You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I did not realise that $effect can be used as a drop-in replacement where Svelte4 code that uses subscribe() to a store value - despite reading and revisiting the documentation several times.
This despite being now quite comfortable with $state runes and replacing most of my stores with them.
I suspect that many Svelte4 developers will be accustomed and comfortable with the idea and the terminology of "subscribe".
And is not $effect effectively an implicit subscriber? I have now found switching my subscribers to $effects is painless and produces clearer code.
Describe the proposed solution
I think that explaining in the documentation that $effect can be viewed as an implicit subscriber, and as being a good replacement for the older subscribe function will greatly speed up and ease people "getting" it.
I've made a similar suggestion suggesting the same pattern in this issue #14975
The pattern I'm advocating in both issues is to get people on the "right page" conceptually by leading the narrative with the problems that a feature solves, or example use cases, and only then explaining how the feature is a solution.
Importance
nice to have
The text was updated successfully, but these errors were encountered:
Describe the problem
I did not realise that $effect can be used as a drop-in replacement where Svelte4 code that uses subscribe() to a store value - despite reading and revisiting the documentation several times.
This despite being now quite comfortable with $state runes and replacing most of my stores with them.
I suspect that many Svelte4 developers will be accustomed and comfortable with the idea and the terminology of "subscribe".
And is not $effect effectively an implicit subscriber? I have now found switching my subscribers to $effects is painless and produces clearer code.
Describe the proposed solution
I think that explaining in the documentation that $effect can be viewed as an implicit subscriber, and as being a good replacement for the older subscribe function will greatly speed up and ease people "getting" it.
I've made a similar suggestion suggesting the same pattern in this issue #14975
The pattern I'm advocating in both issues is to get people on the "right page" conceptually by leading the narrative with the problems that a feature solves, or example use cases, and only then explaining how the feature is a solution.
Importance
nice to have
The text was updated successfully, but these errors were encountered: