search

nettybun / haptic

Explicit reactive web rendering in TSX with no compiler, no virtual DOM, and no magic. 1.6kb min+gz.
MIT License
79 stars 2 forks source link

child cleanup bug #22

Open luwes opened 1 year ago

luwes commented 1 year ago

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

nettybun commented 1 year ago

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 commented 1 year ago

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. 💪😄♥