Read on to learn more about React and its role in the world of front-end web development.
THE REACTIVE REVOLUTION
Harken back to a simpler time, when the World Wide Web was young—PHP ruled the back-end, and the client-side was little more than a window to content stored in static HTML pages housed on humming servers. The web was nowhere near as dynamic or as interactive as it is today, but the path between server request and an immediately viewable webpage was simple, direct, and even theoretically faster (if it weren’t for the obvious technological limitations of the time), thanks to SSR.
SERVER-SIDE RENDERING (SSR)
THE VIRTUAL DOM
The Virtual DOM works by modeling two copies of the DOM, the original and an updated version that reflects changes received from the view. React takes note of the differences and outputs the DOM operations necessary to only update the parts of the UI that actually changed. In this way, React overcomes a previous shortcoming of SSR, where it was necessary to recreate the entire updated view.
Earlier, we called React the “V” in MVC, mostly to help newcomers familiar with front-end web development concepts to understand how they might integrate this awesome library into their web projects. But if your goal is to embrace the “componentized” future of web development, Facebook develops all its apps using an application architecture called Flux that’s better suited for React. The Flux programming pattern places an emphasis on unidirectional data flow and consists of three parts: the dispatcher, the stores, and the views.
- Stores are similar to the models in MVC, except they manage the application state for a particular domain within the application.
- The Dispatcher is a simple single registry of callbacks to the stores within the application. It also manages the dependencies between stores.
- Views are the same as the view in MVC, except in the context of React and Flux, also include Controller-Views, which listen for change events and retrieve application state from stores as required.
Basically, all data in the application flows through the dispatcher, which acts as a central hub. This data is tracked as Actions, which are provided to the dispatcher in an action creator method, often as a result of a user interacting with the view. The dispatcher invokes the registered callback, effectively dispatching the action to all stores that have registered with that callback. The stores in turn relay that change event to the controller-views to alert them of the change. The controller-views listen for events, retrieve data from the appropriate stores as required and re-render themselves and all their children in the component tree accordingly.
If you’re interested in learning more about Flux, check out this article from Facebook itself. You may also want to checkout Redux, a library that lets you code in Flux, but simplifies things by providing a single store.
SHOULD YOU USE REACT FOR YOUR PROJECT?
Consider using React if…
- You’re already a fan of ClojureScript and the Om Project.
- You’re looking for a performance boost for the V in MVC for your app.
- You like the concept of Flux and unidirectional data flow.
- You don’t mind learning a new technology that’s already become a major part of front-end web development.
- You embrace the componentized future of web development.
React’s emphasis on component-based web development means it is well encapsulated and plays well with other technology stacks. Still, if you’re interested in how it stacks up against other popular front-end technologies, check out some of our comparison articles: