Image for post
Image for post
Photo by laura buron on Unsplash

Introduce an opinionated react front end architecture

Abstract

  • 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

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.

After I started working with the javascript, this issue was one of the first big problems in my eyes. Coming from the java back end development, I would say that any undefined logic group should go into a specific module. In general the service object pattern fits, that seems to be known to some people. In the same way many spring applications structure their logic.

So I integrated the following react-redux architecture that is based on best practices from a spring back end.

Image for post
Image for post
Extended flux architecture

Core new points of this architecture

  • 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

The result

  • 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.

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store