Closed dai-shi closed 4 years ago
There are two concerns in this PR.
a) How to convince the usage without context (zustand is the same)
b) We would get the react#17099 warning, if useGlobalStateProvider
is used for opt-in CM support
Still, I think this is more or less promising as v1. (I mean at least better than less common observedBits
.)
Tested v1.0.0-alpha.1. https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-mode/tree/d9501d598621625c581d8d32d9f7894ebd4b6bfa
react-hooks-global-state
check with events from outside
✓ check 1: updated properly (8540ms)
✓ check 2: no tearing during update (1ms)
✓ check 3: ability to interrupt render
✓ check 4: proper update after interrupt (2379ms)
check with useTransaction
✓ check 5: updated properly with transition (3635ms)
✓ check 6: no tearing with transition (2ms)
✓ check 7: proper branching with transition (4485ms)
👏
There was an interesting and shocking tweet from @sebmarkbage. https://twitter.com/sebmarkbage/status/1219836431972978689
Originally, the implementation of this library didn't use context. Then, people expects the use of context for global state. I also wanted to seek the possibility of
unstable_observedBits
. So, the implementation was changed to context based.Now, if we follow the suggestion in the tweet, I don't think we need context. Furthermore, the use of unstable observedBits kept this library away from hitting v1.
This PR is to implement the same API without context. (Precisely, we no longer have
<GlobalStateProvider>
, so it's a breaking change.)The most challenging point is the experimental support of Concurrent Mode, which was another reason why I used context before. With the new
useGlobalStateProvider
, it links React state and global state, which allows "state branching," yay!This is for v1.