CMS Data Layer and Handling

Data States

The canonical data state of an entity is comprised of 3 states, where the External State takes precedence followed by the Local then the Server.

External > Local > Server

todo: Deprecate DataState reducer and epics The DataState itself can largely be made redundant with correct use of reselect (a library for redux selector caching). Deprecation of the DataState will significantly reduce the amount of actions and logic fired when fields are update and improve performance of both the Layout Manager and Article Builder.

Until deprecated the DataState is widely used in the building of ALL entities types.

The 3 remaining data states are still required in order to track changes to an entity, External and Local states may be discarded via unlocking or reverting and thus the Server state needs to be restored avoiding an unnecessary API request.

Assuming deprecation:
Components handling entity data request the required data via a selector manufactured with the createSelector function from reselect. This selector will for the majority of cases select data from a state where it exists in the priority outlined above, in some instances the data states will need to be merged to get a data object from a combination of state.

createSelector allows the selector be cached, and when reused amongst several components only created once so that the resulting data needs to only be formatted once, this will also ensure correct re-rendering when the results from the selector change due to data being updated.

Existing implementation:
The current implementation builds a canonical data state from a combination of the 3 states and saves this state in redux, this state is then used to update the display of fields. This is deprecated by the createSelector method as the state of a field is stored by the selector, rather than in it's own reducer.

When any state updates the canonical data state is also updated, this causes a lot of pressure on the application as what should be handled by a single event trigger now takes multiple events and causes unneeded re-renders of the application.

Local State

This layer stores all unsaved changes that an editor has made to an entity. These can be removed by reverting changes

Server State

This layer store the latest saved state of an entity, when an editor saves an entity a websocket event is broadcast to all clients displaying the same entity, those clients then request the new data from the API and updates the Server state.

External State

This layer stores all unsaved changed made by other users, when an editor updates an entity local a websocket event is broadcast to all clients displaying the same entity, those clients then request the new data from the AWS micro-service that stores a canonical copy of all data changes to an entity and updates the External state.