Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Svelte 5: Bring back $state.link #13452

Open
HighFunctioningSociopathSH opened this issue Sep 30, 2024 · 4 comments
Open

Svelte 5: Bring back $state.link #13452

HighFunctioningSociopathSH opened this issue Sep 30, 2024 · 4 comments

Comments

@HighFunctioningSociopathSH
Copy link

HighFunctioningSociopathSH commented Sep 30, 2024

Describe the problem

Knowing that $state.link existed once, I can't stop thinking how many times I could use it in my project. It's really useful and removes the need of having to write an extra $effect that does nothing other than assigning a value to a variable. Also the work around that uses an $effect isn't really good either because the assignment inside $effect is not fine-grained.

Describe the proposed solution

I think it would be nice to have it back and makes migrating from svelte 4 easier since in svelte 4 you could assign to the reactive variable and it would update again if its dependency changed.
For example, you could do the following in svelte 4 when you didn't want to change the original data passed by the user and still update your finalData if it got updated

export let data;
$: finalData = data;
function handleOnClick() {
  finalData = "something";
}

So here finalData was updated internally but it would have been updated again if the user decided to update the data prop.
This could translate to the following in Svelte 5 which is neat:

let { data } = $props();
let finalData = $state.link(data);
function handleOnClick() {
  finalData = "something"
}

Importance

nice to have

@7nik
Copy link

7nik commented Sep 30, 2024

For reference: #12938 (comment) here is the decision to remove $state.link.

The problem was that, after correcting the behaviour, it used the $effect internally anyway. Also, there were open questions about behaviour in SSR and the inability to apply $state.link to an object's prop. A workaround can have whatever behaviour you need.

Examples: sync $state.link and $state.link with async merging.
If you want, you can wrap the logic into the Box pattern and have something like

let box = link(() => parentValue, onMerge);
console.log(box.value);

@Ocean-OS
Copy link

Ocean-OS commented Oct 2, 2024

Couldn't you just use a $derived, like this?

let a = $state(0);
let b = $derived(a);

@7nik
Copy link

7nik commented Oct 2, 2024

Couldn't you just use a $derived, like this?

let a = $state(0);
let b = $derived(a);

No, derives are read-only (though mutable). So you cannot do b++ or b = 42.

@Ocean-OS
Copy link

Ocean-OS commented Oct 2, 2024

No, derives are read-only (though mutable). So you cannot do b++ or b = 42.

Ah, I see.
Then wouldn't something like this work?

let a = $state(0);
let b = $state($state.snapshot(a));
$effect(()=>{
b = $state.snapshot(a);
});

It shouldn't be too much of a problem that $effect is being used here since that was what $state.link used internally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants