Stores, Actions, Components. If this sounds like a shopping centre, you are not far off – but only in a figurative sense. Because the JavaScript library React.js, launched by Facebook in 2013, and the brilliantly functional application architecture Flux, offer a wealth of new possibilities in web development. A rethink is needed! And our shopping trolley was well-filled during one of our internal workshops last week.
React Speed and More
First, we focused on the specific features of React. Following that, our path led us to Flux. While React primarily sees itself as a view controller and, with a virtual DOM layer, only updates what has truly changed in the display, Flux is a model that makes frontend development feel almost like desktop software development. Thanks to the virtual DOM, the rendering of even complex applications is incredibly fast, so the initial task of a small ticker for React seemed almost ridiculously easy.
But we learned a lot in the process. Starting with JSX (a simplification and acceleration of JS programming through XML-based commands) through to the initially confusing unidirectional model of Flux.
Confusion Included – Yet All Manageable
Because it takes a significant mental shift to move from "classic" JavaScript to component-based development. The individual components do not interact directly with the view, but instead, via a dispatcher and by calling specific actions, instruct the store to deliver new data, with which the view is updated in a render() method. And this short sentence actually describes the complete idea behind the Flux architecture.
Flux View vs MVC and Examples
While in the well-known MVC model, multidirectional communication can lead to difficult-to-oversee one-to-many connections, Flux remains consistent, and communication always occurs in only one direction, or in a circle. The most important tool here is the dispatcher, which distributes specific actions to all possible stores. Returning to our ticker, for this we had a single component (with the render() method vital for the view), which, with a single action, prompted the store to deliver new data (here, the application's runtime so far) to the view. Sounds like unnecessary overhead? Perhaps for a small ticker – but the scalability quickly outweighs the initial extra effort – as we quickly realised with the next example from the workshop. We rapidly built an image mover component based on what was already written, by swapping an element in the view and then being able to drag and drop a "glowing element" across a greyed-out canvas with mouse movement.
Flummox Shows the Way Forward
Building on the workshop, I then turned to "Flummox", an implementation of Flux which further simplifies its use and reduces boilerplate code. And having barely started with React and Flux, I am hooked and only at first glance "flummoxed". Thanks for a brilliantly great workshop and the introduction to development with React!
