observedBits 32bit limitation

[dai-shi]

Discussion from https://link.medium.com/gXvqudhDNR

[dai-shi]

Option 1: we rotate the index. % 31
Option 2: we use multiple contexts for each 31 items.
Option 3: multiple contexts for each items. Do not rely on observedBits

[cyphercider]

Assuming you abstract the implementation away from the user, I guess the decision criteria are (?)

1. Potential high overhead or general “misuse” of the react context feature if potentially hundreds of contexts are created as with option API design question #3
2. Rendering efficiency of the app to the extent that with observedBits 32bit limitation  #1, some components will undesirably receive a state change when an overlapping index has changed

I don’t know enough about the implementation of Context in the react codebase to know if #1 is a concern.

It’s still not clear to me how we may subscribe to deep state or if that is even desirable considering we can receive a state change for the high level state but avoid re renders using things like memo() for functional components and useMemo for computed values.

[dai-shi]

Thanks. I'm not sure either how much overhead creating hundreds of contexts leads.
Another concern is whether observedBits will ever be official...

BTW, https://github.com/dai-shi/react-context-global-state is already taking the Option 3 approach.

[dai-shi]

but avoid re renders using things like memo()

something like this?

11_deep / Person.tsx

const PersonFirstName = () => {
  const [value] = useGlobalState('person');
  const { firstName } = value;
  return useMemo(
    () => (
      <div>
        First Name:
        <TextBox text={firstName} />
        <input
          value={firstName}
          onChange={setFirstName}
        />
      </div>
    ),
    [firstName]);
};

[cyphercider]

Yeah, that's exactly what I had in mind for useMemo.

[dai-shi]

Option 4: we pass non-updating "store" in the context, and let hooks subscribe for key-based changes. This is mostly like the previous implementation which requires useState.

[dai-shi]

Turns out that the current implementation already takes the option 1 approach.
I keep it as is, otherwise the library implementation gets much bigger.
This limitation should be clearly noted in README.md.