> 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.