Skip to content

feat: allow $state in return statements#15589

Open
Ocean-OS wants to merge 14 commits into
sveltejs:mainfrom
Ocean-OS:allow-state-return
Open

feat: allow $state in return statements#15589
Ocean-OS wants to merge 14 commits into
sveltejs:mainfrom
Ocean-OS:allow-state-return

Conversation

@Ocean-OS

@Ocean-OS Ocean-OS commented Mar 22, 2025

Copy link
Copy Markdown
Member

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

  • 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
  • Prefix your PR title with feat:, fix:, chore:, or docs:.
  • This message body should clearly illustrate what problems it solves.
  • Ideally, include a test that fails without this PR but passes with it.
  • If this PR changes code within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

  • Run the tests with pnpm test and lint the project with pnpm lint

@changeset-bot

changeset-bot Bot commented Mar 22, 2025

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 5193f2c

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

@svelte-docs-bot

Copy link
Copy Markdown

@github-actions

Copy link
Copy Markdown
Contributor

Playground

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

@naylour naylour left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

@Ocean-OS

Copy link
Copy Markdown
Member Author

I'm not sure if this should also apply to implicit returns in arrow functions, does anyone have any input on that?

@benmccann benmccann left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would be good to have a test, which would also help illuminate what is being supported

Comment thread .changeset/sharp-rings-march.md Outdated
@Ocean-OS

Ocean-OS commented Mar 28, 2025

Copy link
Copy Markdown
Member Author

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.

@Hugos68

Hugos68 commented Apr 14, 2025

Copy link
Copy Markdown
Contributor

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.

@jdgamble555

Copy link
Copy Markdown

@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

@paoloricciuti

Copy link
Copy Markdown
Member

@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

@jdgamble555

Copy link
Copy Markdown

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

@Ocean-OS

Ocean-OS commented Apr 26, 2025

Copy link
Copy Markdown
Member Author

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.

@paoloricciuti

Copy link
Copy Markdown
Member

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.

@jdgamble555

jdgamble555 commented Apr 26, 2025

Copy link
Copy Markdown

@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.

@paoloricciuti

Copy link
Copy Markdown
Member

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

@jdgamble555

Copy link
Copy Markdown

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.

@paoloricciuti

Copy link
Copy Markdown
Member

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.

@jdgamble555

Copy link
Copy Markdown

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?

@Tyler-Petrov

Tyler-Petrov commented Jun 12, 2025

Copy link
Copy Markdown

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.

@Ocean-OS

Copy link
Copy Markdown
Member Author

You might be interested in #15593, it adds the { property: $state(value) } syntax

@Tyler-Petrov

Copy link
Copy Markdown

That makes sense. I'll post my message there, thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Svelte 5 Exporting $state compile problem

8 participants