Except in the real world opinionated leads and team members forced teams to adopt ONLY hooks going forward, or have to maintain two separate implementations - hook compatible or class component compatible code.
So yes, this is a very sensible concern that transpired with hooks. Simply allowing reverse compatibility doesn't change the fact that hundreds of workplaces forced people to use a less ideal paradigm.
> Except in the real world opinionated leads and team members forced teams to adopt ONLY hooks going forward, or have to maintain two separate implementations - hook compatible or class component compatible code.
That isn't React's fault. Your opinionated team members can enforce all kinds of nonsense. This is a general argument against ever introducing new features in any framework or language, and it's not valid.
> So yes, this is a very sensible concern that transpired with hooks. Simply allowing reverse compatibility doesn't change the fact that hundreds of workplaces forced people to use a less ideal paradigm.
"Less ideal paradigm" is an opinion. There are use cases where hooks make perfect sense and are superior to class components.
And again, what your employer and teammates do doesn't implicate React or the React team! They could have enforced Hooks on all components, and dropped support for the old APIs. What should they have done differently? NOT released an optional feature that is loved by millions of their users, just so none of those users can interrupt your ideal workflow? How entitled can you be?
So yes, this is a very sensible concern that transpired with hooks. Simply allowing reverse compatibility doesn't change the fact that hundreds of workplaces forced people to use a less ideal paradigm.