🦋 Changeset detected

Latest commit:5193f2c

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-15589-svelte.vercel.app/

Playground

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

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:

functionfn(){//...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:

functionreactive(){constvalue=$state(...);// Mutations/Side effects herereturnvalue;}

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.

exportconstrune=<T>(initialValue:T)=>{const_rune=$state({value:initialValue});return_rune;};

Why have that when I can simply have:

exportconstrune=<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

It greatly simplifies the code. There is no reason not to push this PR.

exportconstrune=<T>(initialValue:T)=>{const_rune=$state({value:initialValue});return_rune;};

Why have that when I can simply have:

exportconstrune=<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

letx=$state(0);returnx;

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#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 thesuperForm() function, so I could return a separate open state along side my form (for forms in collapse and modal components).

functionnewSuperForm(form,formOptions){constnewForm=superForm(form,formOptions)return{        ...newForm,open:$state(false),}}

As this syntax isn't avaliable atm, I'm making due with this.

functionnewSuperForm(form,formOptions){constnewForm=superForm(form,formOptions)return{        ...newForm,getopen(){returnopen},setopen(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).

constaddressForm=formBuilder(()=>$derived({ ...reactiveAddressObject,_id:databaseId});,addressFormSchema,);

I'm currently using a temp variable for the$derived call atm:

letaddressFormInitialData=$derived({ ...reactiveAddressObject,_id:databaseId});constaddressForm=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