[2Pacalypse-]

I'd be interested to hear a practical example of these principles applied. For example, how do these principles lead to the creation of hooks API? I'm not trying to say they don't, just genuinely curious.

As someone who has been using React for five years and especially liked it for its simple class API to write components, I was a bit taken aback by the introduction of a new powerful API that is incompatible with the simple class API.

[sb8244]

I feel that hooks make it easy to go from functional component (simplest way to get started) to stateful component without "rewriting" it to the class. It's easy to do that rewrite, but painful when you have to do it back and forth as you're playing around with component design.

That's represented in one of these principles.

[ben_jones]

I've found several "subtle" benefits from hooks in the way they can influence more idiomatic code structure, for example "code smell" becomes more intense and dictates more actions because when a function is > 100 lines of code it sticks out like a sore thumb. It's also influenced us to put more business logic into redux where (arguably) it belongs.

[sb8244]

My coworker showed me that hooks are just functions, so you can still pull apart your functional components hooks into a bunch of imported or defined functions.

Of course that doesn't help if you're still pulling in a lot of hooks, since it's 1 line per hook minimum.

[acemarke]

The primary point of hooks was to give function components the same capabilities that classes already had. In that respect, letting classes use hooks would have been superfluous.

At the same time, the React team _could_ have chosen to implement support for hooks in classes, but chose not to, both for simplicity and as a carrot to encourage folks to use function components where possible. Based on the discussions and examples I've seen, capabilities like Concurrent Mode and Fast Refresh work better with function components because there's fewer edge cases to worry about. While classes aren't going away in the foreseeable future, there's valid reasons to try to get the community to adopt function components more.

[2Pacalypse-]

Well, as far as my understanding of hooks go, and please do correct me if I'm wrong, hooks are not just about giving functional component an option to use state and lifecycle methods. They are also a much more powerful and flexible replacement of mixins and offer an (arguably better) alternative to use certain design patterns, like render props.

I did assume that hooks were not supported in classes because it would be too complex to support that use-case, but the linked article specifically has an "Absorb the Complexity" principle, so it seemed a bit weird to me. Also, I understand the decision to try to motivate the community to use function components more, but is this the trend that we can expect to continue seeing in React? Certain APIs being phased out until they finally become deprecated. I know it has happened a few times already in React, but not on the level of something like a class API.