RFC: UI State management

[flashbackzoo]

Author: @flashbackzoo @chillu
Status: Pending review
Version: 0.1

Purpose and outcome

Given the UI of the SilverStripe CMS is written using the React library, there needs to be a pattern for managing state, which is consistent and extendible. This RFC proposes we use Redux to manage state.

Before reading this proposal you should be familiar with RFC-8: Adding ReactJS to SilverStripe CMS which this proposal depends on. It’s also worth checking out RFC-9: UI Extensibility which is closely related.

Background

As React and the applications built using it have developed, there has been a need for more sophisticated state management patterns than the vanilla React approach, storing state on individual components. The initial pattern put forward by Facebook was Flux.

Flux got some good traction and pretty soon there were bunches of variations cropping up.

The state management pattern we’re proposing is Redux, which evolves ideas from Flux, and is implemented in a functional style (see Where Flux went wrong).

Benefits

These are some of the things we like about Redux compared to Flux and some of it’s variants.

Simplified dependency graph

Flux architectures use multiple stores to keep track of various application state. This inevitably leads to stores requiring other stores, which require other stores. At this point it becomes difficult tell which components will be affected when a store is modified. Affected components may not require the modified store directly, the modified store may be a dependency of a dependency, or even further down the tree.

The Redux pattern removes this complexity by defining a single store for the whole application. The store’s state is segmented by key and components opt into having access to zero or more segments of state.

A simplified dependency graph helps avoid side effects and regression issues as well as making risk analysis much easier for developers.

Well suited to Test Driven Development (TDD)

Redux promotes a functional programming style which we’ve found is a natural fit with TDD. Reducers (the functions which update state) have well defined inputs and outputs with no side effects. Everything is very well isolated which makes writing tests really easy to write.

Tradeoffs

Both Flux and Redux are based on uni-directional data flow, where components don’t affect state changes directly. Instead, actions can be sent by components which get digested into state changes that might cause a component to re-render. This level of indirection can cause boilerplate code for action definitions and fragments the logic more than a straightforward jQuery update cycle would.

Redux also treats each async action (e.g. an AJAX call) as a multi-action sequence (see redux-thunk) which is causing additional boilerplate. We hope to reduce this by creating a client-side API layer abstraction.

Dependencies

Both Flux and Redux are architectural approaches at their core. While they’re most at home in the React ecosystem, the pattern can be applied to other UI frameworks like Angular as well (example).

Example

We’ve put together a proof of concept to show how Redux could be used in SilverStripe CMS.

[anselmdk]

Redux can seem a little complicated if you have no knowlege of React, but I've just been through reading up on React and Redux during the last few months, and am currently building an app based on it. I'm loving it - it feels like a whole new paradigm of web development. I'm very much in favor of SilverStripe taking this approach.

[assertchris]

Here's a free video course, by the creator of Redux: https://egghead.io/series/getting-started-with-redux

[markguinn]

+1 on this. I think the client-side API layer is good idea as well.

That egghead video posted by @assertchris is a great resource. I would recommend watching that before trying to get through the docs and tutorials on the redux website. It really makes it more clear why certain features are needed and what they're doing under the hood (connect() method for example)

[flashbackzoo]

This was implemented and has been in master for a while.