Svelte 5 Support

[niemyjski]

I've been upgrading my app to svelte 5 and one thing that no longer feels idiomatic is using persisted stores in a runes world. This needs a discussion into what is the best option.

[webJose]

Which part doesn't feel right: The persisted part, or the store part? I guess the store part?

[joshnuss]

It appears Stores are not longer necessary in Svelte.

From https://svelte.dev/blog/runes

the store API and $ store prefix (while stores are no longer necessary, they are not being deprecated)

I think we should take everything in this repo and start a new project called svelte-persisted-rune

I will create a new project that offers all the same options.

[TheOnlyTails]

Hey, are there any updates on this? I'd love to help get this going!

[joshnuss]

Opened to PRs, otherwise, I'll get to it the next time one of my project's need it.

Also, I noticed Rich is doing some stuff in this area:
https://github.com/Rich-Harris/local-storage-test

[webJose]

Also, I noticed Rich is doing some stuff in this area:
https://github.com/Rich-Harris/local-storage-test

Unsure what you mean with this. Are you hinting that you might not upgrade to Svelte v5 because Rich Harris is doing a v5 version?

[TheOnlyTails]

Opened to PRs, otherwise, I'll get to it the next time one of my project's need it.

Also, I noticed Rich is doing some stuff in this area:
https://github.com/Rich-Harris/local-storage-test

I saw that and tried it out, problem is it doesn't work for things like Sets. I'll try to come up with a PR soon.

[joshnuss]

@webJose

Unsure what you mean with this. Are you hinting that you might not upgrade to Svelte v5 because Rich Harris is doing a v5 version?

I didn't mean to hint anything. I'm just pointing out another implementation that should be considered by anyone attempting an upgrade.

[joshnuss]

This is the basic idea of how the rune would work:

export function persisted(key, initial) {
  if (typeof(window) == 'undefined') {
    throw Error('Cannot use server side')
  }

  const existing = localStorage.getItem(key)

  let state = $state(existing ? JSON.parse(existing) : initial)

  $effect(() => {
    localStorage.setItem(key, JSON.stringify(state))
  })

  return {
    get value() {
      return state
    },

    set value(new_state) {
      state = new_state
    },

    reset() {
      state = initial
    }
  }
}

[joshnuss]

I was thinking

• reset: reset to initial value
• clear: delete key from localStorage/sessionStorage

[niemyjski]

Kinda feels like they do the same thing (e.g., why wouldn't a user just reset with the known value or clear it?). I guess it couldn't hurt.

I may need to take a stab at converting this to runes here shortly as the disconnect between runes and writables is causing some pain.

[joshnuss]

Sounds good, feel free to open a PR!

[bertmad3400]

Just wanted to real quickly chime in and say, throwing an error when used server side would - in my mind at least - be a terrible idea, for a couple of reasons:

1. For larger applications it is my belief that persisted stores isn't only instantiated or accessed in client-only components. If any of you have a larger codebase where this is the case I would love to see them, because that would be a radically different approach from what I have done. This would also mean that a central store, imported by multiple components would be near impossible, as it would make it impossible to instantiate it in a regular JS/TS file given this would run on the server and while it could be possible to instantiate in a module context of a svelte component that sounds really, really confusing.

2. I strongly believe that this library is a store with the side effect of saving to local storage, and not a wrapper for local storage with the side effect of being a store. Saving to local storage is already not a guarantee (browser, storage qouta and a lot of other stuff may be in the way), and to me the beauty of the persisted stores are that I'm able to instantiate and access them server-side, and when they then reach the client they may be able to hydrate using the local storage contents

[joshnuss]

Thanks @bertmad3400,

I think it's a bit confusing to use this store with SSR.

On the server, it uses the initial value, then after rendering in the browser, the data is re-hydrated from local storage causing UI to change (often causing a flash).

The state will always be wrong server-side, because localStorage is a client-only API.

Many folks have opened GH issues about this.

That is why I'm suggesting to make it hard to make that mistake.

Devs can always wrap this in a conditional:

if (browser) {
  store = persisted(key, initial)
}

And devs that want an SSR fallback, can write a conditional function:

function persistedWithSSRFallback(key, initial)
  if (browser) {
    return persisted(key, initial)
  }

  return $state(initial)
}

[niemyjski]

https://twitter.com/puruvjdev/status/1787037268143689894/photo/1
exceptionless/Exceptionless@951f4ab

Comment with references, going to try this out and see how it works.

[saturnonearth]

I have not looked over this thread fully, so I apologize if I am not contributing here, but I just wanted to throw this example out here to see if it helps at all

import { browser } from '$app/environment';

export class LocalStore<T> {
  value = $state<T>() as T;
  key = '';

  constructor(key: string, value: T) {
    this.key = key;
    this.value = value;

    if (browser) {
      const item = localStorage.getItem(key);
      if (item) this.value = this.deserialize(item);
    }

    $effect(() => {
      localStorage.setItem(this.key, this.serialize(this.value));
    });
  }

  serialize(value: T): string {
    return JSON.stringify(value);
  }

  deserialize(item: string): T {
    return JSON.parse(item);
  }
}

export function localStore<T>(key: string, value: T) {
  return new LocalStore(key, value);
}

via Joy of Code

I have not tried this yet so I don't know if there are pitfalls. (classic Stack Overflow response, sry!)

[niemyjski]

My approach has needed some tweaks and is far from perfect, the approach above doesn't really work for passing in a serializer but is probably closer to the implementation we need.

[niemyjski]

@joshnuss here is what I've been using.. There are definitely issues around simple types (like null or empty strings) as this is a quick implementation to just get my app working. Not really even sure we need the $effect.root https://github.com/exceptionless/Exceptionless/blob/feature/svelte5/src/Exceptionless.Web/ClientApp/src/lib/helpers/persisted.svelte.ts

[Omicrxn]

in the end a new package has been created or are you going to be updating this one?

[joshnuss]

Planning to update this one, but name will likely change

[niemyjski]

@joshnuss Just curious on the way we want to approach this, svelte5 will be released soon.

[joshnuss]

Sorry, I don't have time right now.
I'll get to it when I have time.

[niemyjski]

Here is my current implementation which is not perfect. https://github.com/exceptionless/Exceptionless/blob/main/src/Exceptionless.Web/ClientApp/src/lib/features/shared/persisted.svelte.ts