$effect.pre doesn't work properly if created on mount.

[HighFunctioningSociopathSH]

Describe the bug

$effect.pre runs late and after the DOM is updated if it's initialized in onMount or Actions or Attachments.

Reproduction

Take the following code,

<script lang="ts">
  let node = $state<HTMLDivElement>();
  let colors = $state(["red", "blue"]);
  $effect.pre(() => {
    if (!node) return;
    colors ;
    console.log("$effect.pre", Array.from(node.children));
  });
  $effect(() => {
    if (!node) return;
    colors ;
    console.log("$effect", Array.from(node.children));
  });
</script>

<button
  onclick={() => {
    colors = colors.toReversed();
  }}
>
  change
</button>

<div bind:this={node}>
  {#each colors as color, i (color)}
    <div id={color === 'blue' ? "blue" : ""}>
      {color}
    </div>
  {/each}
</div>

Whenever I change the colors array, the $effect.pre and $effect run properly since $effect.pre logs the children as they were before the change occurs, since it's supposed to run before the DOM updates.
But if you put those effects inside an onMount or an Action or Attachment, the $effect.pre also logs the same output as the $effect, and you miss the snapshot of the DOM before the change.

<script lang="ts">
  let node = $state<HTMLDivElement>();
  let colors = ["red", "blue"];
  onMount(() => {
    $effect.pre(() => {
      if (!node) return;
      array;
      console.log("$effect.pre", Array.from(node.children));
    });
    $effect(() => {
      if (!node) return;
      array;
      console.log("$effect", Array.from(node.children));
    });
  });
</script>

<button
  onclick={() => {
    colors = colors.toReversed();
  }}
>
  change
</button>

<div bind:this={node}>
  {#each colors as color, i (color)}
    <div>
      {color}
    </div>
  {/each}
</div>

This also doesn't work in the playground, so I can't provide a REPO, but it hints that maybe it has something to do with the $effect.pre not going through the server-side code, since putting it in onMount or using playground skips server-side analysis.

Logs

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (16) x64 12th Gen Intel(R) Core(TM) i7-12650H
    Memory: 6.32 GB / 15.63 GB
  Binaries:
    Node: 23.11.0 - C:\nvm4w\nodejs\node.EXE
    npm: 11.4.1 - C:\nvm4w\nodejs\npm.CMD
    pnpm: 10.13.1 - C:\nvm4w\nodejs\pnpm.CMD
  Browsers:
    Edge: Chromium (136.0.3240.64)
    Internet Explorer: 11.0.26100.1882

Severity

blocking all usage of svelte

[paoloricciuti]

Wdym with it doesn't work in the playground? The bug it's not there?

Neither on mount, $effect or $effect.pre are on the server so it's definitely not that issue. Do you have async enabled locally? Does it work if you enable it?

[HighFunctioningSociopathSH]

@paoloricciuti I meant the bug is in the playground as well, even without putting the $effect.pre inside anything.
In the REPO You don't even need to put the $effect.pre inside the onMount or Attachment for it to fail its timing.

[HighFunctioningSociopathSH]

I don't have the async flag enabled

[paoloricciuti]

This seems to be a problem after async was released but it is a documented one, and I can't reproduce without async turned on. Can you provide more insight?

[HighFunctioningSociopathSH]

@paoloricciuti I'm sorry, but I really don't know what else to add.
on the current version, svelte@5.37.3,
running the following code and clicking the button =>
+page.svelte

<script lang="ts">
  let node = $state<HTMLDivElement>();
  let colors = $state(["red", "blue"]);
  $effect.pre(() => {
    if (!node) return;
    colors;
    console.log("$effect.pre", Array.from(node.children));
  });
  $effect(() => {
    if (!node) return;
    colors;
    console.log("$effect", Array.from(node.children));
  });
</script>

<button
  onclick={() => {
    colors = colors.toReversed();
  }}
>
  change
</button>

<div bind:this={node}>
  {#each colors as color, i (color)}
    <div id={color === 'blue' ? "blue" : ""}>
      {color}
    </div>
  {/each}
</div>

will result in the following log =>

$effect.pre (2) [div.s-y_bCXRrkrYfP, div#blue.s-y_bCXRrkrYfP]
$effect (2) [div#blue.s-y_bCXRrkrYfP, div.s-y_bCXRrkrYfP]

This is the correct behavior; Notice how the positions of the 2 divs are different between $effect.pre and $effect.
But if you take the same code and put it in an onMount, you will get the following log after clicking the button.

$effect.pre (2) [div#blue.s-y_bCXRrkrYfP, div.s-y_bCXRrkrYfP]
$effect (2) [div#blue.s-y_bCXRrkrYfP, div.s-y_bCXRrkrYfP]

Notice how the logs are the same; this indicates that $effect.pre ran after the DOM was updated.
But if you take this code, with or without the onMount, and run it in the playground, both versions are broken.
REPO
Open the devtools, clear it, and click the button; You will see that both logs are the same, which means $effect.pre runs after the DOM update.
The following is my svetel.config.js

import adapter from "@sveltejs/adapter-auto";
import { vitePreprocess } from "@sveltejs/vite-plugin-svelte";
import { sveltePreprocess } from "svelte-preprocess";
import { aliases } from "./aliases.js";

/** @type {import('@sveltejs/kit').Config} */
let config = {
  // Consult https://kit.svelte.dev/docs/integrations#preprocessors
  // for more information about preprocessors
  preprocess: [vitePreprocess(), sveltePreprocess()],
  kit: {
    // adapter-auto only supports some environments, see https://kit.svelte.dev/docs/adapter-auto for a list.
    // If your environment is not supported or you settled on a specific environment, switch out the adapter.
    // See https://kit.svelte.dev/docs/adapters for more information about adapters.
    adapter: adapter(),
    alias: aliases
  },
  compilerOptions: {
    hmr: true
  }
};

export default config;

If you need anything else, feel free to ask.

[paoloricciuti]

That is expected since in the playground async is activated by default.

[paoloricciuti]

So just to understand...your undesired behaviour is that if you create an $effect.pre on mount without async you expect it to work the same as outside the onMount correct?

I'll need to figure out if that's a bug but I want to properly understand because the rest of the behaviour is expected.

[HighFunctioningSociopathSH]

That is true. Imagine creating an attachment or some sort of module that requires the node to run. Svelte 5 allows the creator to create $state, $derived, or $effect inside their .svelte.ts files. Usually, people call these functions through Actions or Attachments; So, as someone who is working on a utility function that is meant to animate the changes that occur to the children of an element, the first thing that comes to mind is $effect.pre because the whole point of $effect.pre, as stated in the documentation, is to run before the DOM updates whenever its dependencies change. In the provided snippet, you can see when the "colors" array, which is a dependency of the $effect.pre changes, $effect.pre is running after the DOM is updated, which is wrong.

[paoloricciuti]

As i've said there's a documented breaking change for async and $effect.pre now runs before the attributes are updated but after the blocks...so in your case, each will run before $effect.pre updating the dom within your content. So if the problem is about onMount i can try to figure out if that's expected...if the problem is that when using async (eg. in the playground) you see this behavior I'm afraid we can't change that (and that's why async is experimental and will not be shipped until svelte 6 when we can make this breaking change)

[HighFunctioningSociopathSH]

As I said before, my async flag is false, and this doesn't have anything to do with async, since if it were about blocks running before $effect.pre, then it would have done so even if $effect.pre wasn't called inside of an onMount. having $effect.pre called in 2 different scheduling, just because it was called inside or outside of onMount, has nothing to do with the new features such as async. And no, I'm not talking about the playground, in my own environment, I shouldn't be seeing 2 different timing schedules of $effect.pre based on where it is initialized.

[viktorius007]

That is expected since in the playground async is activated by default.

I can verify @HighFunctioningSociopathSH observation. In the REPL $effect.pre() definitely runs after the DOM updates. However in my local development environment, the identical code runs correctly, that is $effect.pre() runs before the DOM updates. The only time that $effect.pre() runs correctly BEFORE the DOM updates is at initial object creation time.

https://svelte.dev/playground/733c4f95bc7f448d910ca50b7d3933eb?version=5.38.1

The notes are very clear that $effect.pre() runs BEFORE the DOM updates, therefore this "breaking feature" needs to be documented MUCH MUCH better, and IN the main documentation. Including how to opt in and opt out of async mode. Because I'm unable to find any obvious documentation on how to do this and what the exact consequences are of each option. The REPL should also make it clear which version its running, or offer both versions and clearly specified.

@HighFunctioningSociopathSH I have found a workaround to my observed issue by accident, take the REPL URL that you are using and append ?version=5.35 to force REPL to use the version before it was "upgraded" to async.

[paoloricciuti]

The notes are very clear that $effect.pre() runs BEFORE the DOM updates, therefore this "breaking feature" needs to be documented MUCH MUCH better

It will definitely be better documented after it goes out of experimental. As of today is still a bit in movement.

And it's not really after DOM updates, just after template blocks...for example if you check for some attribute update $effect.pre still runs before it.

The REPL runs in async mode for every svelte version after async has been released which is 5.36 (but I think we should probably add a "signal" of some sort)

[paoloricciuti]

Would you consider this a good reproduction of your issue @HighFunctioningSociopathSH ?

https://svelte.dev/playground/a39e2a1997874301ab4a6c4980ba2788?version=5.35.7

[HighFunctioningSociopathSH]

@paoloricciuti Yes, your provided REPL is exactly my issue. The main issue has nothing to do with async. It's more about where the $effect.pre is initialized. As your REPL shows, 2 exactly identical $effect.pre are logging 2 different values, which is an issue.