Repository navigation
HyperScript engine does not work properly with For #2453
Description
Describe the bug
Function "For" in HyperScript mode loses connection with signals when list changes.
Your Example Website or App
Steps to Reproduce the Bug or Issue
- Click "add"
- Click "demo"
Expected behavior
Here is correct behavior using TSX:
https://playground.solidjs.com/anonymous/9392c73a-cd81-4260-9f23-508104380960
Screenshots or Videos
No response
Platform
- OS: macOS
- Browser: Vivaldi
- Version: 7.0.3495.29
Additional context
I have also checked html`` function, it works as expected (https://playground.solidjs.com/anonymous/5e9b68a0-5d8f-4f30-8ec3-d4c8fb24f766).
The closest solution is to wrap children in function (https://playground.solidjs.com/anonymous/32865f62-3ba6-45f3-a0a1-e8bc9adced6a),
but in this case Solid redraws all children everytime I add new element in array, which is undesired behavior.
Activity
[-]HyperScript engine does not properly with For[/-][+]HyperScript engine does not work properly with For[/+]ryansolid commentedon Mar 27, 2025
Thanks yeah I can reproduce. I made some pretty heavy changes to HyperScript a couple years ago to handle Context + Fragments and while it worked then, over time we have been optimizing away unnecessary wrappers in Solid core and it turns out HyperScript is the only renderer that needs them. I want to re-evaluate this solution on a whole because basically the reactivity leaks upwards here in a way that is more or less prevented by our JSX compiler and
htmlfunction.The gist of it is that we defer evaluation here and it leads to render effects being created in the parent context instead of inside the For which means when the parent insert re-runs it inadvertently releases the render effects on the other divs. Given my current understanding of how these things should work this is all wrong.
mizulu commentedon May 1, 2025
https://playground.solidjs.com/anonymous/0392c578-9678-474a-b500-e2d31f64ad70
but this over renders
titoBouzout commentedon May 1, 2025
For references there are a bunch of messages and a thread about this in https://discord.com/channels/722131463138705510/780502110772658196/1367529419052285982
https://discord.gg/solidjs invite if you need
ryansolid commentedon Apr 24, 2026
I did a half measure and it didnt work. The tension was I wanted to preserve how Solid returns real DOM Elements while still ensure things ran in the right context order. I tried to keep both qualities but they are at odds with each other when it comes to ownership.
This is in a really awkward place for 1.0. Either I have to make a complete breaking change(don't return DOM Elements) or revert the half measure which is also breaking(out of order execution, missing Context lookup). Although atleast the order is fixable if the user remembers to always wrap children in thunks.. but that can be very unergonomic. I'd be more leaning to undoing the change on 1.0, but I'm also tempted to leave as is.
I've fixed this in 2.0 with the breaking design that doesn't return real DOM Elements. It's the only reasonable thing to do here.
fix(hyper): rewrite h() as lazy tagged thunks to fix For-ownership bug