[meta:edit-log]: # "2019/08/20"
[meta:title]: # "Shopping in a Redux Store"
[meta:keywords]: # "redux, store, state, pattern"
[meta:description]: # ""


[Redux](https://redux.js.org/) is set of very simple but also very useful ideas:
- defined store and minimal store operation
- juggling the states in a global place
- simplified data flow between action, store/state, and UI
- introduced functional programming
- introduced immutable data

And when combined with a declarative UI like React, the result can be quite good.


## what happened

Some history of our `Redux&React` journey:

> When starting with `React` and `Redux`,
> most of us may spend a lot of time focusing on syntax,
> and the somewhat repetitive 'boilerplate'.
> 
> Then the initial confusing phase pass,
> the syntax works, the code piles up,
> the first rev of UI is done.
> But the UI tree feels wired and shaky:
> - `props` (data) passing is tedious and non-obvious,
>   and many function gets passed down, some ref gets returned up,
>   causing confusing flow of control
> - the leaf `Component` have to much code for both UI and data logic,
>   the most of the branch `Component` just passing & filtering data
> 
> Then it occurs to us: maybe it's time
> to finally fully complete the docs for `Redux` and `React`,
> seriously, and no skipping.
> 
> And from the doc, push the UI code down,
> lift the data and control code up the tree is a good idea,
> also clear up the lazy naming for some of the `props` & `Component` helps, too.
> 
> The second rev of UI survives more iteration,
> during which one or more redux `middleware` is introduced for async actions,
> store state gets more crowded,
> the code works, still somewhat readable,
> but still hard to discuss.
> 
> Then the ideas of modularize of UI and data code comes,
> most of the time, the UI is not one big problem,
> but several smaller separated module problem to solve.
> The code split up for each module, with code for both the UI and data.
> 
> So a better code structure is designed:
> some module each with a smaller store, and a smaller UI tree,
> then some wrapper code to compose these up.

what we ended up with is modular data & UI code:
- single globalStateStore, multiple moduleStateStore
- state change action always dispatch to moduleStateStore
- moduleState update will pass to globalState,
  debounced so globalState will change less often,
  UI props can be get from either store,
  depending on how frequent of the change is needed
  
and some opinionated extra simplification/modification:
- function to reduce/operate state is made reusable, outside of reducer
- the `reducer` code logic is minimal:
  just merge the action payload, and expect the dispatcher generate the correct nextState
- almost all of the state-prepare code is in `middleware`, this way,
  the UI dispatch is simple, the state logic can be put into one file,
  and the code can be async
- action can only be `object`, no function ot promise,
  so action should always be simple and descriptive
- no action type file, use string as action type directly,
  no action creator file, dispatch the action object directly
  to minimize boilerplate & import, and slightly better readability,
  the downside is less safe check can be provided

basically we valued:
- modular & shareable & testable code for `state` reduce/produce
- clear & declarative code for `dispatch`
- simple & minimal `reducer` and `Redux` code

> for the `middleware`, search for `redux-entry`


## what worked

`React&Redux` worked for us because:
- the clear and easy to define separation between `action`, `state` , and `UI` is useful,
  code reuse and code responsibility is manageable
- the default setup works, though some opinionated simplification is needed
- official docs & source code (for Redux) provided the most essential & helpful info


## generalization, expanding the store pattern

The concept of store is not limited to React or frontend only

We can generalize UI to be some visible output, or just output,
then a common data flow with store can be like:
```
action -> store & state -> output
```

we may apply the redux-like store code structure to some different scenario: 

- consider some similar data/control flow,
  but in a server:
  ```
  request -> server & data -> response
  ```
  we may create a `store` for each incoming `request`,
  process it by passing though layers of `reducer` updating the store `state`,
  and finally generate a `response`
- or consider in the context of event/messaging:
  ```
  event/message -> eventListener/messageQueue -> some change
  ```
  for some complex stateful event/messaging code,
  maybe create a store with state,
  and put message-processing/state-changing code in some `reducer`,
  can result in a more clear and debuggable code