-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
docs: explain how to pass reactivity across boundaries #14311
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
Conversation
|
|
preview: https://svelte-dev-git-preview-svelte-14311-svelte.vercel.app/ this is an automated message |
|
|
|
||
| > [!NOTE] When you update properties of proxies, the original object is _not_ mutated. | ||
| Since `$state` stops at boundaries that are not simple arrays or objects, the following will not trigger any reactivity: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
boundaries that are not simple arrays or objects
I'm having a bit of a hard time parsing this. What does it include besides classes? Does it mean that closures don't work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does closures have to do with this? This is about what gets proxified when you pass it to $state
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohhh. I didn't read it that way at all. I thought it was saying $state that has been created can't be created across a boundary. But you're talking about the $state(...) initializer? Maybe something like this then:
| Since `$state` stops at boundaries that are not simple arrays or objects, the following will not trigger any reactivity: | |
| Since the `$state` initializer deeply creates reactive state only when encountering simple arrays or objects, the following will not trigger any reactivity: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this whole block should go in the next section. I'm generally a bit annoyed when docs show me what not to do as a way of teeing up what I should do — just show me the right way in the first place!
In this case, we can demonstrate the Svelte way of using classes, and then reiterate the point that's made at the top of the 'Deep state' section...
If
$stateis used with an array or a simple object
...adjusted to emphasise that things that aren't arrays or simple objects won't be proxified.
| todo.log(); // logs "'right', true" | ||
| ``` | ||
|
|
||
| Notice how we didn't use _any_ Svelte specifics, this is just regular JavaScript semantics. `$state` and `$state.raw` (and [`$derived`]($derived)) don't change these, they just add reactivity on top, so that when you change a variable something can happen in reaction to it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was trying to split the second part into a separate sentence to avoid it being a run-on and realized we probably don't need the second part at all
| Notice how we didn't use _any_ Svelte specifics, this is just regular JavaScript semantics. `$state` and `$state.raw` (and [`$derived`]($derived)) don't change these, they just add reactivity on top, so that when you change a variable something can happen in reaction to it. | |
| Notice how we didn't use _any_ Svelte specifics, this is just regular JavaScript semantics. `$state`, `$state.raw`, and [`$derived`]($derived) doesn't change this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to emphasize what the runes actually do instead.
Co-authored-by: Ben McCann <[email protected]>
Co-authored-by: Ben McCann <[email protected]>
Co-authored-by: Ben McCann <[email protected]>
|
I'm sorry, but I really don't think this is the way to go. In this PR literally over half the page is taken up with how-to-JavaScript examples that make it sound as though wrangling state in Svelte is far more intimidating than it actually is. Far from easing people's minds, this will increase anxiety. Looking at the referenced issues, I see a handful of tangible concerns that can be dealt with directly:
I've opened #14514 which tackles the first two. Not really sure how to untangle the misunderstanding that led to the third, but I don't think it's a common one. |
|
The thing that people have the most problems with is how to preserve reactivity across contexts. Destructuring is the easier part. It's "how do I keep this alive" what needs a good explanation, which includes explaining closures via arrow functions, getters/setters, and object mutation, which I tried here, and which is completely missing in #14514. I'm ok with condensing the knowledge, but just not having it appear in the docs means we pretend this repeating question doesn't exist. |
|
I'm uncomfortable with us taking a lot of space in the Svelte docs to teach remedial JavaScript concepts. But I've opened #14528 which tries to explain pass-by-value as concisely as possible |
|
It just shows that many people learn frameworks rather than the language, so it's unavoidable that we explain some of those concepts. I like the pair of PRs you opened so I'm gonna close this one |
closes #14300
closes #14261