Reading Time: 3 minutes
Keep your state simple II - Flatten the state
Here we go with the fourth lesson of my series about "Effective Application State Management". In this lesson I will - once again - emphasize the simplicity of an application state. If you followed (and understood) the previous lesson you may have noticed that it can be quite tedious to update immutable states.
Reading Time: 2 minutes
Compose your state
When you are going to introduce an application state you should know how to update it. If you're coming from a pure object oriented language like Java, you might think of a class (maybe using the singleton pattern), which instance(s) keep a list of key-value pairs. This might be sufficient for simple states, but usually you have nested objects, and it could be tedious to control this, as you need to introduce some abstractions and/or (de)serialization mechanism to deal with complex objects.
Reading Time: 4 minutes
I'm back! I haven't abandoned this blog, but I procrastinated too much, without being inactive at all. I'm full of cool ideas and have some projects running, e.g. building an Arcade Machine, learning Elixir/Phoenix. I think/hope that in 2017 I'll have more time to write more articles...and this is the first one of a series which I call "Effective Application State Management", based on the concept of Scott Meyers "Effective C++".
Reading Time: 5 minutes
In the third part of this article series I introduced the Dispatcher, the central hub of the Flux architecture,which is responsible for propagation of actions. I also showed, that in most implementations actions can be chained, albeit I do not recommend to make regular use of that feature. In this last part of the series I present the Action Creator which helps us to launch actions in an expressive manner.
Reading Time: 4 minutes
In the second part of this article series I explained that Flux is an architectural pattern and introduced the concept of a Store, one of the essential elements of Flux. I gradually explained the meaning and functionality of a Store and how it differs from the concept of a classical model. I emphasized that a Store in Flux is responsible for maintaining and updating its application state, and notifying interested components. I concluded the article with code snippet demonstrating the usage of a Store using a fictitious Flux implementation. This part introduces the Dispatcher.