Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🔷 [Epic] Hooks support (excludes advanced hooks) #23

Closed
2 tasks done
mpeterdev opened this issue Aug 11, 2023 · 4 comments
Closed
2 tasks done

🔷 [Epic] Hooks support (excludes advanced hooks) #23

mpeterdev opened this issue Aug 11, 2023 · 4 comments

Comments

@mpeterdev
Copy link
Collaborator

mpeterdev commented Aug 11, 2023

Support Preact hooks e.g. useEffect and useState

Tasks

  1. andy-haynes
@andy-haynes
Copy link
Contributor

Support for hooks in general should be possible, though I haven't been able to sort out the issues yet. The current implementation relies on a custom Preact bundle into which a function call is injected into the render method. However this raises compatibility issues with the Preact hooks bundle, which is offered as a separate bundle.

The issue seems to revolve around a null reference on vnode._component in the core hooks functionality (TypeError: Cannot read properties of null (reading '__H')). Based on how it's referenced in the Preact code, this seems to be crucial to managing Component lifecycle. My working theory is that the hooks are somehow decoupled from the Preact Component context/scope; by introducing an inlined custom bundle the assumptions around Component lifecycles are now broken.

I did try to rebuild the custom bundle with hooks as a core dependency, but the error was the same so I am not convinced it's an issue with library interop as most reported issues would suggest. Next steps will be to debug using non-minified bundles to trace the issue and understand the larger problem. In theory there's nothing stopping us from attempting our own hooks implementation but I don't think this should be discussed until the underlying issue here is understood. 🙂

It is possible that this is the indication that inlining the Preact bundle in the iframe container is not a viable solution and requires a more sophisticated approach to intercepting (P)React renders.

@JoviDeCroock
Copy link

JoviDeCroock commented Sep 12, 2023

A prerequisite to getting hooks or any other Preact extensions (i.e. signals) to work is to have a stable reference to the options export from Preact... The most likely cause for this to error out would be by having multiple Preact instances in your bundle. Inlining Preact into an iframe can be done but the hooks implementation should use the options export from said inlined variant.

Putting this into practice, you have an inlined Preact however if you now want to add hooks it would need to use the export from that bundle. An alternative would be to use a CDN to supply you with the code or use the var l which in your inlined variant refers to options as you can see by i.e. looking for .vnode which is one of our option hook invocations.

@andy-haynes andy-haynes self-assigned this Sep 25, 2023
@mpeterdev mpeterdev changed the title useRef support Hooks support Sep 28, 2023
@mpeterdev mpeterdev changed the title Hooks support 🔷 [Epic] Hooks support Oct 10, 2023
@mpeterdev mpeterdev added the Epic label Oct 10, 2023
@mpeterdev mpeterdev changed the title 🔷 [Epic] Hooks support 🔷 [Epic] Hooks support (excludes advanced hooks) Oct 10, 2023
@andy-haynes
Copy link
Contributor

@JoviDeCroock thank you for taking the time to look at the code and weigh in on this! Your comments helped me figure out how to stop abusing the library and better utilize options, which ultimately led to me finding the root issue (invoking the component function directly 😅)

@andy-haynes
Copy link
Contributor

useState and useEffect supported as of #83

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Status: Todo
Development

No branches or pull requests

3 participants