This week in the curious case of React - #3
🌏 Navigating the React World (#2)
Hey!
As I promised, this issue is all about what makes React great and its architecture. Now you might be wondering how did a new library like React overthrow frameworks like Ember, Knockout, or the much popular Jquery in adoption by developers. The devil is in the details so we might need to go back in time a little.
Pre-MVC
Before front-end frameworks became popular most web development was done in plain old (Vanilla) JS. As you might expect, as the complexity of the apps we built increased, managing, and reusing the code across the code-base became a problem. So we quickly adopted libraries that were making the developer's life easier by providing commonly written patterns out of the box.
Out of all this emerged Jquery which became extremely popular. Have a look at http://youmightnotneedjquery.com/ to get an idea of the amount of boilerplate code that was not needed anymore. 🔥
While Jquery was and is quite useful even now, for larger corporations with multi-developer teams this proved to be a debugging nightmare since now anywhere in your 1000+lines of code could potentially be a jquery
call to trigger a button and the listeners to these events could be spread over multiple files.
There was simply no easy way to reproduce the entire flow of events if needed in case of an error.
MVC
Then came MVC frameworks like Ember
and Knockout
solving this issue. MVC is a very popular design principle applied in many frameworks (not limited to the frontend) with its core idea being "separation of concerns".
Model: Manages data and business logic.
View: Handles layout and display.
Controller: Routes commands to the model and view parts.
This helped to have clear boundaries as to who could update data that needs to be displayed by a View layer. (React is just the View
layer of the MVC paradigm)
While this was useful, the view could still be updated from multiple models and any action on the view could update multiple models as described in the image below. (Bi-directional data flow)
This is not a big concern when the application is small but at Facebook-scale this simply did not work.
Flux
Facebook when faced with this conundrum came up with an architecture that allowed uni-directional data flow which is what they called Flux.
This meant a View could only be updated in one-way and the data-flow was predictable which solved the debugging nightmare developers faced sometime back.
Actions: Simple plain object with
type
field indicating the kind of action along with the actual data.Dispatcher: All data flows through the dispatcher as a central hub.
Store: The data store updates itself in response to an action. The components which need this data are alone re-rendered.
View: The same view layer as described above. User events in the views like clicks may lead to action.
Flux is just an architecture, not an actual framework. The most popular implementation of this architecture is Redux which I would highly recommend you use in your next project.
React inherently follows this way of handling events making it a breeze to work with and debug. You can visualize what each action would do to the view layer since the data-flow is so predictable and happens in one direction alone.
Thanks for reading!. If you liked what you read let me know! Better yet share it with a pal would find this series useful.
Next, I will talk about the Virtual DOM and performance gains you get as a developer making web apps using React.
Follow me on Twitter for anything related to tech, startups, and building products.