Hooks offers nothing new over HoC and FaC the same way React offered nothing new over jQuery and EmberJS.

> Hooks offers nothing new over HoC and FaC

You've missed the point entirely. Hooks offer nothing new because their functionality was already implemented in React class components.

They literally add no functionality to React. The docs actually state quite clearly that developers are discouraged from replacing class components with function components.

"No new functionality" and "nothing new" are two different things. Improved developer experience, decreasing the surface area of bugs, etc - all examples of definite improvements that are not technically new functionality.

And what do you think React can do that jQuery cannot? Heck, what do you think React can do that standard HTML5/JS API cannot do?

React doesn't offer new functionality to do UI. It offer new ways to think about the problem.

Hooks doesn't offer any new functionality over `this.state` and component life cycle, it offser new way to think about the problem.

> And what do you think React can do that jQuery cannot?

Again, you've missed the point.

How did you extract concerns from class components and reuse them previously? Easy and hygienic extraction and composability of concerns literally is something new enabled by Hooks that was not offered by class components.

You're also misrepresenting what the docs say about replacing class components. They're saying that you don't need to replace class components just for the sake of using 'the new thing'. However if there was some concern you wanted to extract from a class component that you could not previously, you absolutely could adapt it to use hooks, and then extract and reuse that concern in another component.

> The docs actually state quite clearly that developers are discouraged from replacing class components with function components.

Could you link to where it says this? My understanding is that hooks are intended to be the new best practice, and ideally all code would use hooks (which the React team believes are overall better than class components), but the React team doesn't want to force migration pain on everyone. So as I understand it, it's not that a class -> hook refactor is "discouraged", it's more "don't let this be too much of a distraction, and don't feel obligated to rewrite old code".

You're being sarcastic but there are enough people around who wouldn't see that at face value.

That is being unfair to React.

React changed the way developers reason about UI/DOM from imperative to declarative, the holy grail here is that a declarative API allows you to move up your state and have a "single source of truth" and so makes it easy to reason about your application's state at the cost of having more plumbing, for example consider incriminating the value of an input with jQuery (imperative) vs React (generally with Redux).

What Hooks does is move the component's state management from components root a level deeper into hook functions and advocates for reusable state management functions that manages various fragments of your component's state, this I believe is a step backwards in terms of simplifying how you reason about state management in terms of complexity --not lines of code.

I am just not sure if this abstraction is worth it in practice and a good step for React.

You misunderstood the parent.

I got the sarcasm, but comparing what Hooks brings to table to what React did is unfair. Hooks are moving around state management, React was a paradigm change.