svelte
svelte copied to clipboard
feat: allow `$state` in return statements
This allows $state calls to be returned from a function, returning a proxy (if the argument can be proxied). In DEV, providing a unproxyable argument results in a runtime warning.
Closes #14316
Before submitting the PR, please make sure you do the following
- [x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
- [x] Prefix your PR title with
feat:,fix:,chore:, ordocs:. - [x] This message body should clearly illustrate what problems it solves.
- [x] Ideally, include a test that fails without this PR but passes with it.
- [x] If this PR changes code within
packages/svelte/src, add a changeset (npx changeset).
Tests and linting
- [x] Run the tests with
pnpm testand lint the project withpnpm lint
🦋 Changeset detected
Latest commit: 5193f2c28922ce56ff89a73910fea22e269fad4f
The changes in this PR will be included in the next version bump.
This PR includes changesets to release 1 package
| Name | Type |
|---|---|
| svelte | Minor |
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-15589-svelte.vercel.app/
I'm not sure if this should also apply to implicit returns in arrow functions, does anyone have any input on that?
it would be good to have a test, which would also help illuminate what is being supported
I'll add the test in a bit. This PR allows you to return a $state call, like so:
function fn() {
//...
return $state(obj);
}
In this example, $state gets compiled to $.proxy, proxying the object.
Since the only purpose for this is proxying, $state.raw cannot be used in the same way.
This is cool but I fail to see what use cases require you to directly return $state. If you need to return $state it's usually because you are creating a reactive module. In which you would never return directly:
function reactive() {
const value = $state(...);
// Mutations/Side effects here
return value;
}
I struggle to see where you would directly return $state in a meaningful manner.
@Hugos68
It greatly simplifies the code. There is no reason not to push this PR.
export const rune = <T>(initialValue: T) => {
const _rune = $state({ value: initialValue });
return _rune;
};
Why have that when I can simply have:
export const rune = <T>(initialValue: T) => $state({ value: initialValue });
This is just the basic case, but it would definitely help get rid of pointless boilerplate like declaring an unnecessary variable.
https://github.com/sveltejs/svelte/issues/14316
J
@Hugos68
It greatly simplifies the code. There is no reason not to push this PR.
export const rune = <T>(initialValue: T) => { const _rune = $state({ value: initialValue }); return _rune; };Why have that when I can simply have:
export const rune = <T>(initialValue: T) => $state({ value: initialValue });This is just the basic case, but it would definitely help get rid of pointless boilerplate like declaring an unnecessary variable.
#14316
J
@Hugos68 points is that it's very rare that you need to declare state and just return it. The reason it was initially prevented is because doing
return $state(0);
Is absolutely wrong
Is absolutely wrong
We are using a compiler here. You didn't quote any specific reason other than just saying "wrong." How about we constructively consider how we can make this work instead of how we can't. If there is a bad use case, then we handle that separately.
Thanks,
J
I might add a runtime warning if you don't pass a proxyable value to a $state in a return statement, which should alleviate any confusion.
It doesn't work for the same reason doing this
let x = $state(0);
return x;
Doesn't work: it was a design decision to be explicit about state crossing boundaries that was made for various reasons. Now: returning $state directly can be made work, I was just mentioning the original reason why it was prevented.
Also as I've commented I agree with hugo that is very rare that you need to just create a variable and return it without actually acting on it and at that point you need the reference.
@paoloricciuti But that does work in a function. See original post https://github.com/sveltejs/svelte/issues/14316
Also, rare is relative until there are more Svelte 5 patterns. As of now, no AI can't even handle Svelte 5 code generation.
It's not about svelte 5 patterns...there's little to no reason to do so in non example code. I'm not completely opposed to the feature request, but I don't think we should blindly make this decision
What is non-example code? I gave a perfect example.
I don't see how solving a problem is "blind." People will expect this Svelte code to compile.
Are there specific examples or reasons that you or anyone else would like to reference?
If anyone is worried about side effects, let's tackle them or push this to a test branch.
I don't see how solving a problem is "blind." People will expect this Svelte code to compile.
Adding a new syntax for a problem that is not there 99% of the times is something to consider because if this new syntax introduces some "side effects" that are annoying to deal with you are adding maintenance burden for an edge case.
Merging blindly just means merging for the sake of it, as I've said it was initially prevented because of a design choice, before re-evaluating that design choice we should think of all the possibilities. That's it.
I don't have any specific examples right now, I'm just saying we should think if there are any.
I think we are saying the same thing.
That being said, sharing a simple state like that between components is not that rare IMO.
I don't think anyone is coming up with specific issues so I'm not sure how long this should sit without comments?
Isn't that the purpose of test branches / versions?
Intro
I read this PR a few days ago, and thought that this feature was cool, but wouldn't really ever use it. Since then I have found two scenarios that this feature would be helpful (one with $state, and one with $derived and an arrow function).
I think there was a plea for code examples/real world examples, so here are my use cases. Hopefully they help.
Sveltekit-Superforms Scenario
I has creating a wrapper function around the superForm() function, so I could return a separate open state along side my form (for forms in collapse and modal components).
function newSuperForm(form, formOptions) {
const newForm = superForm(form, formOptions)
return {
...newForm,
open: $state(false),
}
}
As this syntax isn't avaliable atm, I'm making due with this.
function newSuperForm(form, formOptions) {
const newForm = superForm(form, formOptions)
return {
...newForm,
get open() {
return open
},
set open(newOpen) {
open = newOpen
}
}
}
Passing values as $derived to functions
When passing values to functions its helpful to declare them explicitly as $derived or there was reactivity issues (could definitely be a skill issue though).
const addressForm = formBuilder(
() => $derived({ ...reactiveAddressObject, _id: databaseId });,
addressFormSchema,
);
I'm currently using a temp variable for the $derived call atm:
let addressFormInitialData = $derived({ ...reactiveAddressObject, _id: databaseId });
const addressForm = formBuilder(
() => addressFormInitialData,
addressFormSchema,
);
Edit: After some digging this example actually doesn't change anything, but the point still stands (even if the code doesn't).
Conclusion
I hope this comment adds constructively to the conversation, and not destructively to the chaos.
You might be interested in #15593, it adds the { property: $state(value) } syntax
That makes sense. I'll post my message there, thanks