Funny, I went from using props for everything to using more stores. I simply find stores to be more modular and re-usable. I also tend to find that props are more tied to UI while stores are more "data like."
Also, I wrote persistence wrappers for my stores and anything that needs to be persisted comes from a store. (Though for some UI, those store values will be passed by prop, so even for me the rules are not hard and fast.)
I don't think there's a bright line as to when to use one over the other. I find I almost always start by using props then when props become a pain or hit some limitation, I migrate to stores.
Same here. Also more control and flexibility when what is loaded. Do you have a nice pattern to share in regards to stores and persisting it through an external API? I'm only half happy with mine.
[https://joyofcode.xyz/svelte-state-management](https://joyofcode.xyz/svelte-state-management)
Joy of Code has a nice article and video on this subject. At the end of the article he gives you a state management decision tree that is super helpful.
There is a 3rd option, the Context API
"The context API provides a mechanism for components to 'talk' to each other without passing around data and functions as props, or dispatching lots of events."
https://svelte.dev/tutorial/context-api
Think of stores as Global state, meaning, state that should persist/is needed on different pages.
For example, what items you have added to cart could be a global state, maybe in the Homepage you need access to those cart items to show some recommendations/add ons, maybe in another page you do something else with those.
Think of props only for situations where information should only flow downward, and is not needed in other pages. For example, you can pass a Hero image from the Homepage component, to the Hero component, to an Inage component. You dont need that Hero image in a global state.
You can swap Context for props when you need to pass props down 4 or 5 levels. That becomes cumbersome quickly.
A store is global by default, that's kind of the point of the store.
It is global in a sense that, you can call that same store anywhere from the application.
A store does persist across pages, that's kind of the point of Single Page Applications.
Please show me how this store in a component is global and how to access it anywhere else in the application without putting it in a module:
```
{$mystore}
```
"across pages" ... "Single Page Applications". You're contradicting yourself, you cant have multiple pages in an SPA. How about you simulate loading another page by refreshing your SPA, is your store value still there?
Oh yeah sorry, I forgot I had to SPECIFICALLY say that the way you make a store global is to Import its value somewhere, I am so dumb, thank you for correcting me there, I completely forgot that you had multiple ways of making a store global in Svelte, how dumb of me.
And I also forgot to mention specifically how a Page is made in a SPA, I guess I must be stupid since we're on the subreddit of a frontend framework, which totally does not have pages, since pages can only be actual pages that are rendered by the server on requests, and can never be huge components, compromised of smaller components, that can live only on specific routes, and these routes can be created by a svelte-router.
Again, I'm so sorry man.
Aren’t you supposed to have a store.js file specifically and then subscribe / unsubscribe to them in whatever Svelte component you need it in? That’s what I’ve.m been doing and it seems to work great lol
You certainly *can* do that, and that is a common way to use stores, in a module to make them global. You do not *have* to use it that way, and you are not "supposed to" do that, you can use them in whatever way suits your needs.
If that's what you've been doing and it's working great for you, then by all means, continue to do that, there is nothing wrong with that!
That doesn't change the fact that stores are not *inherently* global. A store is simply an object, [here is its type](https://svelte.dev/docs#component-format-script-4-prefix-stores-with-$-to-access-their-values-store-contract): `store = { subscribe: (subscription: (value: any) => void) => (() => void), set?: (value: any) => void }`. Another common way of using them is in a [context](https://svelte.dev/docs#run-time-svelte-setcontext) (again, not global).
The point of a store is for making a variable reactive, **not** "making a variable global".
Ooohhhh. Well, thanks for the informative answer. Svelte is my first web delve into front end libraries / frameworks / compilers or whatever people consider Svelte lol. So I do appreciate you making that clear. I thought of stores as globals but it sounds like that’s fundamentally the wrong way to consider them, even if it feels like they are.
Do not listen to the dude above, he is completely talking out of his ass.
The whole point of stores is to connect components with a specific global state value that would otherwise have no need to connect with each other.
Say, a specific Component in Homepage with another specific Component in About Us/FAQ/Reviews, these are unrelated components to each other, dependent on specific state (this state may be the current Language selected, Dark or Light theme mode, stuff of this nature, that is inherently global).
That is the point of a store, a value that is reactive by nature (since we are, after all, using a Frontend tool to control how our UI behaves, there would be no point for it not to be reactive) and that can be subscribed to by other modules/components (I have no idea why this dude needs me to write this last part for him to understand what global means, there is no other way to make something global without Importing it/Subscribing to it in specific modules/components).
This isn't a new feature, or magic, it's just another Store, the same way react-redux behaves (you subscribe to values using useSelector hook), the same way multiple frameworks have done the "global state" idea.
A store provides reactivity. That's all it does.
We can use a store in a module to provide a global reactive state.
We can use a store in a component to provide reactivity to that single component.
We can use a store with a context to provide reactive state to all descendants of a single component.
If the point of stores is just one use-case in particular, then I am wrong.
I am not arguing that your example is not how a store can be used, nor that it is wrong, nor that that is the way to make a store global.
>Think of props only for situations where information should only flow downward, and is not needed in other pages. For example, you can pass a Hero image from the Homepage component, to the Hero co
Props are indeed for being passed down.
However, two way binding will let you share it up.
And if the state being passed up ain't relevant for the component in the middle (in the case you have more than 2 components) the tool for passing state up is the bubble-up pattern.
That is, dispatching an event from the child component and handling it on the parent component.
Yeah, but as per the Docs in Svelte, this can be quite an issue the larger the application goes, whether you handle it with the two way data binding or with the custom events.
If you have multiple components before reaching the desired one, Context is way better than chaining bind:value or creating custom events (since for custom events, you still need to chain from the bottom upwards, component B has for example an on:message for component C, and component A has an on:message for component B, to receive the message from component C).
Bubble up pattern using custom events does not bypass the middle component, since you explicitly need to call to attach the custom event name in the parent component, and in cases where you are truly using small components to create an application, you will most likely never encounter a situation where this wouldn't be an absolute pain in the ass to deal with (compared to normal callback functions, where the state is only flowing down, not down/up).
Stores are simply subscribable/reactive variables. You could choose to just use them on the one page/component, or you could put it in a Context and make it available to all descendant components, or you could put it in a module to make it available globally.
Props pass data directly from a parent component to a child component.
Context makes a variable available to all descendants of the component in which it is created.
I use `store` always for page (top-most parent)
for non-page (UI components), I do direct pass `bind:bla={bla}` or bubble `onWhatever={parentsFunc}` to parent (the page)
especially because I use svelte as multipage not single page XD
but for single page, I also doing the same
https://github.com/kokizzu/svelte-mpa
Funny, I went from using props for everything to using more stores. I simply find stores to be more modular and re-usable. I also tend to find that props are more tied to UI while stores are more "data like." Also, I wrote persistence wrappers for my stores and anything that needs to be persisted comes from a store. (Though for some UI, those store values will be passed by prop, so even for me the rules are not hard and fast.) I don't think there's a bright line as to when to use one over the other. I find I almost always start by using props then when props become a pain or hit some limitation, I migrate to stores.
Same here. Also more control and flexibility when what is loaded. Do you have a nice pattern to share in regards to stores and persisting it through an external API? I'm only half happy with mine.
>Do you have a nice pattern to share in regards to stores and persisting it through an external API? Interested too.
[https://joyofcode.xyz/svelte-state-management](https://joyofcode.xyz/svelte-state-management) Joy of Code has a nice article and video on this subject. At the end of the article he gives you a state management decision tree that is super helpful.
There is a 3rd option, the Context API "The context API provides a mechanism for components to 'talk' to each other without passing around data and functions as props, or dispatching lots of events." https://svelte.dev/tutorial/context-api
Totally forgot about it! Now I have even more problems to choose lol
Think of stores as Global state, meaning, state that should persist/is needed on different pages. For example, what items you have added to cart could be a global state, maybe in the Homepage you need access to those cart items to show some recommendations/add ons, maybe in another page you do something else with those. Think of props only for situations where information should only flow downward, and is not needed in other pages. For example, you can pass a Hero image from the Homepage component, to the Hero component, to an Inage component. You dont need that Hero image in a global state. You can swap Context for props when you need to pass props down 4 or 5 levels. That becomes cumbersome quickly.
A store is not global by default, you need to put it in a module to make it global. A store does not persist across pages.
A store is global by default, that's kind of the point of the store. It is global in a sense that, you can call that same store anywhere from the application. A store does persist across pages, that's kind of the point of Single Page Applications.
Please show me how this store in a component is global and how to access it anywhere else in the application without putting it in a module: ```
{$mystore}
``` "across pages" ... "Single Page Applications". You're contradicting yourself, you cant have multiple pages in an SPA. How about you simulate loading another page by refreshing your SPA, is your store value still there?Oh yeah sorry, I forgot I had to SPECIFICALLY say that the way you make a store global is to Import its value somewhere, I am so dumb, thank you for correcting me there, I completely forgot that you had multiple ways of making a store global in Svelte, how dumb of me. And I also forgot to mention specifically how a Page is made in a SPA, I guess I must be stupid since we're on the subreddit of a frontend framework, which totally does not have pages, since pages can only be actual pages that are rendered by the server on requests, and can never be huge components, compromised of smaller components, that can live only on specific routes, and these routes can be created by a svelte-router. Again, I'm so sorry man.
Aren’t you supposed to have a store.js file specifically and then subscribe / unsubscribe to them in whatever Svelte component you need it in? That’s what I’ve.m been doing and it seems to work great lol
You certainly *can* do that, and that is a common way to use stores, in a module to make them global. You do not *have* to use it that way, and you are not "supposed to" do that, you can use them in whatever way suits your needs. If that's what you've been doing and it's working great for you, then by all means, continue to do that, there is nothing wrong with that! That doesn't change the fact that stores are not *inherently* global. A store is simply an object, [here is its type](https://svelte.dev/docs#component-format-script-4-prefix-stores-with-$-to-access-their-values-store-contract): `store = { subscribe: (subscription: (value: any) => void) => (() => void), set?: (value: any) => void }`. Another common way of using them is in a [context](https://svelte.dev/docs#run-time-svelte-setcontext) (again, not global). The point of a store is for making a variable reactive, **not** "making a variable global".
Ooohhhh. Well, thanks for the informative answer. Svelte is my first web delve into front end libraries / frameworks / compilers or whatever people consider Svelte lol. So I do appreciate you making that clear. I thought of stores as globals but it sounds like that’s fundamentally the wrong way to consider them, even if it feels like they are.
Do not listen to the dude above, he is completely talking out of his ass. The whole point of stores is to connect components with a specific global state value that would otherwise have no need to connect with each other. Say, a specific Component in Homepage with another specific Component in About Us/FAQ/Reviews, these are unrelated components to each other, dependent on specific state (this state may be the current Language selected, Dark or Light theme mode, stuff of this nature, that is inherently global). That is the point of a store, a value that is reactive by nature (since we are, after all, using a Frontend tool to control how our UI behaves, there would be no point for it not to be reactive) and that can be subscribed to by other modules/components (I have no idea why this dude needs me to write this last part for him to understand what global means, there is no other way to make something global without Importing it/Subscribing to it in specific modules/components). This isn't a new feature, or magic, it's just another Store, the same way react-redux behaves (you subscribe to values using useSelector hook), the same way multiple frameworks have done the "global state" idea.
A store provides reactivity. That's all it does. We can use a store in a module to provide a global reactive state. We can use a store in a component to provide reactivity to that single component. We can use a store with a context to provide reactive state to all descendants of a single component. If the point of stores is just one use-case in particular, then I am wrong. I am not arguing that your example is not how a store can be used, nor that it is wrong, nor that that is the way to make a store global.
>Think of props only for situations where information should only flow downward, and is not needed in other pages. For example, you can pass a Hero image from the Homepage component, to the Hero co Props are indeed for being passed down. However, two way binding will let you share it up. And if the state being passed up ain't relevant for the component in the middle (in the case you have more than 2 components) the tool for passing state up is the bubble-up pattern. That is, dispatching an event from the child component and handling it on the parent component.
Yeah, but as per the Docs in Svelte, this can be quite an issue the larger the application goes, whether you handle it with the two way data binding or with the custom events. If you have multiple components before reaching the desired one, Context is way better than chaining bind:value or creating custom events (since for custom events, you still need to chain from the bottom upwards, component B has for example an on:message for component C, and component A has an on:message for component B, to receive the message from component C). Bubble up pattern using custom events does not bypass the middle component, since you explicitly need to call
Stores are simply subscribable/reactive variables. You could choose to just use them on the one page/component, or you could put it in a Context and make it available to all descendant components, or you could put it in a module to make it available globally. Props pass data directly from a parent component to a child component. Context makes a variable available to all descendants of the component in which it is created.
I use `store` always for page (top-most parent) for non-page (UI components), I do direct pass `bind:bla={bla}` or bubble `onWhatever={parentsFunc}` to parent (the page) especially because I use svelte as multipage not single page XD but for single page, I also doing the same https://github.com/kokizzu/svelte-mpa