🦋 Changeset detected

Latest commit: 8f71584

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:

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.

#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 #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?