How It Works

ThunkModuleMap: the Single Source of Truth

All the states are managed in a single source of truth: ThunkModuleMap.

Object-State

Object-states are typically used for component-presentation. Therefore, Object-states require renew as new objects after each operation for ReactJS to detect the change of the state.

ModuleState and NodeState

We realized that developers care only the object-states. ModuleStates are registered through registerThunk and never renewed as new objects after each operation. NodeStates are never renewed during update or upsert. This approach enables us to have getStateByModule to obtain the newest object-state while keeping object-states copy-on-write.

Following Action-Dispatch-Reducer Pattern Under The Hood.

Despite that we need only the thunk modules when using use-thunk, the implementation heavily utilizes action-dispatch-reducer pattern under the hood:

• The implementation of dispatch can be found here.
• getModuleState can be viewed as the original getState in Redux Thunk.
• set is dispatch and the syntax sugar of dispatch(upsert(id, data)).
• get is the syntax sugar of getting the object-state from module state.
• getOrNull is the variation of get.

Reducers: Only Primitive Reducers

We recognize that state management requires only init, get, update, and remove (CRUD). Furthermore, in most cases, only upsert and get are needed. Therefore, our implementation provides only these primitive reducers.

Separation of doModule and ModuleState

Unlike the selector pattern used by RTK and Zustand, we believe that data and operations should be separated to improve maintainability, since the same module functions should be able to operate on different objects. Therefore, we provide doMod for accessing module functions and getMod for accessing module state.

Object-based Re-rendering

Starting 16.1.0, we use useSyncExternalStore for each object to achieve object-based re-rendering.