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: 5 minutes
Currently, I am refactoring a mid-size application which I started more than a year ago (additionally, to my daily workload). The project is a ReactJS application consisting of more than 120 components already. I started developing without Flux (mainly, due to the fact that I didn't understand the need for Flux initially). In the meanwhile, I gained a deeper knowledge of Flux and decided to go for it in that project. I chose nanoflux as a Flux implementation, my very own implementation. While I think that Flux is - once understood - a very simple concept I discovered that one challenge is to decide what shall be treated by Flux and what not - By far, not everything that is a state is worth being shifted towards Flux.
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.