docs: tweak untrack description, provide an example of usage #14085
Conversation
|
commit: |
|
Do we also want to mention that any state written to inside an |
|
No, because it's not true |
|
Well that's a good reason to not do it. I recall that it has some sort of an effect in this area. There was some issue recently where someone really wanted to run mutations inside the template and I suggested using untrack because it seemed to work in that case. Maybe it was just blocking the read portion of an a += 1, though. |
|
Yep, if you do |
| @@ -2,7 +2,7 @@ | |||
| title: $effect | |||
| --- | |||
|
|
|||
| Effects are what make your application _do things_. When Svelte runs an effect function, it tracks which pieces of state (and derived state) are accessed, and re-runs the function when that state later changes. | |||
| Effects are what make your application _do things_. When Svelte runs an effect function, it tracks which pieces of state (and derived state) are accessed (unless accessed inside [`untrack`](svelte#untrack)), and re-runs the function when that state later changes. | |||
There was a problem hiding this comment.
Effects are what make your application do things This sounds too broad, you can actually make applications do things without using effect. I suppose react is out of question, why not something like $effect lets you take full control on your application?
There was a problem hiding this comment.
you can actually make applications do things without using effect
Like what?
There was a problem hiding this comment.
Like anything that don't use effect... like 90% of the example of the docs and tutorials? Is this a real question?
There was a problem hiding this comment.
Do you mean like the {name} in <h1>hello {name}</h1>? Because that is an effect. This is made quite clear in the following sentence
There was a problem hiding this comment.
Documenting the implementation is pointless in a user docs. This makes the sentence even more confusing. This reads:
"Effects is everywhere, you and Svelte cannot do anything without effects. Avoid overusing effects!
This screams read the full page or you will miss out to the uninitiated. Also this is a direct contradiction with the when not to use effect section which heavily tempers this statement.
alternative to #14060. In general we should put documentation on the functions themselves — that way there's a single source that populates everything.
It's also good to use realistic motivating examples where possible — in particular it's good to avoid
console.login examples of effects, since it's better to use$inspect(particularly when dealing with state proxies).