[spion]

> I had thought that maybe the framework could pass a more limited delegate for the instance to the constructor to prevent people from doing something silly with it, but that would prevent you from assigning a property safely anyway.

That seems like a good idea. I'll admit my illustration is not a fully fleshed out design, it was meant more to be a sketch of how it would be possible to make a class based design much more capable than the original one was.

> Any user-defined component using lifecycles will still need to have "constructor", "render", etc in the generated source

Ahh I got it - this is not about DCE but about minified names. Not sure why my mind went with dead code elimination.

My first gut feeling is that this wouldn't be as important for everyday users if they already have code splitting / DCE / gzip. I'll look up the video, would be interesting to see some numbers - I'm hoping thats part of the presentation.

> componentDidUpdate receives prevProps and prevState, and shouldComponentUpdate receives nextProps and nextState. How would you provide information about the previous or next version of that hook-based state if it's being tracked as an instance property rather than in the component's state object?

I'm giving up having a single component state with the new API - this class based hook API also allows you to have multiple states. So I'm going to focus on the props part.

In the hook constructor, you would be able to use a listener for componentUpdate:

  component.onUpdate((prevProps, props) => { run code });

You could also do something like

  component.watch(() => [otherHook.someValue(), this.someState.get()], () => {
    // callback
  })

to get render-time change detection (equivalent to `useEffect(fn, [otherHookValue, someStateValue])`).

Its all a bit wordier, no doubt, but I feel that most of the capabilities can be implemented.

[rimunroe]

I imagine most of them could be, but this is an API which would require a lot of additions to the existing React.Component API, and would end up duplicating a bunch of already-existing functionality for something which in the end would probably need to conform to the same rules hooks do, but with what certainly feel to me like clunkier ergonomics. You'd also still be left with the problems of class components like poor minifiability and unreliability for hot module replacement.

I have to go to bed, but if you'd like to see a much better explanation about why hooks were adopted, I highly recommend the [checks notes] 1,401 comment-long discussion[1] on the PR for adopting the hooks RFC back in 2018, as this sort of design was brought up frequently. Especially worthwhile is Sebastian Markbåge's ending summary about why the team was going with hooks[2].

[1] https://github.com/reactjs/rfcs/pull/68 [2] https://github.com/reactjs/rfcs/pull/68#issuecomment-4393148...

[spion]

I was trying to discuss the merits or demerits of hooks overall - just wanted to point out that a class based design doesn't need to be significantly less powerful or HoC-level awkward to use.

(I can't resist commenting I suppose - I did follow that thread as much as time permitted back then, and I couldn't agree with the conclusion from the arguments presented. Specifically, I was unconvinced that dispatch performance and file size were that dramatically different. In my experience, classes are very efficient in modern engines and code-splitting means much more than minification, especially after gzip. Even if they are the right trade-offs for Facebook, its unclear whether they're the right trade-offs for the rest of React users and the community as a whole - from my experience it has errected a bit of a barrier to front end work for backend engineers because there is a steep and weird learning curve at the start)