🦋 Changeset detected

Latest commit:a0dfeea

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

Playground

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

I prefer this version as it resembles existing APIs likehttps://vuejs.org/api/reactivity-advanced.html#triggerref
And then, unlike $state.opaque, this one can be used in class properties.

We are now looking closely at how we can utilize writable deriveds to our benefit which have led up to the question on how to reset a derived back to its computed value. Which leads me to question if there should be also$derived.invalidate rune. What do you think?

What's the use case of reverting a value back to its computed value, and is this something you could write a wrapper for? Something like

letprev;letvalue=$derived.by(()=>{prev=value;// ...});// ...value=prev;

@dummdidumm we are now trying to draft how we would write our models to support optimistic updates and seems like writable derived is exactly a perfect fit for it. We are building a real-time application and are looking into supporting offline-mode to a certain degree.

So imagine the same example that isdescribed in the docs with the slight change that we can schedule multiple optimistic updates before server responds. Now if the server responds with error on the first update what we want is to reset the value to its "confirmed" state and try to reapply second, third, etc optimistic updates again.

While the way you suggest to solve it would work it'll be kind of impractical when we have multiple models with tens of fields - it'd be simply a lot of code. The reasoning is sort of the same as with writable deriveds. While you can achieve writable deriveds with$state and$effect having them seems simpler at scale.

classModelextendsAbstractModel{// This is a confirmed value that is consistent with the server state.// Here I use only one field as an example, but lets imagine there are 10s of them,// and a single change could involve updating multiple fields.privateserverCounter=$state(0)// this value we will use for UI and will optimistically updatecounter=$derived(this.serverCounter)increment(amount:number):void{// I don't have an exact API here yet, we are still looking at how to best implement it.// However lets imagine we store this functions in some collection,// then we apply optimistic updates immediately, but run server queries in sequence.// If the request responds with an error, we reset all the deriveds on the model// and reapply remaining proposals again, then we send the second request and so on.// Here $derived.invalidate would come in handy.this.propose(()=>{this.count+=amountreturnasync()=>{this.serverCount=awaitfetch()}})}}// somewhere in UI clicks button multiple times and we call increment multiple timesmodel.increment(1)model.increment(3)model.increment(2)

The idea here is to have something conceptually similar to what is written inthis article, without patches and snapshots though. If you know of any better ways to do this in Svelte and have time/energy to share would also appreciate any ideas.

If you have a definite variable that contains the "real" state, and you have a way to know it errors (which you need anyway else how do you know how to call$derived.invalidate) why not dothis.counter = this.#serverCounter then?

Yeah, you are right. Ideally we still hope that we can find a way to make a somewhat generic solution, so we could apply it to any model. Of course given the lack of decorators and ability to iterate over class properties in Svelte it might be not achievable, but lets see.

Anyway, thank you for looking into this. Perhaps it'd be better for me to open a separate issue with better example if we end up needing something like$derived.invalidate in the end :)

After todays drafting session we were able to restructure our idea such that we can still keep it generic without the need to manually invalidate for$derived, however$state.invalidate would come in very handy. So eagerly waiting for it to land.

I've also noticed that the follwing trick helps solving the same problem:

classBox{value;constructor(initial){this.value=initial;}}classCounter{count=$state.raw({inner:newBox(0)});increment(){this.count.inner.value+=1;this.count={inner:this.count.inner}}}

Not as nice as the PRs solution, but solvable without any additions to the API

Is it possible to invalidate only one property of an object?

constcounters=$state({count1:0,count2:newCounter()})$effect(()=>console.log(counters.count1))$effect(()=>console.log(counters.count2.current))// Only trigger this onecounters.count2.current++$state.invalidate(counters.count2)

If not, would not it make sense to limit this rune to be used with only $state.raw?

I could probably make it do that, but that'd require basically treating it like an effect (and wrapping it in an arrow function), getting the source that corresponds to that property, and invalidating that.

Just to clarify, I don't think making it possible to invalidate properties is worth the effort
My point is that if $state.invalidate wasn't designed to use the specific deep fine grain reactivity features of $state then it should be limited to being used with $state.raw

If I were to try to implement it, it'd be in a separatePR commit so I could easily revert it.
I honestly would be curious to see if I could do it, and if it would work well.

I've added the ability to invalidate individual properties of a$state proxy (in a pretty performant/simple way too), feel free totry it out and see if there are any bugs.
If there are too many bugs, some sort of confusion, or little reason to have it, I'll revert it.

LGTM

What about a class version of that object internally created using$state.raw(), with atick() method and a possibility to obtain a raw value without triggering reactivity?

https://svelte.dev/playground/hello-world?version=5.34.7#H4sIAAAAAAAAE41TTY-bQAz9KxZaKaBEoXslBKnKpXtdRb2USkvASUadzKAZQ3aF-O_18BWyyqo9IMBjv_fseW48lV3Qi7wfKKWGqzayAB8LQVgE3so7ConWi341Hn2ULs8FOD5UfS_Lta1RkosdMouP4rlWhIoYxov7YKRLElpZMJVCC2GSqlTFNjeiJJCZOm1Tj2zqcVxcSm0IGnjFI7RwNPoCi3Vo8DgQLDauOJeZtbDTFVMZaFIFkLsf2MK3LgFAqNzghYX4QQS1FoVLSykl1mcJFF53Q8VySWdh1x3Aps-5ZWqJa6lP_tuLo1KZHIiEBaWv8NSMQO1b4GjbVLU3hdzFKBLfeSpFF4qHWDIqZ0GmykkbP-hDALYq0fgMPnbpB8FmIHCvE1KvxLWnqsthnAOAQaqMgq6pOpMVTq1N1Q-H42pnRbOcYaTDMYn8jz-J6bvtZpoPrW7ddGe9d8lx2F94f_nn52Q4jEP-5sihItIKNE-O8bcNj2KbjJBzMW3imHfjLTRjSvduHVEPNRG9ZtcRZyQrk5cR0K6A86HQaNWCgIw4nbgHg1lOohb0EYflv_WZ7Po_Gl3aY50Hk3TP2TiyXBeY_ERjeW2iW3ndR9o47BJ42Yht5UXsHmxXXyztbXfWvJR3e_v5aLa6-N4t4mTjeD-4lVuIYN_d_iCH7_vJUsYgfOY_j26Z27rmkuDOY5zKdfVnS3fWc6bc3zuyZ5p8OLc4I81Renc-cnWPsVxOzr2f32_-y4S8ClV40TGTFtu_-hFo1y8FAAA=

(The code above doesn't work past 5.34.3 without the<svelte:options runes /> declaration at the top)

[Svelte Playground] - a better example on how to use it

Not a complete solution, but you get the idea.

AState class, that will be specifically designed to work with other classes (or outside.svelte components in general), so that I don't need to deal with limitation of runes and wait for$state.whatever, or even name all my files likefile.svelte.ts just because it's required for runes to work.

I can make a separate feature request later with a more complete idea. For now that PR is the closest thing to what I need.

#16419 brought up an interesting wrinkle, which is not handled by this: If you have an each loop iterating over the values, you want the#each items to re-check their values, too.example