🦋 Changeset detected

Latest commit:293fefb

The changes in this PR will be included in the next version bump.

Not sure what this means?Click here to learn what changesets are.

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

preview:https://svelte-dev-git-preview-svelte-15069-svelte.vercel.app/

this is an automated message

Playground

pnpm add https://pkg.pr.new/svelte@15069

Would there also be anonchange option for$state.raw?

Would there also be anonchange option for$state.raw?

Yes (uh I need to update types for that too)

I like this, but also I'm thinking that there are more cases where you get a$state from an external source (props, imported, etc), and you might want to synchronously observe their changes as well.
I'm not sure what the implementation of that would look like, however. Maybe something like a$watch rune, which was proposed somewhere.

I like this, but also I'm thinking that there are more cases where you get a$state from an external source (props, imported, etc), and you might want to synchronously observe their changes as well. I'm not sure what the implementation of that would look like, however. Maybe something like a$watch rune, which was proposed somewhere.

I think effect or derived with state is the good formula for that already...this aims to solve the problem of getting deep updates for a stateful variable that you own.

This would have helped me several times! Figuring out how to watch deep updates was very unintuitive to me.

Recapping discussion elsewhere — I think we made a mistake with the implementation of$state(other_state):

letobj={};leta=$state(obj);letb=$state(obj);console.log(a===b);// false, which is goodletc=$state(b);console.log(b===c);// true, which is bad

There's no real point in havingc be a separate binding with the same value; if you want that just dolet c = b. But for some reason we did this:

It would have been better if existing proxies passed directly to$state were snapshotted.

Most of the time this doesn't really matter, because people generally don't use state like that. But we do need to have some answer to the question 'what happens here?' more satisfying than 'we just ignore the options passed toc altogether:

letobj={count:0};leta=$state(obj,{onchange(){console.log('a changed');}});letb=$state(obj,{onchange(){console.log('b changed');}});letc=$state(b,{onchange(){console.log('c changed');}});

I think one reasonably sensible solution would be to throw an error in thelet c = $state(b, ...) case if options were passed to eitherb orc. In Svelte 6 we could go one of two ways — automatically snapshot, or error whenany state proxy is passed to$state.

I think one reasonably sensible solution would be to throw an error in thelet c = $state(b, ...) case if options were passed to eitherb orc. In Svelte 6 we could go one of two ways — automatically snapshot, or error whenany state proxy is passed to$state.

I think it'd probably be best if$state proxies were snapshotted when passed to$state. You don't always know if you're getting a$state proxy (such as in props). I also think it'd be best ifthis sort of thing were to be fixed earlier, as this doesn't seem like somethinganyone would want/try to do.

Actually, I take it back — in thinking about why we might have made it work that way in the first place, this case occurs to me:

letitems=$state([...]);letselected=$state(items[0]);functionreset_selected(){selected.count=0;}

That doesn't work if we snapshot at every declaration site (and itcertainly wouldn't make sense to snapshot on declaration but not on reassignment).

So I guess automatic snapshotting and erroring are both off the table — we need to keep the existing behaviour for$state(value) today and in Svelte 6. But I do think we should make it an error to do either of these in the case whereb is an existing state proxy (with or without an existing options object), because there's no way for Svelte to know whichonchange handler to fire when the state is mutated:

letc=$state(b,{onchange(){...}});

letc=$state({},{onchange(){...}});c=b;

Actually, I take it back — in thinking about why we might have made it work that way in the first place, this case occurs to me:

letitems=$state([...]);letselected=$state(items[0]);functionreset_selected(){selected.count=0;}

That doesn't work if we snapshot at every declaration site (and itcertainly wouldn't make sense to snapshot on declaration but not on reassignment).

So I guess automatic snapshotting and erroring are both off the table — we need to keep the existing behaviour for$state(value) today and in Svelte 6.

I didn't think of that, actually. But couldn't that be fixed with$state.link? That way, we wouldn't have to worry about$state proxies referencing other$state proxies, unless that is the desired behavior:

letitems=$state([...]);letselected=$state.link(items[0]);functionreset_selected(){selected.count=0;}

Not sure how I feel about this. Shouldn't this just be some kind of effect, that watches deeply?

$effect(() => {    ...}, {deep: true})

Shouldn't this just be some kind of effect

No. Avoiding effects is the whole point of this. Deep-reading is easy, but often when you want to respond to state changes, the state was created outside an effect (think e.g. an abstraction aroundlocalStorage).

Opened#15073 to address an issue with array mutations causingonchange to fire multiple times.

Any thought to doing something likelet foo = $state(watch({ bar :"value" }, () => handleChange()))

Instead of

let foo = $state({ bar :"value" }, () => handleChange())

In my opinion this is more composable and extendable. I know this is an older PR but to me the proposed API feels a bit off.

What's the value of thewatch function?

Any thought to doing something like let foo = $state(watch({ bar :"value" }, () => handleChange()))

I think the issue here is, this makes it seem likewatch can be used without$state. Correct me if I'm wrong, but isn't theonchange functionality provided by$state wrapping the object deeply with a proxy? How couldwatch work without this?

Any thought to doing something like let foo = $state(watch({ bar :"value" }, () => handleChange()))

I think the issue here is, this makes it seem likewatch can be used without$state. Correct me if I'm wrong, but isn't theonchange functionality provided by$state wrapping the object deeply with a proxy? How couldwatch work without this?

Yeah watch without$state would just be a worse effect.

I mean we could make it work but I just don't understand what the advantage would be (it also looks very ugly)

Watch would likely wrap the value in a proxy, this is basically a copy of a function I wrote to solve this problem before this PR. It could also be done at compile time but I think you lose some of the extensibility. Watch is also a place holder name it would be “track” but to me if someone comes to this file with watch it’s fairly obvious what the callback it doing. If I see a second arg in the state rune it’s much less obvious what the callback is for.

What this PR does it's different from using effect since it's invoking the callback synchronously... it's also doing it deeply without the need to create a source for the whole object.

What's not clear about an object withonchange property? Doesn't theonchange signal that you want that callback to be invoked when the state value changes?

Nope, it's just the compiler that is unwrapping the object to pass just the onchange to the function so the API is still the same

@jjones315 Please don't delete comments from threads, it makes it very difficult for people to understand what (for example) other people are replying to. This repo is a public record. We'll hide irrelevant comments if that's necessary to declutter the thread

This is good but I'm very concerned about the cost of creating a new set and a new wrapper function on every new proxy. I think we have to come up with a way around that.

Here's what I'm thinking: a top-level source can have anonchange function that gets called insideset (notinternal_set), while a proxy always has anonchanges array (not set, for reasons explained in a sec) which is usually empty. When a proxy is created as a child of another proxy, it just gets that same array. The proxy itself is responsible for calling all theonchanges when a property is updated. Onproxy.property = other_proxy, theonchanges belonging toproxy are appended to theonchanges belonging toother_proxy; ondelete proxy,other_proxy has theproxyonchanges removed.

It's an array rather than a set because you could have duplicates:

functiononchange(){console.log('changed');}letproxy=$state({},{ onchange});letother_proxy=$state({},{ onchange});// `other_proxy` inherits `onchange` from `proxy`proxy.property=other_proxy;// `onchange` is removed from `other_proxy`deleteproxy.property;

If it was a set, the add/remove would be assymetrical, andother_proxy would lose itsownonchange.

There is a caveat to this approach:

letproxy=$state({},{onchange:foo});letother_proxy=$state({},{onchange:bar});letmiddle={ other_proxy};proxy.middle=middle;

Here, wewouldn't want to passfoo toother_proxy, because then ondelete proxy.middle we would need to walk the object until we were able to remove it again which is costly.

As a result,proxy.middle.other_proxy.blah would on triggerbar, notfoo. Personally I think this is an acceptable trade-off.

Will hack on this

Let me know if you want to pair on this or if I can do anything to make your work easier 🤟🏻

Gah I made some progress on this (compare/state-onchange...state-onchange-roots?expand=1) but there's a (obvious-in-hindsight) fatal flaw:

letitems=$state([...],{ onchange});constlast=items.pop();// should not trigger `onchange` as it's no longer in `items`, but it doeslast.foo='blah';

If theonchanges array is shared between parent and child, we can't remove the callback when an item is detached.

Think I need to step away from this PR for a bit because there are other demands on my attention, but a sketch of apossible alternative approach:

• we distinguish between root proxies and child proxies
• root proxies can have anonchange callback
• child proxies have aparent if they are a child of a root with anonchange or a child of a child with aparent
• when a mutation happens (i.e. via theset ordeleteProperty traps) we walk up theparent chain to a root. If the chain is broken somewhere (because an object was detached from a state-with-onchange tree) the callback does not fire
• existing state proxies cannot be added to a state-with-onchange tree — only POJOs, non-proxyable objects, and primitives. this ensures that a child proxy has either 0 or 1 parents (otherwise this doesn't work)
• the exception to this is when mutating an array with e.g.array.splice(...) orarray.reverse(), since ifarr[i] is assigned toarr[j] it will already be a state proxy

In other words we introduce some new constraints to enable a memory-friendly implementation, but these constraints only apply to state that usesonchange.

I think this was basically my original implementation...I don't think a lot of people will pass proxies to proxies but I wonder if this limitation could be confusing.

What if we stick to an array (not a set) and we dedupe the functions when calling them?

existing state proxies cannot be added to a state-with-onchange tree — only POJOs, non-proxyable objects, and primitives. this ensures that a child proxy has either 0 or 1 parents

I think that would be a dealbreaker. Consider this situation.

<script>import {localStorage }from'./somewhere';let todo=$state({});functionsave() {// localStorage uses onchange, so this will throwlocalStorage.state.todos.push(user);  }</script>....

I think something like this is prone to happen one way or the other.

Yeah I think it would be very confusing or annoying...is there a way to measure the memory footprint?