PersistedState does not update when derived from another component

[charleston-olaes]

Describe the bug

Apologies if this isn't the right place to report this or if I'm using PersistedState wrong.

After version v0.28.0 the state does not react/update when it's changed and referenced on a different component.

In my case, I have PersistedState on a class property which is shared across different components via setContext/getContext .

When setting the .current property of the state, it does not trigger any updates.

Example:

import { PersistedState } from 'runed';

export class TestPersist {
	_sessionToken = new PersistedState<{ token: string | null }>(
		`--test-perist-state`,
		{ token: null },
		{
			storage: 'session'
		}
	);

  normalState = $state('');

  derivedToken = $derived.by(() => this._sessionToken.current);

	get sessionToken() {
		return this._sessionToken.current;
	}

	updateToken() {
		const rand = Math.random().toString(36).substring(2, 15);
		this._sessionToken.current = { token: `${rand}` };
    this.normalState = `${rand}`
	}
}

On parent component

<script lang="ts">
	import { setContext, type Snippet } from 'svelte';
	import { TestPersist } from './test-persist.svelte';

	type Props = { children?: Snippet<[]> };

	const { children }: Props = $props();

	setContext('test', new TestPersist());
</script>

{@render children?.()}

Then in the child component

<script lang="ts">
	import { getContext } from "svelte";
	import type { TestPersist } from "./test-persist.svelte";

  const test = getContext<TestPersist>('test');

  const token = $derived(test.sessionToken);
  const stateToken = $derived(test.normalState);
  const derivedToken = $derived(test.derivedToken);
  const direct = $derived(test._sessionToken.current);
</script>

<pre>
  Persist State using class getter. Does not update
  {JSON.stringify(token, null, 2)}
</pre>

<pre>
  Normal State. This updated properly
  {JSON.stringify(stateToken, null, 2)}
</pre>

<pre>
  Derived State. Does not update
  {JSON.stringify(derivedToken, null, 2)}
</pre>

<pre>
  Direct Access. Does not update
  {JSON.stringify(direct, null, 2)}
</pre>

Reproduction

Here is a bare bones sveltekit app to replicate the "issue". It's under the /test route

https://github.com/charleston-olaes/runed-persisted-state-bug/tree/main

Logs

System Info

System:
    OS: Linux 5.15 Ubuntu 22.04.5 LTS 22.04.5 LTS (Jammy Jellyfish)
    CPU: (12) x64 12th Gen Intel(R) Core(TM) i5-1235U
    Memory: 16.97 GB / 31.12 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 22.14.0 - ~/.nvm/versions/node/v22.14.0/bin/node
    Yarn: 1.22.19 - ~/.yarn/bin/yarn
    npm: 9.6.5 - ~/.npm-global/bin/npm
    pnpm: 9.14.3 - ~/.nvm/versions/node/v22.14.0/bin/pnpm
  npmPackages:
    @sveltejs/kit: ^2.22.0 => 2.24.0 
    runed: ^0.31.0 => 0.31.0 
    svelte: ^5.0.0 => 5.36.4

Severity

blocking an upgrade

[charleston-olaes]

I've pushed a PR that removes the storageType check in the constructor to resolve this issue.

[webJose]

The PR you submit is incorrect, as this cannot be the solution. The check for storage type is there to avoid local storage values from soiling session storage values. The subscription subscribes to the storage window event, which only fires on local storage, and only when the change is from another window.

I'm not saying that removing it doesn't make your case work. I'm saying that this is not the way of fixing it.

[charleston-olaes]

@webJose Understood. Apologies, it wasn't my intention to disrupt the separation between local and session storage types, it makes more sense now that you've explained it. I just needed the session storage type to behave the same as the local storage type due to project requirements.

[webJose]

Fully understandable. You're probably depending on the artificial signal that createSubscriber() is creating, and it is only being used for local storage. A version of the call to createSubscriber() probably needs to happen for the session storage case in order to fulfill your requirement; one that doesn't subscribe to the window's storage event.

In case it wasn't clear: It is not wrong to seek resolution; simply the proposed solution is the wrong one.

[charleston-olaes]

@webJose since the problem I'm having is this.#update is undefined when setting the current value.

  set current(newValue: T) {
    this.#serialize(newValue);
    this.#update?.(); // <-- undefined
  }

Would something like this be an acceptable fix?

    if (syncTabs && storageType === "local") {
      this.#subscribe = createSubscriber((update) => {
        this.#update = update;
        const cleanup = on(window, "storage", this.#handleStorageEvent);
        return () => {
          cleanup();
          this.#update = undefined;
        };
      });
    } else if (storageType === "session") {
      // create a subscriber but without hooking into the storage event
      this.#subscribe = createSubscriber((update) => {
        this.#update = update;
        return () => {
          this.#update = undefined;
        };
      });
    }

Not sure if the else if (storageType === "session") is necessary, could just be an else.

[webJose]

That sounds better. You want/need the artificial signal that lives inside createSubscriber(), so you want it to exist on all cases.

I would program it differently, though, as I don't like repetition. I would take the guarding IF and put it inside the createSubscriber()'s callback to only guard subscription to the storage event.

[charleston-olaes]

@webJose Sounds good. Does something like this look cleaner?

    this.#subscribe = createSubscriber((update) => {
      this.#update = update;
      const cleanup = syncTabs && storageType === "local" ? on(window, "storage", this.#handleStorageEvent) : null;
      return () => {
        cleanup?.();
        this.#update = undefined;
      };
    });

[webJose]

That looks better to me, yes. No repetition of code is always a good thing to have.

[charleston-olaes]

@webJose Thanks for the feedback. I'll update my PR as soon as I get back.