🍪 Svelte Snacks. Todays episode, updating a variable/state management. One of the things that draws me to this language is the fact that it attempts to stay as close to vanilla as possible while thoughtfully abstracting out things we do everyday in web dev.
A lot of times in UI dev, we need to capture data from the user. Here's an example of a .svelte file that binds the input value to state. In Svelte, things defined in the script tag are accessible in the template using {curly brackets}. You can also put any JS expression in {}s
In the above example, whenever a user adds text to that input field, it will automatically be assigned to the "value" variable. And notice the reference to {value} in our template? That <p> tag will contain the <input> text and auto update whenever it changes.
Go try it! You can also have an object and then bind <input/>s to object properties of course. It's all just variable references in the end and Svelte will follow all of them for you and update only the things that need to be updated. svelte.dev/repl/7f4f52bc9195455ead9e4f78d3f12e1e?version=3.55.1
This is great for local state. A user could fill out a form with all of their values and then in this component we could have a submit function that sends it all off. But what about global state? Can we really manage app state with these simple patterns? Probably 🤷🏼♂️
For global state, Svelte has "stores". A store is just a normal JavaScript variable with the added benefit of being able to subscribe to it. If the a store value is ever changed in one place, all other things/components using the store will also be refreshed.
Bear with me for a sec, this isn't the most common usage of accessing stores but I want to explain how they work and why they work so well in Svelte. When you Create a store and import it, you have the following methods. .set(), .update(), .subscribe().
See that subscribe method at the bottom? This pattern of a .subscribe() method that takes a callback that gets the value as the first arg isn't unique to Svelte and often used in subscription models. Svelte adheres to these standards
and adds a cool abstraction to these subscription patterns to tap into them, the "$". In .svelte files you can prefix stores with $ which stands for "subscribe, get the value, unsubscribe, give me the value". Allowing you to use stores like normal variables. These are the same.
You can use this with other frameworks too that use this pattern like XState. You could use Svelte's $ on that "service" instance to get the value of the state machine and subscribe to it like a store value.
Any component in our app can import user store and read whatever the value is with "$". You can even set it or bind to it like any normal variable making them uber convenient.
Stores are great, but there isn't really a state management framework in place. Svelte is BYOS (state manager). For most small projects stores are all you will need. You could even organize them with a nice map and add setters and getters to keep it all clean and roll your own.
Here's how I like to build stuff tho..
- SvelteKit (Svelte + backend, like Next): kit.svelte.dev/
- SvelteQuery: sveltequery.vercel.app/
- tRPC: trpc.io/
When you setup tRPC in SvelteKit, there's also this available library called trpc-svelte-query-adapter which lets us combine SvelteQuery and tRPC to create queries that are mapped to tRPC endpoints. This lets us import queries and "$" them to get data, no more "fetch()" + typed.
The above is an example of a get price endpoint and how you could use it in Svelte with this setup, so clean! When you subscribe to that query store it will fetch data if it doesn't have it or reuse existing if it does. you can also query.load() to manually refetch at any time.
Thanks for reading! LMK if you have any questions or ways to do it better. Happy building 🚀
Meh Discord discord.gg/rQt2Y59pz7