No guidelines for UI-related side-effects and state for Component vs Store level

[petemill]

Add more documentation (and include patterns / libraries) around where UI-related logic and UI-related state should be stored and handled.

Side Effects

At the moment we have redux reducers mixed with action-handlers that fire more actions, and/or perform an async-action first (aka side-effects). This is often OK for smaller projects, but we may be at the scale where it's good to make a decision about what would be more readable, maintainable and performant considering the amount of actions, side-effects and state.
We should decide if:

• What we are currently doing is ok (mixing state reducing functions with more action dispatching and side-effect api calling, e.g. muon)?
• We should use a side-effect library such as redux-thunk, redux-saga, or other (see link below)?
• We should define when it's ok to put this logic in to either:
  • 1. UI component
  • 2. action creating function,
  • 3. specific side-effect action handler or;
  • 4. a state reducing function

Related reading: https://redux.js.org/docs/faq/Actions.html#actions-side-effects

State

Of course as much state data as possible should be placed in the store, but should we define when it's ok to use:

• Component state (setState)
• Component instance property (this.blah)
• Global / static property (const blah)
• (or even a component-level reducer https://twitter.com/dan_abramov/status/736310245945933824)

Related reading:

• Question: How to choose between Redux's store and React's state? reduxjs/redux#1287 (comment)
• https://redux.js.org/docs/faq/OrganizingState.html#organizing-state-only-redux-state
  (great list of articles discussing these)

Actions

• Guidelines should be added that actions should be declarative, and related to the user gesture / UI event that is occurring, rather than the specific store property that should result in a change.
• Is this for all components, or should there be a distinction between dumb components and container components. Container components, or action-creator logic could distill some UI events for more performant / coherent store actions.