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

child cleanup bug #22

Open
luwes opened this issue Jan 20, 2023 · 2 comments
Open

child cleanup bug #22

luwes opened this issue Jan 20, 2023 · 2 comments

Comments

@luwes
Copy link

luwes commented Jan 20, 2023

just wanted to let you know @fabiospampinato found out there is a signal cleanup bug with using the standard JSX transform
https://twitter.com/luwes/status/1574536326418149376

fixing it in this lib would probably mean using the same approach as Voby.
having a render() function and resolving a tree of closures.

I put together this Codesandbox showing the bug in Haptic
https://codesandbox.io/s/try-haptic-0-10-forked-j4bn6t?file=/src/index.tsx

luwes added a commit to luwes/sinuous that referenced this issue Jan 20, 2023
@nettybun
Copy link
Owner

Neat thanks for sharing! I'd never passed children that way, but it makes sense: <Parent children={<Child/>} /> would be similar but more clearly not-nested and therefore not-associated for cleanups... I'll think about this.

@mindplay-dk
Copy link

I've been thinking about this for years now, I've tried to approach several different developers about this issue.

From my point of view, the root cause of this problem is the standard (React) JSX transform, which just isn't very suitable for reactivity overall. Frameworks such as Solid go the extra mile of maintaining their own custom transform - which isn't great either, as this ties you to a particular compiler, and there are so many of those now.

Would you guys be at all interested in trying to define a new "standard" transform designed for reactivity? 🤔

My thinking here is really half baked, but essentially, children would be a function, and any JSX expression that might be dynamic would be transformed into a function as well - so effectively, anything dynamic would be deferred, removing control from the JSX expression itself, instead delegating control from the framework to the JSX expressions.

I think the strength of the React transform is it's very simple, easy to explain and understand - my hope is that a new transform designed for reactivity could remain relatively simple, so as to attract support by various compilers, creating more common ground among reactive frameworks, and a more fluent end user experience, e.g. fewer closures.

I would love to see people like you two, along with Ryan and Fabio rallying around this. 💪😄♥

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants