Introduce an opinionated react front end architecture
- react.js is just a view (+ some controller logic) in classical MVC
- redux introduces some architecture but its incomplete
- why we need to become opinionated
- suggested solution for a react-redux architecture
- advantages of using a completely defined architecture
React is a library, not a framework
Its known react is just a library. If we would map it to the most known design pattern MVC then it would be the V(iew) + some ability to trigger controller actions, who can exist on the view itself.
If we add redux to the stack we usually follow the official flux architecture.
So framework wise we cover the MVC functionality and unfortunately this is still not the complete picture. To make an example this are the parts of the logic that are not mentioned in the flux architecture. The structure for the rest of logic is open for the team to decide.
- logging logic with addition reporting to some external bug tracking tool
- domain specific logic, like some tax calculations or business objects management that is used from several react components
- environment management, specifically activating some feature in dependency of the environment at runtime or feature toggles
- technically neutral http and REST logic
- i18n logic used by many components
- mock data generation and management from central place, used by many unit and integration tests
- redux store setup, specifically in dependency of the current environment
So we see there are many areas left out of the flux architecture, since its goal is to organise the react view part itself and not more.
In case its left undefined where all the other logic parts go, developers will randomly make their architectural decisions. In the most cases it will result in an uncoordinated architecture, not centrally handled concerns and many specific assumptions.
So what is the solution? Obviously to cover the rest of the stack and to answer the questions, that seem unclear.
So I integrated the following react-redux architecture that is based on best practices from a spring back end.
Core new points of this architecture
- we have a services layer, that is used top down from the react components, I will describe a service in a separate article in more detail
- it is strictly forbidden to break the architectural borders, like passing around the reference of the dispatch function from redux to other architecture layers
- we have a rest calls middleware that works with specific rest actions, I will present it in a separate article as part of this series.
- there is no redux thunk or saga, we use a redux middleware to make async calls in only ONE place
- something that I called “the action chains” and “service actions” are used as a pattern, I will describe it with the middleware
- with this extended architecture we can clearly assign new types of logic to the services layer. We cover the client site to the end and developers have a clear framework to structure the code
- within a company you can rely that any project is following the same structure, so people have an easier way to jump in and find their way around
- there are no unknown or single person specific patterns used in the stack
- junior developers can focus on parts of the present parts of the architecture, without having to know everything right away
I used this stack in two projects right away and made the best experience with it. During this time I brought at least 4 new developers on board into this projects. My colleagues we productive after 1–2 days inside the code base. Besides a react router integration we had no other architectural choices to make.
The core simplification comes clearly form the rest middleware and the services layer, wich I will present in the following articles.