4 ms·

But why use a HOC? `useState` is a global function. I don't see a problem using some kind of static global state factory thing. Likewise, you could just call

But why use a HOC? `useState` is a global function. I don't see a problem using some kind of static global state factory thing. Likewise, you could just call set() and get() without any of the fancy stuff. Maybe I'll try implementing this to show what I mean/learn why it wouldn't work.

fastball 5y ago
Are you talking about having some global store that you're calling `set()` and `get()` against? If yes, the reason you can't just do that is because if that is done naively then components using `get()` won't know that they need to re-render when a `set()` is called somewhere else. Not done naively and you do have global stores built for this, like Redux or MobX, which handle this gracefully and (at this point) use hooks under the hood and in the dev-facing API to accomplish this. Tbh this is also now built-in to React with the `useContext()` hook, which allows you to do the same. `useState()` should really only be used for local-to-a-component level state (though technically you can obviously pass down the state/setter to any child components, but given the above I find it's frequently better to `useContext()`).
- recursive 5y ago
  Yes. Global store with subscriptions. I barely know react, but I knocked one together in half an hour. https://codepen.io/tomtheisen/pen/NWvdXyJ https://codepen.io/tomtheisen/pen/NWvdXyJ I already like it better than hooks. Everything's out in the open. No magic or hidden dependencies.
  - fastball 5y ago
    Yep it's all out the open and there are many things wrong with it. Fix all the problems with it and you've re-invented the wheel and it's no longer super simple.
  - srcreigh 5y ago
    // this could be made to track actual depencies with more granularity subscribe(() => this.forceUpdate()) You're well on your way to building a decent system here... I guess if you don't pass your dependencies as an array to a function called useEffect, you aren't using hooks. Win! And if you need a specialized function to only update 1 component instead of all of them, just make sure it isn't returned by a dastardly magical function called useState.
    - recursive 5y ago
      > I guess if you don't pass your dependencies as an array to a function called useEffect, you aren't using hooks. Win! You joke, but yes. Also, you don't have to follow these. https://reactjs.org/docs/hooks-rules.html https://reactjs.org/docs/hooks-rules.html And you don't have to rely on the diff remembering which state goes to which widget. To its credit, it seems to do it right at least 99% of the time. I recognize I'm tilting at windmills here. React is a juggernaut, and many people love it. In fact, many people like the exact things that I don't. And that's ok.
      - jolux 5y ago
        You may not realize it but you're just rewriting hooks here. The example you give is too simple to show the problems with your initial approach. The main one is that if you're not extremely careful about when you're writing and when you're subscribing, you're going to end up with a race condition. Similar problems if you call "subscribe" in the wrong place. This is not a safe solution to the problem, and it does not circumvent the need for rules about usage.
        recursive 5y ago
        I'm sure there are complexities that I hadn't considered yet, but I don't see how a race condition can be one of them. Outside of workers, there's really no way to simultaneous concurrency in js. Order of dispatch to subscribers seems like it create similar problems, although it would be fully deterministic, rather than a race. Anyway, thanks for your insight.

fastball 5y ago

Are you talking about having some global store that you're calling `set()` and `get()` against? If yes, the reason you can't just do that is because if that is done naively then components using `get()` won't know that they need to re-render when a `set()` is called somewhere else. Not done naively and you do have global stores built for this, like Redux or MobX, which handle this gracefully and (at this point) use hooks under the hood and in the dev-facing API to accomplish this. Tbh this is also now built-in to React with the `useContext()` hook, which allows you to do the same. `useState()` should really only be used for local-to-a-component level state (though technically you can obviously pass down the state/setter to any child components, but given the above I find it's frequently better to `useContext()`).

recursive 5y ago
Yes. Global store with subscriptions. I barely know react, but I knocked one together in half an hour. https://codepen.io/tomtheisen/pen/NWvdXyJ https://codepen.io/tomtheisen/pen/NWvdXyJ I already like it better than hooks. Everything's out in the open. No magic or hidden dependencies.
- fastball 5y ago
  Yep it's all out the open and there are many things wrong with it. Fix all the problems with it and you've re-invented the wheel and it's no longer super simple.
- srcreigh 5y ago
  // this could be made to track actual depencies with more granularity subscribe(() => this.forceUpdate()) You're well on your way to building a decent system here... I guess if you don't pass your dependencies as an array to a function called useEffect, you aren't using hooks. Win! And if you need a specialized function to only update 1 component instead of all of them, just make sure it isn't returned by a dastardly magical function called useState.
  - recursive 5y ago
    > I guess if you don't pass your dependencies as an array to a function called useEffect, you aren't using hooks. Win! You joke, but yes. Also, you don't have to follow these. https://reactjs.org/docs/hooks-rules.html https://reactjs.org/docs/hooks-rules.html And you don't have to rely on the diff remembering which state goes to which widget. To its credit, it seems to do it right at least 99% of the time. I recognize I'm tilting at windmills here. React is a juggernaut, and many people love it. In fact, many people like the exact things that I don't. And that's ok.
    - jolux 5y ago
      You may not realize it but you're just rewriting hooks here. The example you give is too simple to show the problems with your initial approach. The main one is that if you're not extremely careful about when you're writing and when you're subscribing, you're going to end up with a race condition. Similar problems if you call "subscribe" in the wrong place. This is not a safe solution to the problem, and it does not circumvent the need for rules about usage.
      - recursive 5y ago
        I'm sure there are complexities that I hadn't considered yet, but I don't see how a race condition can be one of them. Outside of workers, there's really no way to simultaneous concurrency in js. Order of dispatch to subscribers seems like it create similar problems, although it would be fully deterministic, rather than a race. Anyway, thanks for your insight.