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.
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.
That's represented in one of these principles.
Of course that doesn't help if you're still pulling in a lot of hooks, since it's 1 line per hook minimum.
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.
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.