Facebook's React and Flux Architecture

Facebook's React and Flux Architecture I am a big fan of Facebook's Flux pattern. It just makes a lot of sense to me. And hopefully to you as well if I do a good job explaining it. The Flux pattern can be used in large scale applications. Relay is build on top of the same pattern. So a good understanding of flux will help you understand Relay.

Flux is just a pattern, a simple one, you have lots of opportunities in the way you end up working with it. Relay on the other hand is an opinionated framework.

So what is the problem the Flux pattern is trying to solve? A few years back, model view controller pattern emerged and sort of revolutionised web development. This application had, for instance, 3-6 models. The controller acquired those details from the model and views represented it. As we started to add more models some of those models started to acquire information from other models. Dependencies aries and this is nothing new - it just happens.

So this application with all its models is now in production and ready to be upgraded.

With a high pace of development your customer addresses the need for new features to be implemented. Some of those features require you to create an environment where more models are depended on each other. Guess what, the your single source of truth just vanished. Everything depends on something else and you end up with an unstable application state.

With Flux, you are creating a one way flow of information and it defines constrains for you. So instead to allow models to read and write from each other and allowing the views to read and write to all the models, lets try to maintain a one way flow of data.

(Flow of information source: https://facebook.github.io/flux/docs/overview.html)

The views can only read from the stores (which are the models). Important! They can’t write to them directly. Of course, views will need to alter data in the system eventually but instead of writing to them directly to the store, you implement actions which trigger an api to dispatches events. Communication to an API is a different problem domain, Flux does not provide a solution there.

Actions, in the Flux pattern, are just vanilla Javascript objects. Those usually hold some kind of data. But they also have a type property. That type property holds the information of how others are supposed to followup on a triggered action. Think of actions as an API of your application, not the data. That is the reason why we connect them with the API of the data. That means you create a solution where one interface communicates with another. For instance:

To clarify, _AppDispatcher is just a helper class to minify the amount of writing and to increase readability. SocialAction is a singleton object to interface with functions

like postToFeed. This functions triggers the dispatcher which instantly creates a call to all stores. In order to identify to where this data is supposed to be send we attache a field called actionType.

So what exactly is this dispatcher? It is a simple module with a very simple job. We have this data now broadcast/emit to the rest of the app. There is no intelligent logic in that dispatcher. The dispatcher is a collection of callbacks to which stores are going to register with. The dispatchers job is it to execute the callback when an action was fired. The dispatcher is a singleton in your app. That means you have only one dispatcher in your application. This is a key constraint to avoid the connection mess we discussed earlier.

When you have stores that depend on each other, you have to declare that dependency. With a singleton dispatcher and say that StoreA.waitFor(StoreB) before it is processing its own data. This is a readable process and a clear dependency to make the dispatcher execute the callbacks in order. In this example StoreB was called

first and than StoreA. The payload on our dispatched item is our simple action and thanks to Facebook, we don’t have to implement this dispatcher. They have shared their effort with us. In order to become proficient with the dispatcher you have to become familiarised with three methods, such as dispatch(), register(), and waitFor().

Dispatch() to emit changes to the store, register() for Stores to register with a Dispatcher, and waitFor() to handle the correct order of execution for certain actions.

All this seems to be a lot of boilerplate code, check out https://github.com/rackt/redux and see if it is a fit for your application. Its based on Flux and incorporated an easier setup at the beginning.

The store, all logic based on an action is happening here. Each store is a singleton and completely autonomous. Its a separate entity in the system. No components writes or reads to it directly. They either listen or emit information about data changes in the system. The stores are in control of data management and with a simple switch you can tell it to execute or to hold off for a moment. A store is a manager of your apps state. It decides whether data should be kept or mutated.

Each store operates with private variables and methods. This keeps secret data where it belongs. Stores are interested in what a dispatcher sends as payload. Which is basically just a big mapping against operations for each time it is executed. There is only one way for a store to actually store data; through a dispatched action. There is no other way if you remember the constraints. Again, components can only read data that is exposed to them, they don’t own rights to read and write directly to a store.

That leaves one simple question, how do you change data within a store? You don’t, stores are in control.

Every store emits a change event, when ever it is executed. Those events are necessary for views/components to make them aware of data that has to be changed.

Views are listening to changes on a store and are changing their state in case it is necessary.

Last but not least, React comes into play with its component trees. Some components are dry and only obtain props, others turn into controllers. Changes are edited based on actions called by a component. Views are changed when stores change and React will re-render if shouldComponentUpdate.

And just what could I do for you? Well, let’s find out. You can get in touch with me through the following mediums. Let’s talk coding and all that it could deliver for your project, whatever that may be.

Email - michel.herszak@gmail.com Twitter - @MHerszak (twitter.com/MHerszak) Want to know even more about the way in which I work?

You can check me out over on my website, right here.