Shopping in a Redux Store

2019/08/20
redux, store, state, pattern

• what happened
• what worked
• generalization, expanding the store pattern

Redux 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