CustomElement $effect caused due to props read

[satouriko]

Describe the bug

Reading sub-component's prop in eventListener causes sub-component's $effect getting triggered.

<script lang='ts'>
  $host().addEventListener('change', () => {
    $host().querySelectorAll('my-custom-element').forEach((el: any) => {
      // Simple read causes $effect to trigger
      el.value;
    });
  })
</script>

See Reproduction for detail.

Reproduction

https://github.com/satouriko/svelte-effect-bug
Typing in the first input, it triggers the $effect of itself, that's good.
While then type in the second, it triggers the $effect of both itself and the first one.
Then type in the third one, it triggers all the three $effects.
That's weird. Why reading properties cause $effect?

2024-08-09.14.16.59.mov

Logs

No response

System Info

Svelte 5.0.0-next.210
'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36'

Severity

annoyance

[trueadm]

So looking into this deeply. This isn't a bug, but intended behaviour.

If you don't want the effects to update on the read, you need to wrap the dispatch in an untrack, this will prevent the effect from capturing the read of each of other other el.value reads and thus preventing the reads from becoming dependencies.

[satouriko]

@trueadm From my understanding,

let's say we have

<root-custom-element id="root">
  <my-custom-element id="1"></my-custom-element>
  <my-custom-element id="2"></my-custom-element>
  <my-custom-element id="3"></my-custom-element>
</root-custom-element>

First on mounted,

• (#1).$effect depends on (#1).value
• (#2).$effect depends on (#2).value
• (#3).$effect depends on (#3).value

now (#1).value updates, triggers (#root).eventListener, and that reads all sub-elements' value, so at this time,

• (#1).$effect depends on (#1).value
• (#root).eventListener depends on (#1).value
• (#2).$effect depends on (#2).value
• (#root).eventListener depends on (#2).value
• (#3).$effect depends on (#3).value
• (#root).eventListener depends on (#3).value

now (#3).value updates, only (#3).$effect and (#root).eventListener should get run. Why does it triggers (#1).$effect as its dependency (#1).value didn't change?

Is it by designed that reading a property also triggers those effects depends on it? That doesn't make sense.

[satouriko]

And I still have a question on this,

Given each custom element mounts one after another, the 2nd one will know of the 1st and the 3rd will know of the other two.

If that's the case, i.e. the effect dependencies depend on the mounting order, wouldn't the $effect in the 1st and the 2nd run if I update the 3rd as soon as the page loads? But it actually isn't, the fact is

If you update the 3rd one then update the 1st, you'll see that the 3rd on triggers itself only but the 1st one triggers the effects of both.

So I think an explanation to this probably should be the effect dependencies get updated during the event listener of the root element triggers, not on mounting.

[satouriko]

Dispatching an event synchronously which means that the effect is reading el.value and thus becoming a dependency of the same effect.

I got it now. I guess I'd better wrap dispatchEvent inside untrack or setTimeout otherwise something unexpected would happen.

[trueadm]

I think there is a bug here though, so will investigate it. We are flushing each web component individually, which might not be right here. Essentially the problem is this:

• There are two custom elements, root-element and my-element. There are two my-elements inside root-element and they contain an $effect that dispatches a change event to the parent.
• The root-element has a change event listener that is added in the render phase and is meant to capture the mount of its children, but it doesn't. This is because the child components run first (expected) but their effects, which normally run after a microtask, flush sync and thus before the parent has added the event listener.
• Thus now the parent doesn't know of its children until you change the input – which means that the dependencies get build incrementally causing the odd issues you're seeing.

If we don't flush the children effects sync, then everything works as intended – changing one thing causes 3 effects to run each time.