4 ms·

> That said, the React docs are pretty clear about the motivation for hooks and I think that is a good place to start: https://reactjs.org/docs/hooks-intro.html

> That said, the React docs are pretty clear about the motivation for hooks and I think that is a good place to start: https://reactjs.org/docs/hooks-intro.html#motivation https://reactjs.org/docs/hooks-intro.html#motivation. I've read this a number of times, and none of the point make sense to me. > It’s hard to reuse stateful logic between components Is there some reason you can't use a `get(key)` and `set(key,value)` between class components. I don't really grok react, despite trying, so maybe there's a reason that doesn't work. > Complex components become hard to understand I don't understand what the hard part is supposed to be here. If you have a method that's dealing with too many concerns, you can just add methods, and then call those. > Classes confuse both people and machines `this` is pretty confusing in javascript, but yet that's the language react is targeting. And it's no less confusing in prototype-based objects. And after having tried to learn both hooks and `this`, it certainly doesn't seem like hooks are conceptually easier than `this`. Probably my fundamental problem with hooks is trying to understand which state goes with which component-function invocation. It just seems like dark magic that usually works. I've tried to read the implementation to figure it out. It seems to depend on the famous DOM diff feature. It was about at that point that I lost the plot. So, I know I'm an outlier, but class-based components just make sense to me. They can be complex, but fundamentally comprehensible. Function components seem like a fake simplicity that's masking a complexity that I've yet to figure out.

srcreigh 5y ago
> Is there some reason you can't use a `get(key)` and `set(key,value)` between class components. I don't really grok react, despite trying, so maybe there's a reason that doesn't work. You can and the hooks way is better. The class based components way is to wrap component in a HOC. The common state is stored in the HOC. The HOC passes the state to the component via props. This can include functions, so maybe your component can call `this.props.reloadApi()`, which changes HOC state, which results in new props sent to your component. The hooks way is described here. [0] What's wrong with Higher-Order Components? One answer is that it's weird to call something a "component" which doesn't render any UI. In other words, why is an interface to access remote data a "component"? Another answer is that HOCs break the diff algorithm without special care see. [1] [0]: https://reactjs.org/docs/hooks-custom.html https://reactjs.org/docs/hooks-custom.html [1]: https://reactjs.org/docs/higher-order-components.html#dont-use-hocs-inside-the-render-method https://reactjs.org/docs/higher-order-components.html#dont-u...
- recursive 5y ago
  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.
imbnwa 5y ago
To better understand the move away from OO interfaces, and mixins for behavior sharing, first read 'Mixins Considered Harmful'[0], then for a counter point read 'Why are Mixins Considered Harmful?'[1], then the follow-up that POCs a mixin implementation that responds to the issues raised about mixins[2] [0]https://reactjs.org/blog/2016/07/13/mixins-considered-harmful.html https://reactjs.org/blog/2016/07/13/mixins-considered-harmfu... [1]http://raganwald.com/2016/07/16/why-are-mixins-considered-harmful.html http://raganwald.com/2016/07/16/why-are-mixins-considered-ha... [2]http://raganwald.com/2016/07/20/prefer-composition-to-inheritance.html http://raganwald.com/2016/07/20/prefer-composition-to-inheri...

srcreigh 5y ago

> Is there some reason you can't use a `get(key)` and `set(key,value)` between class components. I don't really grok react, despite trying, so maybe there's a reason that doesn't work. You can and the hooks way is better. The class based components way is to wrap component in a HOC. The common state is stored in the HOC. The HOC passes the state to the component via props. This can include functions, so maybe your component can call `this.props.reloadApi()`, which changes HOC state, which results in new props sent to your component. The hooks way is described here. [0] What's wrong with Higher-Order Components? One answer is that it's weird to call something a "component" which doesn't render any UI. In other words, why is an interface to access remote data a "component"? Another answer is that HOCs break the diff algorithm without special care see. [1] [0]: https://reactjs.org/docs/hooks-custom.html https://reactjs.org/docs/hooks-custom.html [1]: https://reactjs.org/docs/higher-order-components.html#dont-use-hocs-inside-the-render-method https://reactjs.org/docs/higher-order-components.html#dont-u...

recursive 5y ago
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.

imbnwa 5y ago

To better understand the move away from OO interfaces, and mixins for behavior sharing, first read 'Mixins Considered Harmful'[0], then for a counter point read 'Why are Mixins Considered Harmful?'[1], then the follow-up that POCs a mixin implementation that responds to the issues raised about mixins[2] [0]https://reactjs.org/blog/2016/07/13/mixins-considered-harmful.html https://reactjs.org/blog/2016/07/13/mixins-considered-harmfu... [1]http://raganwald.com/2016/07/16/why-are-mixins-considered-harmful.html http://raganwald.com/2016/07/16/why-are-mixins-considered-ha... [2]http://raganwald.com/2016/07/20/prefer-composition-to-inheritance.html http://raganwald.com/2016/07/20/prefer-composition-to-inheri...