4 ms·

Hooks weren't invented because of 'this' complexity though, but rather as a better way to handle reuseable code (somewhat) akin to mixins.

• tenaciousDaniel 6y ago
  I'll see if I can find the link, but I recall seeing some references in the official docs, naming `this` complexity as a key inspiration for looking to hooks as an alternative to stateful classes.
  • grumple 6y ago
    That complexity was largely avoided by using arrow functions.
  • genezeta 6y ago
    It's right there in their intro to hooks in the section "Classes confuse both people and machines" [0]. [0] https://reactjs.org/docs/hooks-intro.html#classes-confuse-both-people-and-machines https://reactjs.org/docs/hooks-intro.html#classes-confuse-bo...
    • efdee 6y ago
      That is about a lot more than just 'this' confusion though.
      • runawaybottle 6y ago
        But focusing in on the ‘this’ criticisms highlights the general criticisms. They think ‘this’, or the Class model is a barrier to entry for React. React is a great framework, and super intuitive on so many fronts, but where it misses, it misses big. To come to the conclusion that the Class model, a pretty predictable pattern, is more a barrier to entry, or a conduit for confusion, is really misguided. Just take a look how simple functional components can take on a quasi Class-like form with lookup maps for hooks in this particular article. When you advocate for stuff like this, you are injecting the community with effectively bad practices. The React dev team can not resort to the ‘You probably don’t need ________’ article in perpetuity. At some point, they have to say to themselves - ‘We probably don’t need to add this to the API’.
        • efdee 6y ago
          I agree that the lookup map thing looks like very bad advice. I can't see a reason why you'd do something like that. On topic, it has been my understanding that the React team is moving away from classes for a number of reasons. Not just because it confuses people (although the pattern seems to create expectations that aren't met due to Javascript's weird 'this' behavior), but also because it doesn't have a good pattern for code reuse (as demonstrated by the lack of mixins that used to be popular in React's createClass syntax) and also because it seems to be a suboptimal pattern for compilers. That said, I've moved on from class components to function components with hooks and I can't remember the last time I thought something would be easier to implement as a class component, even though it is still an option to do so. But that is, of course, anecdotal.
      • genezeta 6y ago
        I was just providing the link.
    • petilon 6y ago
      I am far more confused by hooks than by classes and 'this'.
      • pier25 6y ago
        Also you can't really try to protect JavaScript developers from understanding this. It's a fundamental part of the language.
        • williamdclt 6y ago
          Disagree. I understand `this`, but I very, very rarely encounter situations where it doesn't mean the same thing as Java's `this`. When you work on a full-React codebase, it just doesn't really happen. We used to have weird `this` behaviour on event handlers, but arrow functions and hooks fixed this. Not saying it's good or bad, just an observation
          • pier25 6y ago
            Right, but without understanding this one doesn't really understand arrow functions either.
      • hombre_fatal 6y ago
        `this.foo = this.foo.bind(this)` and then the new feature of method properties `foo = () => this` vs `foo() { this }` are constant sources of confusion for people who aren't well-established in Javascript/this. Not to mention function() vs arrow functions. All exist because of the idiosyncrasies of `this` that you may be discounting because of your familiarity and already being over the learning curve that ensnares people daily.
• petilon 6y ago
  But that took the simplicity away. Everyone that knows modern JavaScript knows classes. Now they have to learn this alien concept called "hooks". Now regarding reusability: I have been doing UI code for many many years and I have rarely felt that logic inside UI components need to be reusable. First move all business logic out of UI components into model-layer objects. This eliminates most of the need for reusable logic in components. Then decompose your mega-components into simpler components. This removes all remaining need for reusable logic. If you still have reusable logic inside your component -- this is very rare -- allow some duplication of code, this is better than creating monstrous code that nobody understands.
  • thatswrong0 6y ago
    You're only calling it not simple because you're not familiar with it. I personally think hooks are simpler despite being different. Everyone knows "classes" but React's usage of them is not typical and there _are_ non-standard behaviors about using them that you have to learn when learning React (because the classes necessarily exist within the React runtime). Either way you're dealing with React. And on a day-to-day basis for me, there are still plenty of uses for reusable logic inside of components even after extracting business logic / creating small focused components, especially as it pertains to presentation. A simple example that I use somewhat frequently is a window-size watcher.. a pretty simple hook that watches the window-size, re-renders when it changes (on a debounce), and it provides the current width x height of the window, allowing the component to use those values to calculate some view parameters. With hooks, it's as simple as plopping `const { windowHeight, windowWidth } = useWindowSize()`. Without hooks it generally requires wrapping a component with another. I've been using hooks basically since they came out and IMO they're way more in tune with React's programming model than class-based components. Even if you create custom hooks for most components, the paradigm still encourages developers to encapsulate related pieces of component logic into their own hook-functions rather than spreading that logic across multiple lifecycle methods. I haven't come across a single situation where I would have preferred a class based component.
    • com2kid 6y ago
      The problem I have with hooks is that I see cool examples like the window size watcher, but when it comes to my own code I have: 1. Some stuff that happens when the component gets mounted 2. So local state that gets maintained (shown error text, whatever, red x, whatever) 3. Some stuff that happens when the component is unmounted. React classes fit 99% of my use cases. Yes HOCs to get navigation and stuff working is a pita. But honestly I'd have preferred a way to get the cool hook stuff added to class components instead of adding all the class component stuff to function components!
• kls 6y ago
  Mixin's where a bad idea as well, they where basically just multi-inheritance lite. In all honestly I have never seen a mixin accomplish something that could not be accomplished by single inheritance and wrapping a private instance that contains the functionality one want's from the mixin. Sure it's a little more boilerplate, but it's understandable, uncomplicated and none-magic boilerplate. I am not down on Hooks per-say but I am skeptical of magic and hidden effects caused by code outside of the visible flow of code. Sometimes the magic is awesome but sometimes it's just not worth the hassle.