🛠 📐📏 Understanding MVC Architecture with React
Model-View-Controller (MVC) is a very often used software design pattern for implementing user interfaces. Since I tried to use and understand the structure in my last projects, I decided to take a deeper look into it. This article provides an overview of MVC and it’s use in the React environment.
📄 Table of contents
“If you can’t understand it, you can’t change it”
― Eric Evans, Technologist
What is MVC?
MVC is a way of thinking to structure your web application. It’s popular because it’s used by many frameworks that implement that structure (rails, cakephp, django etc.).
The architecture stems from the traditional flow of a web application.
- View — Client
Displays visualization of the data to the user. Only connected to the controller.
- Controller — Server
Processes server-side logic and acts as a middleware between View and Model, i.e. controlling the flow of data.
- Model — Database
Processing data from or to the database. Only connected to the controller.
See a practical example here ➡️
What are it’s advantages and disadvantages for coding?
The structure allows flexibility since responsibilities are clearly separated. This leads to
- better and easier code maintenance and reusability
- easier to coordinate in teams due to the separation
- ability to provide multiple views
- support for asynchronous implementations
, but also to
- an increased complex setup process
- dependencies, i.e. changes in the model or controller affect the whole entity
What is React?
- declarative: Design different views for each state, which will be efficiently updated and re-rendered
- component-based: Build components, that manage their own state and structure them together into more complex UIs
- maintains an internal representation of the rendered UI (“virtual DOM”), that renders only the changed elements
Apply MVC with React = Flux?
Whereas React is often referred to as the View in a MVC structure, Facebook presented their own architecture called Flux ➡️. The problem with a MVC structure is it’s bidirectional communication, which proved to be very hard to debug and understand when a change in one entity caused cascading effect across the codebase. Especially when the app is scaling into a much bigger one, like Facebook for example. The flow of data was not well enough or easy enough defined for large applications.
What is Flux and what is different compared to MVC?
Flux is made up of 4 key elements:
Objects with property and data.
Contain the application’s state and logic.
- The Dispatcher
Processes registered actions and callbacks.
Listen to changes from the stores and re-render themselves.
It’s important to notice and understand the unidirectional flow here.
Now the differences to a MVC are:
- The flow of processing is unidirectional instead of bidirectional
- stores are able to store any application related state, whereas the model in MVC was designed to store single objects
- the initiating point Dispatcher makes debugging much easier
Despite the fact that some are calling MVC “dead”, I think Flux is more of a refined and enhanced MVC, and thus sympathizing withPaul Shan and his conclusion in his article.
What is Redux and what is different compared to Flux?
Redux builds on Flux and can be described in three fundamental principles:
- Only one single source of truth
The state of your entire application is stored in a single store.
- State is read-only
The only way to change the state is to emit an action (an object describing what happened).
- Changes are made with pure functions
Specify the transformation by actions with reducers, which allow to navigate through states.
- Redux does not have the concept of a dispatcher because it relies on pure functions instead of event emitters.
- Redux assumes you never mutate your data. You don’t mutate them in a reducer but rather return a new object
As the documentation already suggest, you should use the concept of redux after understanding React first. And:
In general, use Redux when you have reasonable amounts of data changing over time, you need a single source of truth, and you find that approaches like keeping everything in a top-level React component's state are no longer sufficient.
As we could see, software design patterns are evolving with time. The use of certain architecture depends heavily on it’s used frameworks and goals of each project. That being said, in the end, MVC, Flux or Redux are just tools. Be sure to know their tradeoffs and use them accordingly.
Please leave comments, feedback and suggestions as I am always trying to improve.
Share your thoughts - it's never been easier 😄
Dive deeper — some useful links
- 🔀”Model-View-Controller” — Microsoft (retired content!)
- 🔀”What is programming MVC” — DevMarketer (video)
- 🔀”MVC Pattern” — Tutorialspoint (practical example)
- 🔀”Benefits of Using MVC Model” — Soroosh Pardaz (LinkedIn article)
- 🔀”Is MVC dead on the front end?” — Alex Moldovan (5min article)
- 🔀”Flux Concepts” — Facebook (Github)
- 🔀”Flux vs MVC Design Patterns” — Amir Salihefendic (5min article)
- 🔀”MVC does not scale” — Abel Avram (5min article)
- 🔀”Flux vs MVC” — Paul Shan (5min article)
- 🔀”Redux Docs” — Redux (complete documentation)