ok, so no point then?

because I feel like I'm just not getting it

I think just adding a few nice life cycle events would achieve all the things that hooks currently make easier

"all the things" = the use cases I've seen so far that are less verbose with hooks vs. life cycle events

i think that hooks can be good only for composition

I think it's not worth a flamewar.

@francescoagati do you have an example of composition with hooks that can't be easily done with classes?

https://rangle.io/blog/refactor-to-react-hooks-not-classes/

but i think that in many case class and hooks are equivalent

yeah, I mean the problem is simply that react life cycle events are not very well designed and instead of improving that, React team seems hell-bent to not use classes because FP is the solution to everything This is the proposed method:

js
export function Layout(props) {
  const [isSidebarExpanded, setSideBarExpanded] = useState(true);

  function handleRouteChange(url) {
    setSideBarExpanded(true);
  }

  useEffect(function routeChangeComplete() {
    Router.events.on('routeChangeComplete', handleRouteChange);
    return () => Router.events.off('routeChangeComplete', handleRouteChange);
  },[]);
  // ...

Here's the same in coconut with evil, evil classes:

haxe
class Layout extends View {
  @:state isSidebarExpanded:Bool = true;

  function handleRouteChange(url) {
    isSidebarExpanded = true;
  }

  function viewDidMount() {
    Router.events.on('routeChangeComplete', handleRouteChange);
    beforeUnmounting(() -> Router.events.off('routeChangeComplete', handleRouteChange));
  });
  // ...

This could practically look exactly the same in React, if they were to work a bit on the life cycle events

Hooks are a pure JS solution which doesn't require fancy compiler magic - only a lot of React magic :D

(and a lot of closures garbage to collect)

The JS community loves to hate classes.

js
class Layout extends Component {
  state = { isSidebarExpanded: true };

  handleRouteChange = (url) => this.setState({ isSidebarExpanded: true });

  componentDidMount() {
    Router.events.on('routeChangeComplete', handleRouteChange);
    this.beforeUnmounting(() -> Router.events.off('routeChangeComplete', this.handleRouteChange));
  }
  // ...

well, that's kind of the problem ^^

the thing that really revolts me about hooks is that they're inherently impure

Yep I dislike that too

I like your

beforeUnmounting

BTW.

thanks ;)

actually, it works best with tink signals, which return a cancellation token ... so you can go straight

untilUnmounted(Router.routeChanged.handle(handleRouteChange))

I think a big source of mess is all those

componentWillMount

,

componentWillReceiveProps

,

componentDidUpdate

well, all but the 3rd were killed

and the fact you can't call

setState

in the constructor so you can't reuse the same initialisation logoc

what happens when you call setState? ^^

you get an exception I believe

nice

so they handle the case where you make your own constructor and forget to pass props to super, but when you call setState in there, they hit you with the stick ... well played :D

Well in the constructor you may want to use your props to set the initial state, then when the props change... you need some other logic to change your state.

This is all really broken from the start

Other issues are around tracking that your component is still mounted when async operations complete.