Appropriate approch for following the change in effect behavior in svelte 5.24.0

[ykrods]

issue: maxnowack/signaldb#1536
related: #15564

To briefly explain here as well — in Svelte 5.24.0, updates to $state variables created within an $effect are no longer treated as dependencies of that $effect. As a result, reactivity is lost in some features of SignalDB.

On SignalDB, integration with svelte has code like the following ( same as guide ). In the code, cursor.fetch() internally creates a $state to catch changes to the database. Due to the change mentioned above, even when that $state changes, the $effect no longer re-runs.

<script>
  import { Collection } from "@signaldb/core";

  const Posts = new Collection({
    reactivity: {
      create() {
        let dep = $state(0);
        return {
          depend() {
            dep;
          },
          notify() {
            dep += 1;
          },
        };
      },
      isInScope: () => !!$effect.tracking(),
    },
  });

  let items = $state.raw([]);
  $effect(() => {
    const cursor = Posts.find({});
    items = cursor.fetch(); // calls reactivity.create() inside

    return () => {
      cursor.cleanup();
    };
  });
</script>

We're currently considering the use of createSubscriber instead of $state, as also suggested in maxnowack/signaldb#1536 (comment).
Would this be considered an appropriate approach to handle this situation? Or is there a better solution?

[webJose]

I'm unsure what changed between v5.23 and v5.24 (too lazy to go check). Generally speaking, an effect re-runs whenever read state changes. You'lre creating state, but you're not reading it. Try reading it.

[ykrods]

@webJose Thanks for your comment!

Ah, you're right — reading state is definitely an important point as well. I forgot to mention that depend() is also being called within cursor.fetch().

[ykrods]

Since the change to createSubscriber seems to be working well, We've decided to switch over to that. I'll go ahead and close this discussion.

For future readers, here’s a simple example:

The following code used to cause $effect to run infinitely, but as of version 5.24.0, it now stops after one run.
This is because dep is created inside the $effect, and is no longer considered a dependency.

<script lang="ts">
  $effect(() => {
    let dep = $state(0)

    const id = setTimeout(() => dep++, 1000)

    console.log("dep:", dep)

    return () => clearTimeout(id)
  })
</script>

If you want $effect to react to changes in dep that was created inside another $effect, a simple approach would be to add a nested effect like this.
(We didn’t go with this approach because it would require changes to our library’s API design.

<script lang="ts">
  $effect(() => {
    let dep = $state(0)

    const id = setInterval(() => dep++, 1000)

    $effect(() => {
      console.log("dep:", dep)
    })

    return () => clearInterval(id)
  })
</script>