use-thunk: A New Global State Management Lib as (much) Simplified Redux

ReactJS has been a widely adopted development framework. Since Dan Abramov's mind blowing invention of Redux, ReactJS has been drastically changed to function-based components with React Hooks.

I especially like the concept of thunk in Redux. To my understanding, thunk enables the ability that we can write "derived functions" for the actions, so we can write manageable number of switch-branches in reducer. However, we have only useReducer and useContext as the built-in ReactJS.

Issues with Redux / useReducer

I feel some tedious parts using Redux, which makes me want to develop a simplified version:

1. Confusion of the use-scenario for thunk and reducer, as we still need to write around the same amount of the code. It's just the philosophical question whether we want to derive in the action stage and have a simple reducer, or we want to have simple actions and derive everything in the reduce stage.
2. The switch-statement in the reducer makes the reducer easy to be one gigantic function.
3. My understanding of reducer is that it is a gigantic state storing all the info of all the objects. Ideally the objects should be updated through their corresponding functions/operators. However, because reducer is a gigantic state for all the objects, fundamentally we cannot prevent the developers writing functions accidentally updating other objects, or it is not trivial for us to access other objects (through the corresponding operators) if we use slice.
4. The need to write "dispatch" whenever we want to dispatch an action seems redundant.

Issues with useContext

It is possible that we can use useContext to achieve "derived functions for action, and use useState to update the state." by having state and setState as the value for the Context. However:

1. We need to specify each time we create a context.
2. We need to have some customized methods to deal with async operations. We can use getState and dispatch to easily deal with async operations.
3. It is not explicitly described in the document of useContext. The "state/setState as value" approach is a special case/workaround for useContext.

My Ideal Frontend Dev Style

One example of my ideal frontend dev style can be referred to demo-use-thunk, as:

1. Separate the ui rendering (components) from global-state management (reducers).
2. In global-state management, we can write the code like module / functions, with very consistent programming patterns.
3. Instead of action/reducer/thunk/etc., We have only one concept for global-state management: thunk.
4. The global-state management modules can be considered as a class of objects, and we just need to pass the object-id (or not even needed if we have only 1 object) for the ui-rendering to access the corresponding info.
5. For the global-state management, there is a default state for each object. We don't need to worry that the object is undefined/null.
6. We don't need to worry about where to put <Context> in the code.