Updating onchange causes sibling to mount/unmount #1742

Activity

1. ryansolid commented on May 31, 2023

   

   ryansolid

   on May 31, 2023

   Member

   More actions

   As event handlers aren't tracked the function call is being tracked by the parent scope. Which would result in exactly what you see. Intentionally so. That's how Solid renders by nesting reactive contexts.

   This is interesting case in that I can see why that wouldn't be desirable it is also not a really detectable error. The compiler I suppose could untrack in this specific case. It could also support dynamic event handlers, although that de-opts the super common case (props.onClick) when calling it yourself would be more performant. But admittedly the fact it isn't obvious that this is an error is more problematic than the fact that this is not allowed. This is definitely a place that could use improvement.

   If we had a strict mode, we could make this an untrack that warned on access. That's probably the best solution outside of measuring the comparable overhead of dynamic event addition/removal.

   Short term response is that dynamic event handlers aren't supported (https://www.solidjs.com/docs/latest/api#on___). But I think this definitely should be a consideration around good error message handling.
2. ryansolid

   added

   enhancementNew feature or requestNew feature or request

   on Jun 26, 2023
3. ryansolid commented on Oct 13, 2026

   

   ryansolid

   on Oct 13, 2026 – with Claude

   Last edited by ryansolid

   Member

   More actions

   Status on 2.0: the original repro still reproduces. Inside a conditional branch ({cond && <>…</>}), the branch's JSX is built in a tracked scope. So a handler factory called at the callsite (onChange={generateOnChange()}) that reads a signal re-creates the branch and its sibling components, and no dev warning fires. When the same mistake is made through a component prop, 2.0 does report STRICT_READ_UNTRACKED in dev. The workaround is to wrap the call in untrack, or to read the signal inside the returned handler.

   (This issue was briefly closed by mistake and has been reopened. Whether to change anything here is still undecided.)

   — Claude via Claude Code

   ---

   Generated by Claude Code
4. ryansolid

   closed this as not plannedon Oct 13, 2026
5. ryansolid

   reopened this on Oct 13, 2026