Kontakt

React & Redux

reactjs.org / redux.js.org

We're using React & Redux in almost all our big Frontend Applications, that's why we can wholeheartely recommend to ADOPT it.

Benefits

  • declarative approach to UI rendering, effectively making the UI a function of the state
  • with Redux, state is immutable, and state changes happen through pure functions (see immutability and pure functions). State changes do not rely on object observing, which reduces error likelyhood (through lost updates) a lot.
  • is quite fast by default, can be optimized a lot. Very understandable and debuggable what's happening when.
  • has a small API surface (is a library instead of framework)
  • time-travelling debugging using redux-devtools possible
  • scales well as the application and its state gets bigger
  • reselect can be used for computed properties based on state
  • create-react-app helps to get started really quickly
  • for native apps, react native is a good option. See the article on PWAs vs React Native for background.
  • we use plow.js for mutating deeply nested state in an immutable way and functional way (since it supports partial application/currying). For huge projects (like Neos UI), we use immutable.js (which is also supported by plow.js). Alternatively, one could also use immutability-helper.
  • For complex workflows, we like to use redux-saga, which also worked well for us to implement state machines.

Drawbacks

  • especially with Redux, quite some boilerplate code has to be written
  • modelling big application state in a good way is not easy, and there are little guidelines available
  • There is no standard way to implement routing; and especially the de-facto standard react-router has a lot of API churn.

Alternatives

  • We have used ember.js heavily in the past. While this worked well especially to get started, we found numerous hard to debug scenarios as the projects grew in maturity. In my opinion, this is rooted in the fact that changes are observed on mutable objects; leading to lost updates in case the dependency tracking did not properly work. Especially with highly nested data structures, setting up the dependency tracking in a fully correct way is very hard. That's why we do not use ember anymore in new projects.
  • We won't use MobX (as Redux-alternative) for the same reasons; as it is built around observing mutations as well.
  • Vue.js looks very lightweight and has a solid following; but also has a reactive change tracking mechanism at its core - which is why I fear that it might suffer of the same problems as Ember (and which is why we always stick to React).