Using $effect to update derived state inside the component

[joelmukuthu]

I have run into cases where some local state needs to be updated when a prop changes (so is derived) but also needs to be updated inside the component:

<script>
  const { isExpandable = true } = $props();
  const isExpanded = $state(false);

  $effect(() => {
    if (!isExpandable) {
      isExpanded = false;
    }
  });
<script>

{#if isExpandable}
  <button onclick={() => isExpandable = !isExpandable}>collapse/expand</button>
{/if}

Summary view...  

{#if isExpanded}
  Expanded view
{/if}

This is a simpler case but I have cases where the local state is truly derived from a prop where my first attempt was to use $derived, only to get the error that derived state cannot be updated locally.

Am I using $effect the wrong way here? If so, what should I be using? I know I could also accept isExpanded as a prop and have the consumer set both isExpandable and isExpanded as needed, but I want to avoid having to duplicate that code wherever the component is used.

I've seen discussions where great lengths are travelled to discourage $effect so I generally try to avoid it. But what I don't understand exactly is what's wrong with using it? What downsides should I be aware of?

[webJose]

I too have encountered this issue. @wjfe/dataview, up to v0.12.0, ran entirely on a single $derived. Then v0.13.0 introduced cross column synchronization. This cross (component) synchronization requires a single reactive control variable called expectedLeft. Just because the algorithm updates this control variable, I had to abandon $derived in favor of $effect.

The consequence: Now the component doesn't render server-side because $derived runs in SSR, but $effect doesn't.

It seems that we will have to wait for #14784 to be able to use a potential new unsafe() function to fulfill our need. The bad news: It has the Svelte v6 milestone assigned. 😞

[joelmukuthu]

Thanks for responding @webJose!

The consequence: Now the component doesn't render server-side because $derived runs in SSR, but $effect doesn't.

Great to know, thanks!

I've seen some cases where $state is returned from a $derived.by callback, something like this:

const someState = $derived.by(() => {
  if (foo) {
    return $state(bar);
  }
});

Then accessed in the template via someState.current. Have you worked with this? Do you know if it's a workaround as well or even a recommendation?

[brunnerh]

Returning $state directly is currently not allowed, it needs a separate declaration.
There is some discussion around loosening this restriction specifically to facilitate the $state in $derived pattern.
That being the case it probably could be considered a recommendation.

[joelmukuthu]

Understood, thanks @brunnerh! Would you mind giving a complete-ish example of the $state in $derived pattern? e.g. for my initial example?

[brunnerh]

It is a bit weird for this example because the prop is just a partial constraint, it does not really need to be used, it can just reset the derived state. Since the initial state is false, when you try to combine that with isExpandable, the type inference will just force the type itself to false and minifiers might eliminate the one thing which would make this reactive.

You can reference the property on its own, which is a bit odd and reminds me of reactive statements in Svelte 3 & 4.

<script>
  const { isExpandable = true } = $props();
  const isExpanded = $derived.by(() => {
    isExpandable; // for reactivity
    const state = $state({ current: false });
    return state;
  });
</script>

{#if isExpandable}
  <button onclick={() => isExpanded.current = !isExpanded.current}>
    collapse/expand
  </button>
{/if}

<p>Summary view...</p>

{#if isExpanded.current}
  <p>Expanded view</p>
{/if}

Playground

Using an $effect to synchronize $state is really not that bad if done correctly. It becomes dangerous if you have many dependencies or end up having state depend on itself (which easily leads to infinite loops).

[joelmukuthu]

Understood. Thanks for the help!