Improve front-end state management

[AlanGreene]

The front end currently presents data from a number of APIs in most of its views. The logic required to correlate the pieces from different sources is subtly different between e.g. Pipeline and PipelineRun vs Task and TaskRun. This leads to unwanted complexity, additional maintenance overhead, and increases the risk of bugs.

So far we have used a small number of top-level container components which are responsible for making API calls and manipulating the responses into a form suitable for consumption by the presentation components. This approach will not scale long-term, especially as the data needs to be combined / presented in new and subtly different ways for other features / views.

Introducing a consistent state management layer which normalises the data received from the APIs and is isolated from the presentational layer will allow for greater flexibility, improved consistency, and easier testing.

Plan:

• redux (with react-redux + redux-thunk for async actions) as a single source of truth
  • container components bound to store via react-redux's connect, and provide relevant view of state as props to pure presentational components
• normalizr to ensure consistent and efficient storage of the data according to a simple schema
  • shelving this for now
• Pipeline, Task, PipelineResource, etc., indexed by name/id as appropriate
• action creators responsible for API calls (thunks that make API calls and dispatch actions)
  • view triggers action creators (use mapDispatchToProps to bind to store)
• selectors (using reselect or similar) to retrieve content from the store, containers/components shouldn't know the shape of the store
  • use mapStateToProps to provide appropriate inputs to the containers
• utilities for generating common reducer + action creator patterns
  • shelving this for now

[AlanGreene]

/assign

[AlanGreene]

Core work complete, any additional work will be tracked separately.