First Impressions with Flux
I recently got the opportunity to work with React.js in a production app and also experiment with the Flux architecture pattern used by Facebook. I have to say I’m a big fan of both, and while there was a bit of a learning curve with Flux I think I’m getting the hang of it. Here are a few things that I learned or tripped me up a bit in the beginning.
The Flux pattern is easier to grok if you focus on preserving unidirectional data flow. What does this mean? The control flow of your application moves in one direction, and creates an easy to follow cycle. At a high level, interactions with your Views will trigger Actions that get passed to a Dispatcher. Dispatchers are a central hub of Action management, Stores register callbacks with the dispatcher for the actions they care about, and this is THE ONLY WAY that stores can be updated.
Stores in Flux do not expose public setter methods! This one architecture decision removes a lot of problems that appear in typical MVC apps where data will all of a sudden change when you least expect it, because somewhere else, another component modified it.
Dispatchers are sort of analagous to Backbone Radio, a popular pub/sub event network. Coming from a background of unfettered event triggering, this structure is very welcome and makes code so much more manageable.
One of the biggest differences between developing my first React app and this one was realizing and making a conscious effort to keep views slim. Instead of passing lots and lots of props and state between components, Flux recommends that you have fewer ‘Controller Views’, views that typical live higher in the component hierarchy and are responsible for reading data from stores and passing it along to their children. This reduces the coupling that would arise if each and every one of our views were tied to one or more of the same views.
Next steps: I’d like to explore using immutable.js data structures for component state. The two advantages that this will supposedly provide are 1) reducing the unexpected modification of state objects and 2) smarter virtual DOM generation based on true state changes