I’ve mentioned about being dependant on frameworks in another post here:
#1 – The problem with abstractions
Now I intend to explain the opposite concept.
Separation of Concerns, was a term created by Edsger W. Dijkstra.
For instance, it’s the thermology used for when you can identify and isolate each aspect of a software so it becomes clearer what every part is supposed to accomplish.
This approach gives us many advantages such as: maintainability, easier debugging and bug fixing and the software overall. By using it accordingly it gets easy to replace a portion of your website whenever needed.
Single Page Applications
Let’s try and categorize each aspect of an SPA. We can split it into three sub-items: State, View and Actions.
State
All data inside an app, from a request response to all data that was statically set on the code.
View
It’s basically our HTML + CSS, they’re rendered according to the data fetched from the app itself.
Actions
These are the events that occur inside our app, sometimes they modify the State, sometimes not.
We can split these events in two:
— User interaction: Button click, data being filled in a form, etc…
— IO: Network events, such as a request being made.
Now, how do they integrate? It’s quite simple actually. The State is responsible for storing the data and delivering it to the View. The View then will render relying on the data received. If an Action takes place, and changes the data inside the State, then the State sends the brand-new data to the View and the whole cycle restarts.
This description can be seen in every SPA, regardless of the technology involved. The question here is that several frameworks have those three parts glued together, being impossible to replace each ‘agent’ behind them.
React
Of all three parts we discussed, React takes role within one, the View. React doesn’t really care about how you manipulate the State or Actions, he just gets the data through the props and interact with the DOM to render the View.
Redux
In other hand, Redux is responsible for both the State and Actions, giving you the ability and flexibility to work with the View as your will.
A Redux Store contains three methods that allow you to work with the State via public API:
subscribe
By using this method, you can add a listener to the Store, that will be later invoked whenever a State change is performed.
dispatch
With this one you can trigger your actions.
getState
This method gives you the power to read the current State. It’s usually used inside the listeners, to capture the State when a modification occurs.
Whit these three methods you can pretty much integrate Redux with whatever View render lib you opt to use.
Analyzing both React and Redux makes it clear how they complement themselves and work in an independent way.
More to come at:
#3 – Has React and Redux helped me become a better dev?