4 ms·
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
by 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 agoThat complexity was largely avoided by using arrow functions.
- genezeta 6y agoIt'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 agoThat is about a lot more than just 'this' confusion though.
- runawaybottle 6y agoBut 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 agoI 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 agoI was just providing the link.
- petilon 6y agoI am far more confused by hooks than by classes and 'this'.
- pier25 6y agoAlso you can't really try to protect JavaScript developers from understanding this. It's a fundamental part of the language.
- williamdclt 6y agoDisagree. 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 agoRight, 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.