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.
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.
`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.
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’.
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.
