feat: svelte 5

[PuruVJ]

Originally intended to just see how fast non-runic svelte 5 would be, I couldn't resist and converted the whole app to svelte 5 with runes. No more stores here, just $state

[changeset-bot]

⚠️ No Changeset found

Latest commit: c90ad9a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
macos-web	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 30, 2024 8:35am

[benmccann]

If I create a new SvelteKit project with create-svelte then plugins is at the top level and I also have a parser override. I'm not sure which is more correct 😆 But I'm surprised they're different

[PuruVJ]

Oh I didn't know about that, I just thought of adding a plugin for just .svelte files. if the global plugin works, its fine ig 😅

[benmccann]

I'd be curious if one is better for performance or if there is a best practice. Like is yours fast because it applies only to svelte files or is the create-svelte one faster because it just has to be instantiated once globally. The more surprising part is that you were able to get away with out the parser setting.

For reference, here's what create-svelte does:

	"plugins": ["prettier-plugin-svelte"],
	"overrides": [{ "files": "*.svelte", "options": { "parser": "svelte" } }]

[PuruVJ]

That's weird, parser svelte shouldn't be needed, I have never added that to any prettierrc file until now.

I tested with pnpx prettier . --write to see if maybe parser svelte is required, but no, it works just as well

[benmccann]

I feel like trying to abstract persisted here isn't doing you any favors because you have to do things like preferences.value.theme.scheme instead of preferences.theme.scheme. Perhaps you can just create the $effect to keep local storage updated directly in this file instead? I think then you don't need the .value since you wouldn't be crossing boundaries to access the persisted value

[PuruVJ]

I kept it like that cuz Joshnuss is working on svelte-persisted-rune, and once that's out I'm sure he'll figure out a way to do .value on primitives and flattening on objects, so I'll upgrade to that then. Not too worried about the syntax atm

[Rich-Harris]

I think preferences.value is fine — better than a) not having something encapsulated and reusable or b) inconsistency. Unless you were to enforce persisted values being non-primitive

[benmccann]

I don't know if there's a way around preferences.value if you want to have it in a separate file even if you restrict it to being an object? Maybe you could use proxies or something?

You can have a decent amount of reuse if you write it as a hook that the consumer needs to install in an $effect. That doesn't buy you much here because this example is so simple, but is potentially something you could do in a more complicated example

[PuruVJ]

I figured it out

import { auto_destroy_effect_root } from './auto-destroy-effect-root.svelte.ts';

type Primitive = string | null | symbol | boolean | number | undefined | bigint;

const is_primitive = (val: any): val is Primitive => {
  return val !== Object(val);
};

export function persisted<T>(key: string, initial: T) {
  const existing = localStorage.getItem(key);

  const primitive = is_primitive(initial);
  const parsed_value = existing ? JSON.parse(existing) : initial;

  let state = $state<T extends Primitive ? { value: T } : T>(
    primitive ? { value: parsed_value } : parsed_value,
  );

  auto_destroy_effect_root(() => {
    $effect(() => {
      // @ts-ignore
      localStorage.setItem(key, JSON.stringify(primitive ? state.value : state));
    });
  });

  return state;
}

[PuruVJ]

Check the commit just after this comment box

[PuruVJ]

Maybe you could use proxies or something?

No need when svelte does it for ya 😜

[benmccann]

Nice. That looks much better!

[Rich-Harris]

Personally don't love the inconsistency but horses for courses!

Tangential to this convo, but: I'm personally of the view that a localStorage abstraction must listen for storage events and synchronise between tabs, otherwise one will clobber the other silently, leading to all sorts of fucked up bugs

[PuruVJ]

Yet to add that, will do so. I'm also planning on upstreaming the changes to svelte-perisisted-store.