If you are working with Redux, the state definition is a key task in the design of your application. Once the state is defined, the reducers are the next step, setting how the state will change according to the inputs received. If your state is too complex, is better to group the logic in two or more reducers and then use something like the following code:
val newState = combineReducers(::reducerA, ::reducerB)(action, oldState)
In this way, the method
combineReducers will accept as many reducers needed, connecting the output of one reducer to the input of the next one in the list…
We could define -in a simplistic way- the async code as the code that, after calling it, returns an answer that is not immediately available and most of the time is executed in a background thread. For example, to connect to a BLE device or to download an image from server.
One of the most chocking ideas (at least for me) after adopt a Redux like pattern was that everything worked totally synchronous. The actions were processed one by one in the main thread, the state modified, the view was updated and the predictability was fantastic but: How to deal with asynchronous signals or remote API calls?
There are two main approaches to deal with async calls: action creators and middleware.
Both of them share the same functionality behind and it can be summarized in 3 main points:
Sometimes when developing an app, you need to introduce some complexity in order to keep your code neat and clean.
Applying this idea to a bicycle, an internal-gear hub part comes to my mind: the interaction with it is simple and makes life easier if you stop-and-go when commuting in a big city. On the other hand, it is a complex and expensive component.
Curiously, the same example can be found inside Fidesmo app codebase:
Unidirectional architectures are here to stay. Web development is full of successful cases based on Flux, Redux, Elm, React among others and some of them have been ported to mobile dev with really nice results. But, are these ported frameworks enough mature to be used into a production environment? Is it worth it?
At Fidesmo we think it is, but there are some considerations about our app that make the decision easier. Our app is a kind of bridge between Fidesmo devices and a whole remote platform to interact with them. So, for our app:
Fastlane is growing fast, it was bought by Fabric and again by Google (as a product of Fabric). In Fidesmo we’re totally fans of Fastlane and its ecosystem. Here is an example of the lanes we use internally:
The most relevant point of this lane is that it takes the version number and changelog from the existing Git information and you don’t have to worry about anything, just to define the kind of release you want to publish. To achieve that, the follow steps are executed:
Imagine that in your new job, the RESTFul API that will be your friend in the next 6 months isn’t correctly designed. And you receive a different data structure for the same value, depending on external factors that you can’t control. For example, you’ll receive every text content translated into two languages but if one is missing, you’ll receive only the default language.
As the previous JSON shows, we could receive a translated string in multiple forms, as a dictionary or as a string. How to deal with that? First let’s try with the straight solution: