Effective Application State Management - Lesson 2

Reading Time: 2 minutes

Prior Lesson

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.

Continue reading

Using Flux for component states is an anti-pattern!

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.

Continue reading

Flux explained for newbies - Part 4

Reading Time: 5 minutes

Introduction

Flux-CapacitorIn 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.

Continue reading

Flux explained for newbies - Part 3

Reading Time: 4 minutes

Introduction

Flux-CapacitorIn 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.

Continue reading