First rendering when dispatch in reactivity expression

[ruslan-khomiak]

If we use dispatch in a reactive expression, when the component is first rendered, the dispatch event will not be handled. But if you do the same with onMount, it will work. I fixed it with await tick() before dispatch in reactivity expression. But I don't understand the bug is this or not.
What do you think of it? I didn't find anything like this in the documentation.

REPL reproduced bug with reactive expression: https://svelte.dev/repl/1055153bb575466cbcd91f38af019d1c?version=3.25.1

REPL solution with await tick: https://svelte.dev/repl/2864c5f152b14e6988328045b61f72ac?version=3.25.1

REPL everything is works with onMount: https://svelte.dev/repl/33c316946a0e4f97bbc899af151c6407?version=3.25.1

[Conduitry]

Duplicate of #4470.

[TylerRick]

In other words, this issue is about how to postpone dispatching an event containing the initial value from the Child2 component until its parent component has mounted.

Thanks for the await tick() idea. Not sure I would have thought of that solution to this problem.

---

To clarify, for future readers, the 3rd REPL as is isn't actually "everything working" in the same way that the 2nd REPL is. To have it dispatch an event for both the initial value and any changes from that initial value, you would need to have a reactive $ as well as the onMount that it already has. See updated REPL:

 	onMount(handleOptionChange)
	$: { handleOptionChange(); option }

But that has 2 downsides that I can see:

1. It dispatches a duplicate event on first render — the initial one from the $: being the one that gets dispatched before parent has registered its listener. (Not sure how this could be a problem in practice, but still seems unfortunate.)
2. it is more verbose than the await tick() trick.

So, it seems like the await tick() option is the best workaround for this problem. Are there any downsides to doing it that way? Like maybe it could cause changes to not show up immediately in certain cases because it waited until after the render was complete to dispatch?

It's hard to believe this is really the intended behavior. It just seems unintuitive and easy to forget that this is needed. Will re-read #4470 to try figure out why the current behavior might be desired/intended, but so far, I can't understand why this behavior would be desirable.