This is assigned to tfennelly for now, but it's really tscherler + tfennelly, working together to evolve the current redux codebase to something that is easier to maintain, test, extend etc.

We are using redux more and more and it works well (it's fundamental to how BlueO works), but we have stretched the current implementation beyond the point where it is easy/possible for others to make sense of it, contribute to it etc. It's getting harder and harder to maintain, so we really need to evolve it to the next stage.

There may be other evolutionary steps required/possible (e.g. generating from the backend rest api) as the whole app evolves.

We'll see if we can come up with a more composable pattern for managing app state in redux. Maybe something like a StoreObject JS type that can be added as an extension point (in the .yaml file) that encapsulates a redux reducer for handling a specific set of redux actions relating to a specific piece of state (e.g. branches on a job) + providing helpers for loading/fetching data from the REST API etc.

Let's see about Immutablejs too. tscherler feels strongly that this is the right way to store the state. He has very valid points re reference Vs value equality etc and how Immutablejs helps there + management of large amounts of data (freezing and cloning the whole state will not scale as we grow), but others find Immutablejs a bit cumbersome to use (myself included). Maybe there's a happy medium..

Moving everything to a new pattern in one go would be a big task, so it would be good if the new pattern could live alongside the existing stuff as we transition. That way, we can divide and conquer.