Best way to ensure updated FormData in dispatchEvent after programmatic change

[Tjaitil]

Hello,

I'm learning svelte and enjoying the journey so far. I'm working with a custom select component where I'm hidding the native select and building my own UI select. This means I'm changing the state programmatically, and then dispatch the input / change event myself to make it act more like a native form element.

However I realised that adding a onchange on the form (or any other parent element) would read the previous value when constructing FormData since svelte hasn't updated the DOM (i.e Select element) yet.
Reason for using an onchange could be for instance a filter form.

I've come up with at least 2 options but wondering what is the best approach and most "svelte" idiomatic I guess.

	const choose = (x) => {
		open = false;
		if (x === value) return;

		value = x;
		// Without anything the change would produce a stale value when <form> onchange runs 
		// Option 1 - await tick() - would require async
		// - Drawback Would make the event.currentTarget = null for callbacks
		
		// Option 2 - select.value = value;
		// - Drawback Duplicate assignment of value
		
		// Option 3 - ?
		// Dispatch the custom events to let the form read it
		select.dispatchEvent(new Event('input', { bubbles: true })); 
		select.dispatchEvent(new Event('change', { bubbles: true }));
	}

Link to playground
The playground uses a select but this scenario relates to other components where the change happens programmatically.
Again I'm a beginner so any do's and don't would be highly appreciated.
Please don't hesitate to ask question if anything needs clarifying.

Thanks in advance!

[charan-rathore]

flushSync is an option if you want choose and the notifications to stay synchronous:

import { flushSync } from 'svelte';

const choose = (x) => {
  if (x === value) {
    open = false;
    return;
  }

  flushSync(() => {
    open = false;
    value = x;
  });

  select.dispatchEvent(new Event('input', { bubbles: true }));
  select.dispatchEvent(new Event('change', { bubbles: true }));
};

Changing value schedules a DOM update, but dispatchEvent() runs the parent listener synchronously. flushSync applies the bound select update before those events are dispatched, without a separate select.value = value assignment. The docs describe it as synchronously flushing pending updates.

I checked a small compiled Svelte 5.57.3 component in jsdom with a real select binding and a parent form handler reading new FormData(event.currentTarget). From an initial DOM value of a, choosing b and immediately dispatching the events read a without the flush, and b with it. These were separate mounts, so the flush case tested an actual changed DOM value.

await tick() before dispatching is also reasonable if you don't need synchronous notification. Making choose async does not by itself make event.currentTarget null in the synchronous form handler: that handler receives a new event when you dispatch it. currentTarget becomes null after that event's dispatch finishes. If the form handler itself awaits something, capture the element first:

const form = event.currentTarget;
await tick();
const data = new FormData(form);

So you can keep the parent handler synchronous with either approach. The choice is whether choose should wait for the normal update (tick) or flush it immediately (flushSync).

[Tjaitil]

Thanks for the detailed answer!

I completely agree with choose async event.currentTarget point. My wording was poor there. The point I was thinking of was if the component accepts an onChange event handler prop I would want to invoke after the value is updated.
Example

const choose = async (x) => {
  if (x === value) {
    open = false;
    return;
  }
  await tick();
  
  // Call onChange event handler prop - but event.currentTarget is null here because of await
  onChange(e);
  select.dispatchEvent(new Event('input', { bubbles: true }));
  select.dispatchEvent(new Event('change', { bubbles: true }));
};

Is there a preference between flushSync and await tick?. Seems to me that using await tick() is better since calling flushSync from a reusable component is a bit greedy since it forces an update for every pending update no matter the component? Might make the page a bit less performant? To me the docs isn't very clear on when one should use it or the gotchas with usage.

[charan-rathore]

That distinction makes sense. If you're forwarding the original event after await tick(), its dispatch has finished, so its currentTarget is null. flushSync lets a callback invoked before the first await still see it, but that is a timing contract the component would need to keep.

For a reusable component, I'd generally use tick() when the callback can wait. It lets Svelte batch the pending changes instead of forcing them to complete in the middle of the handler. flushSync is useful when you deliberately need the DOM and notification updated before the handler returns. It isn't scoped to that component, so your concern about flushing other pending work is valid. That doesn't mean it updates every component regardless of whether it has pending work, or that it is always slower. I wouldn't make a performance claim without measuring the actual page.

One detail: tick() isn't a component-local flush either. In the normal, non-experimental-async path in 5.57.3, it awaits a microtask and then calls flushSync() internally. The difference here is letting the scheduled update happen versus demanding it immediately, not local versus global updates. The API docs describe those timing guarantees.

For an onChange callback prop, you can avoid tying the API to the lifetime of the original DOM event. Pass the selected value and, if needed, the select element explicitly after the update:

value = x;
await tick();
onChange?.({ value: x, element: select });

That's a suggested callback shape, not a native event. If callers specifically need a native event whose currentTarget is the select, handle the newly dispatched change on the select instead. The original click event's currentTarget refers to the element handling that click, not necessarily the select.

I checked the two timing paths with compiled Svelte 5.57.3 in jsdom: the callback read the updated select/FormData in both cases; the original click's currentTarget was null after tick() and present during the synchronous flush path. A pending update in a separate mounted component also flushed immediately with flushSync. That's a behavior check, not a browser performance benchmark.

[tbhvishal]

Hi @Tjaitil! Welcome to Svelte!

This is a classic challenge when building custom headless form controls. The reason you are seeing stale FormData in the parent <form onchange> is that Svelte schedules DOM updates for bindings (bind:value), while native DOM event dispatching (dispatchEvent) executes synchronously.

Here is why your options behave the way they do, followed by the idiomatic solution:

---

Why the Initial Approaches Have Caveats:

• Option 1 (await tick()): As you noted, waiting for a microtask turns the handler asynchronous, which breaks synchronous form submission chains and clears event.currentTarget in native bubbling handlers.
• Option 2 (select.value = x duplicate assignment): While it feels like duplicate assignment, this is actually the standard headless UI pattern (used in libraries like Melt UI, Bits UI, and Radix). Because the DOM node is the source of truth for new FormData(form), setting select.value synchronously right before dispatchEvent ensures any listener reading the DOM immediately gets the latest value.

---

Idiomatic Solution 1: Svelte 5's flushSync (Cleanest)

In Svelte 5, you can use flushSync from 'svelte' to force Svelte to flush all pending reactive DOM bindings immediately and synchronously before you fire the events:

<script>
  import { flushSync } from 'svelte';

  let open = $state(false);
  let value = $state('');
  let selectEl;

  const choose = (x) => {
    open = false;
    if (x === value) return;

    // Synchronously flushes Svelte state into the bound <select> DOM element
    flushSync(() => {
      value = x;
    });

    // Now selectEl.value is guaranteed up-to-date for bubbling FormData listeners!
    selectEl.dispatchEvent(new Event('input', { bubbles: true }));
    selectEl.dispatchEvent(new Event('change', { bubbles: true }));
  };
</script>

<select bind:this={selectEl} bind:value class="hidden">
  <option value="a">A</option>
  <option value="b">B</option>
</select>

---

Idiomatic Solution 2: Direct DOM Sync + Reactive State

If you want zero dependency on flushSync, synchronizing the underlying DOM element directly and then updating Svelte state is completely safe:

const choose = (x) => {
  open = false;
  if (x === value) return;

  value = x;
  if (selectEl) {
    selectEl.value = x;
    selectEl.dispatchEvent(new Event('input', { bubbles: true }));
    selectEl.dispatchEvent(new Event('change', { bubbles: true }));
  }
};

Both methods guarantee that any parent onchange={(e) => new FormData(e.currentTarget)} reads the fresh value with zero race conditions!

[Tjaitil]

Thank you for the answer.
Given that this component might be in a component library it seems to be that it would be better to use await tick() with its caveat. Also as pointed out in the first component that calling the dispatchEvent on the the element wouldn't be itself make the currentTarget null. It is likely to happen if one would pass the event to another function.

Calling flushSync from a reusable component is a bit greedy since it forces an update for every pending update no matter the component. It is a gotcha for a new developers joining.

Looks like you are correct that ui libraries uses direct DOM assignments.