Don't Sleep on Svelte 5
HTML-код
- Опубликовано: 13 сен 2024
- I think the changes introduced in Svelte 5 are great, and in this video, we'll build out the same feature once using stores, and again using signals in Svelte 5 to showcase how much better Svelte 5 makes composition.
REPL: hbyt.us/signal...
Joy of Code's Svelte 5 Runes Introduction:
• Svelte Runes Change Ho...
(tell him he'll be hearing from my lawyers about the thumbnail copyright 😉)
🚀 Modern SaaS Course: hbyt.us/modern...
💬 Discord: hbyt.us/discord
🐦 Twitter: hbyt.us/twitter
🖥️ Setup Stuff: hbyt.us/gear
📃 Topics Covered:
- Svelte stores
- Svelte writable
- Svelte custom store
- Svelte 5 runes
- Svelte signals
- Svelte 5 composition
- Svelte 5 state
- Svelte 5 reactivity
- Stores vs Runes
- Svelte 5 stores
- Svelte 5 performance
- Svelte 5 examples
Runes even in their primitive form seem to add so much value. Great insights, thank you!
I agree, it's super cool to see the things people have been creating with them, like Solid's createSignal, Vue's ref, etc!
People disliking runes because of the API is dumb IMO. They just saw the word "state" and "effect" and got scared, but didn't stop to think about the performance and readability improvements that are possible with this. I think it's the right move, and this video shows one very clear reason why
Mostly people still in todo app phase from freecodecamp, nothing to be worried about
OK. now that was a CLEAN explanation, natural teacher 👨🏫 Thanks!
Thank you! I'm glad you received it well!
Lovely how natural runes are looking now. For me, the most important is that you write it very similar to the thought process (at least mine lol). On React i feel that the code gets all around the place so quick. Svelte has been a breath of fresh air :D
Totally! It'll become second nature for everyone after using it for a bit! I actually tried typing $state() in a Svelte 4 codebase this morning 😂
As someone who is learning Svelte now I definitely think the new way is more intuitive
That's great to hear!
I think this was a great example to quiet all those memelords going "Svelte is becoming React" as a response to the latest announcement. You clearly show it is very much still Svelte minimalism/simplification even when introducing things from react frameworks and libs.
Mostly people still in todo app phase from freecodecamp, nothing to be worried about
I would definitely appreciate if you did a deeper dive on runes, because even with this I was completely clueless about how the $state rune can simplify logic that you showcased
Would love a deeper dive. This is honestly not sinking in yet, but as soon as you showed the last example I realised how clean some of my code could become. Intriguing.
Signals in Svelte look so smooth and elegant. This is a great step ahead, cool!
I’m excited about signals! Huge change and improvement
Nice demo, thx!
That is a good explanation! Thank you. You get me excited about Runes
This was a well structured and informative video. Best runes video so far
Thanks ! Nice video
I would love to add one thing that is very hard to do today with svelte 4, and will be completly natural with svelte 5.
If you use OOP (Class and stuff) you may need to have items with stores inside for managing reactivity. Like, for exemple, class Todo, could have a 'done' property set to writable(false).
And then you might want a store to manage all your todos. Like todos = writable([]).
You may often need to filter your todos based on their 'done' state. But look how crap it is :
If you do $todos.filter(todo => get(todo.done)), this will work once, but if one of the todo 'done' property changes, it won’t be reactive since todos won't be reassigned.
One thing you can do, but it's ugly, is, every time you update 'done', notify todos like todos.update(i => i). OK.
But now imagine that you have nested Items list in your items list with store properties and you want to filter at the root… its starts to get impossible to manage. For exemple, you have a Label class, with an 'active' writable todo.labels.filter(label => label.active).length === 0)))
And it works !!!
Try it out svelte-5-preview.vercel.app/#H4sIAAAAAAAACnWTTZObMAyG_4pLM2OYYUnaYwrZ9rCdHtpbbyEHLxaJp8ZmbJFuhuG_d2RDNvvR4WLpkaxXQh6TVmnwyXY_JkZ0kGyTb32f5AleejL8GTRCkifeDq4hT-kbp3rc1aY2NTZaeM9-ikfQbCRHjaJBdQZWsZVHgZCiGyAjNM0p1nhkIPyFVczA35idZs_sJJz8H-vUW3TV8dtKu8jQhP2zjP1hDp1vckOD1qUxLJuTlrT7orXuQTSnyFm1Y3hSvoi06Ac_kyyLidObBtFKe1s-xpFwUpnuaQCHLH_tpt7fcXdKBv24dHFT5LvSCA5oLisJTp1BpjE_4KINPF06JGdoyEq7NDSHXJsNhyL-yazQYI54YlVVsU28JUjJvgTD1LhSxvfQYPpCT1Barm_2Zfzojep7wFggpY3LmULosjDA8nFAtIZZ02jV_KnGNCM1FFBc1-rDjTnt5tWjmyY23kbeM648iwZn22DZtuVTuY5ldrUZ17Og8OtKqc7M40XDthPuqEzFN2zDPn3un9iGz0Qq32txqXir4Wlx0vlOKgcNKmsq3lg9dGahQqujuSNtvuINGAS3oKPoK04FOKn56sBIcPN0-IPwF56Hp0LzeY1_KclzehDvwR_CEaV1IlyupTrHNxu-JE86K1WrQCZbeqHTYfoHvYkkSAwEAAA=
Great video dude! 🤙
Thanks for the explanation. I guess it will take a while to get used to this new system of reactivity. Mixed feelings tbh.
That's another great thing about the update is that you plenty of time to get used to it with the backwards compatibility! And stores aren't going away, you just may not reach for them as often when the same can be accomplished with better performance and cleaner composability!
@@Huntabyte yes, I like that. :) One big drawback of these kind of smooth transitions, though, is that a large codebase (I work in a project with literally thousands of Svelte components) will have both versions, and the transition will probably never be complete. This can produce mental overhead. Which system should I use in this component? And this can also get quite tricky for beginners. To be honest, I would have preferred to make it NOT backwards compatible.
@@ScriptRaccoon So I was actually trying to find a place where migrating to 5 in one place breaks something using just 4 and I seriously couldn't produce an example, so it appears they have the ground covered well. Otherwise, I'd agree with you 100%, but I do see the _why_, especially considering the amount of potential changes (this is just the first preview of Svelte 5!)
i just liked your video, bcz everything you said is gold!
Svelte stays simple. Before it was simple magic, now its more like simple obvious. And to be even more relevant, it is obvious for new joiners.
I understand some hate to signals, but after developing a whole component library I see the use for these. My current notification toast and modal would be much easier with signals.
Svelte is the only UI framework that seems to evolve instead of just adding more stuff, like React and others. Weights less, is faster, is simpler. I bet on it.
I completely agree!
Finally some actual content about runes instead of everybody crying over linguistics and making piss poor comparisons to X/Y framework. As a software engineer, I feel like software engineers are the most miserable people in the universe.
No lies were spoken in your comment 😂
Agreed! Been coding nearly 30 years, never a truer word said
Thanks for the video. As a newcomer to Svelte (and frontend in general, really), I have a hard time wrapping my head around the store approach. The approach that Svelte 5 offers seems way simpler.
Hi man, could you indicate me the resources on how is intended to capture the press of the cancel and action button in the shadcn-svelte alert dialog? Thanks for your work!!
Killer video! I actually thought of your video from the other day and took that as a refactor experiment this morning.
I knew this change was coming and wanted to have that out as an example to point this video to (as well as for use until 5 is released of course)!
As always; excellent content! I think it will become more obvious when using an object with a few values that need reactivity as you can individually re render those values with signals instead of renewing the whole object every time a value changes with stores. Great for SPA development for instance or the use of state machines. Maybe a nice video for beginners in Svelte?
Awesome! I'll dive deep into runes/siginals
Oh this is nice, it works similar to pinia setup stores
I think the svelte 5 store, as per the video, if used directly in multiple components will initialise a new store each time it's used. If that is not the desired intent, I think you can initialise the store once at the bottom of the file and export that initialised store instead. (I'm assuming there's no issue doing it that way with SSR)
im new to svelte i came from react and i love the new runes update
it drives me crazy repl doesn't support typescript... 😢 Great video!
Was just talking about that yesterday after looking at the Solid playground 🫠 hopefully soon!
Because it's not Typescript, it's SvelteScript :) they need to rewrite their language server to support new syntax
@@JLarky - Considering Svelte is sort of its own language with a compiler, why not just make it have its own types too... would be interesting... no ts, no js, ss for sveltescript lol, sort of
@@jonathangambleYep, that is actually a great idea.
One minor gripe with the code you ended up with: that curr setter isn't very intuitive; I'd replace it by a method named "save".
Another thanks for the explanation!
You're welcome!
I live under a rock.
Patrick?
Nice video. Very clear
Glad it was helpful!
Great video as always! Are you guys planning on updating Melt-ui to use signals as well?
That’s the plan!
Nice explanation. Thanks!
For a newbie like me, what are the benefits of Svelte now compared to React or Vue, for example? The first time I saw Svelte I fell in love with its simplicity, now I don't see how its advantages over Vuejs, for example. Now Vue looks more simple to me. All my excitement to learn Svelte has completely gone.
It’s even simpler than it was before. They’re able to eventually drop a ton of API surface with a few runes! Additionally, it makes building libraries and more complex apps better as well!
Lovely vid , cant wait till it gets released
The changes lower required mental effort. Just make every value you want to make reactive a $state rune, and that's it. Way simpler than before.
Exactly. In every file, which is incredible!
I definitely enjoy the simplicity of Svelte 3, but I certain see the importance of having a more explicit API especially for use in pure js files
Thank goodness, it's finally making some sense. I've watched a handful of "introduction to runes" videos, and it just didn't click for me. I've only made a single web project in my life, and I did not need stores for it, so to me runes seemed to complicate syntax as opposed to simplify.
I have some new functionality planned that will need stores, so I'm crossing fingers this will get released before I'm forced to implement that. It would suck to have to learn stores such a short time before runes make them obsolete.
Seems like a Derived store would've been far simpler than implementing custom logic into the writable set
Can you provide an example REPL? Curious to see, as when I tried using derived it became a mess because derived is updated after something changes, not before and doesn't include the current / next values.
I've already complain about how stores work different in Svelte files and JS/TS files (even in context module they are different), it is good to have only one way to use things, I have to be honest, "state", "effect", these names are weird in Svelte world, they remaind me React, but at least you have not getters and setters for each state like in React, and you don't have to use state.value or state.current like in Vue, the getters and setter in this video are only due to function boundaries, this is great, a $state is only a thing to tell the compiler what to do, but its usage still the same.
That's the thing with this runes, they are signals -> you can do signal without svelte. I hope next feature before svelte 5 release are islands.
Omg - thank you. I get it now!
Mission accomplished!
Maybe a stupid question but how would you unit test a function that involves runes $ syntax (eg withPrev.js here)? Needing to render a component in order to test the function seems a bit hacky, and the js wouldnt run without being compiled
Do you use vitest? Should work fine
@@tom400iq6ft I’m not following, using $state in a JavaScript file throws an error, would vitest compile it? (When this is released)
I am really excited for the changes but have a few worries.
Yes, the new system is super powerful if you use stores the way you showed, but in reality, I use stores in entirely different way. For me they are a global bucket for the whole application, which I know I always can access and for safety I can implement a few functions around these stores, but I have never done them in the way you showed in this video.
This new store system feels more like redux toolkit, which is actually really good, but I got so used to these svelte stores, because they just clicked with me and I feel like I can't use them in any other framework, but now I won't be able to use them at all it seems.
Anyway, I'm really excited about the changes, the old system was really good for simple solutions, but for more complex ones it could become a bit of a mess, I'm sure the Svelte team though about things like that and I will trust their decisions.
They will provide helpers to easily make something like a ‘writable’, so if you aren’t writing custom stores today you will not even see the internals, but still get the performance boosts
Great stuff! Thank you… how about a more complex example using objects please. Would we still need to do $someStore = $someStore to trigger reactions to a list being modified for example?
Nice example.
Its a bit offtopic, but I would use a class instead of a factory function. Just because intellisense works better with classes, at least in vsc.
You could certainly do that as well!
So, Stores now become what? Runes? Signals? What is the official name. I am so confuse of what is Runes, what is Signals.
That’s a new one for me. Same syntax, different result:
let curr = $state(initialValue);
curr = prev;
First line gives a variable ‘curr’ a new value. Second line doesn’t give a new value to the variable ‘curr’ but does something to the state of the current value of ‘curr’. Confusing to have the same syntax for two different operations. I understand the convenience, but confusing none the less..
Very nice video ! Do you advice to wait for Svelte 5 before starting learning how to use Svelte?
Absolutely not!
@@Huntabyte Ok, thanks for the feedback.
Hi there. just want to ask if there is a rich text editor that you can suggest? Thank you very much
Why does one need the update function? And why not use get method?
function set(color) {
prev.set(get(curr));
curr.set(color)
}
function undo() {
curr.set(get(prev));
prev.set(undefined);
}
What are your thoughts on snippets + render? Will you be refactoring shadcn-svelte/bits to use them instead of multiple .svelte files? Just subscribed to your channel. Thanks!
Love them! I’ll have to see what makes the most sense once 5.0 is production ready!
Very well explained. After watching your video, it occurred to me that what runes are trying to accomplish this fine grained reactivity where the variable can carry their own reactive state instead of relying on an external component such as store to do it or using any special compiler magic which can do this only for svelte file with special $ prefix syntax. This is a really powerful concept. Your video makes this amply clear. Kudos to the svelte team for recognizing the pain of coerce grained reactivity which ironically when it was introduced was one of their selling point over react. Also the fact that they are making transition so smooth is amazing.
I used to love store for its contractual flexibility which made it possible to use external libraries such as xstate and rxjs to be used as store. I am wondering if you have any thoughts on how it can be accomplished using runes. Would a simple wrapper function work?
Yeah! There’s been a few examples in the runes channel in the svelte discord already. If you need start/stop notifiers then you can of course stick to stores for things like that, as they’re still a first class citizen, you just won’t reach for them _as_ often in Svelte 5!
Nice Onee
Thank you!
I hope u dont check the box on creating a vid on how to make these composable funcs because this is the superpower i want to be great at. Id love more of these and maybe take it to the next level of complexity. For example today I was trying to do this and trying to nest composable funcs like one composable func is create_counter() and another create_player_scores() so im trying to use the counter attatched to each player that gets added
There will definitely be more to come, you can even have `$effect`s in these as well which can unlock even cooler things :)
I think this could potentially simplify some of those instances where we reach for svelte-subscribe, but I'm not exactly sure if my intuition is correct. I've always hated having Subscribe components polluting a page in order to solve what is essentially just a limitation of stores in their present form.
100%
But if you use color across multiple components, do it update as store do?
If you defined it in another file like `signals.js` and exported it from there, yes, it works the same way!
For me, the store syntax is simpler, since you can pretty much understand it by knowing javascript, and signals feels more magical, and the fact that it usses setters and getters makes it event more complicated for newer devs (there are many articles against them)
I disagree that signals are more magical than stores. The reactive syntax with stores is at least as magical, especially because it's not a native JS feature, and it's much harder to learn imo. Also, the fact that store reactivity has so many weird edge cases about when you can and can't use it is a significant complexity hurdle.
I disagree that the store syntax is more simple. You have to first learn how stores work, how to update them, the updater callback it takes in, etc. vs. get curr() reads exactly like what it does.
By the way, you do not have to define an update function for stores, it's not part of the interface.
The only things that matter for Svelte are subscribe & set.
If I want it to provide the same API as the writable then I do.
@@Huntabyte Well, yes, but it's useless most of the time.
Update is primarily useful outside of components when writing stores and most stores are consumed within components, so unless you are going crazy with custom stores being used by other custom stores or functions in plain JS, you usually just don't need it.
Just checked one of my applications, which has about 180 components and I use update in 2 TS files a total of 4 times.
@@ELStalky It's a strange you point you're trying to make. It might not have been useful in your experience but it could be in someone else's.
@@maelstrom57 I am just noting that if you are not writing a library, you don't have to bother with it most of the time so you can probably spare yourself the effort.
Is there a way to destructure store without losing reactivity?
Unless there's some magical restriction I'm not aware of, you could simply use methods instead of getters/setters.
{
getCurr: () => curr, // etc...
}
const { getCurr } = withPrevSignals("green");
I'm on day 1 of a pattern i may really like. Make one giant composition function intended for a +page and all components that may be used on it.
Define this func in independent js file and also define another var immediately after that calls that func to set as a global store. We then import that global var in any component and call methods
You would instantly call say my_data_manager.init(data) when u get server data in export let data methods.
Then u can put all the messy stuff in that and just import the pretty state and methods in components.
Its day 1 tho ill keep building and evaluating
I'm glad you're already experimenting with the different patterns. This update really adds a lot of composition power which I personally love the most about it!
@@Huntabyte ya so many ideas to discover. Even things like init the composition func on the server somehow could be interesting since im sending data through func after i get
How do we subscribe to Runes ($state)?
You don’t have to subscribe!
looking at the update function really makes sense why this make sense to introduce runes.
I felt Rich Harris speedrun the demo and didnt do it justice
I don't understand how $state is available from a normal .js file if it isn't included. How does that work?
Compiler!
@@Huntabyte But, it's supposed to work outside of Svelte files? 🤔
@@ilu1994 The compiler can read more than just .svelte files!
Why do we need get and set though?
Rich Harris made a video on this on his RUclips!
I really don't get the need for runes, I'm sorry, what's stopping us from sticking an "await tick()" in between the assignment and next read inside the function?
Cause as far as I can tell the only issue here is the component render delay, all it takes to fix the whole thing is one single 'await tick()'.
Not to mention you only have this issue in .svelte files.
At least it's opt in, hopefully the old "$:" syntax won't get deprecated in favor of runes, runes are much less readable.
Will Svelte 5 break code in previous versions?
Nope!
This store definition was great. But with derived stores it could have been way cleaner and easier to read. And compare
Can you provide an example? I tried with derived at first but it ended up being more complicated in that derived is only called when the value of the store it depends on changes, so getting the prev value. Curious to see how you’d clean it up!
Honestly, I felt extremely comfortable using stores.
Stockholm syndrome
@@Huntabyteyes, svelte 5 doest that.
Cant' really understand what frontend frameworks which mostly are opinionated what they are trying to achieve... I need just dead simple CQRS pattern on the frontend, which libraries like Tanstack or RTK have baked in... Also if we talking about jumpwagon on observability (but rxjs was crap), it's the only missing feature of js language, besides types...
sorry but I never saw where pople use Svelte store like this. It's not a real use case. Ussualy it's much much simpler and this is why runes not a replacement. Basicaly you implemented API/CRUD base on Store.
yep, you just not realy understand how to work with Svelte store, this example is not legit. Even more - you example can be even easier to implement without $state !
😂
Sorry, for my emotional reaction. If somebody used a store like this it's a valid example but I never used stores like this, for me it's very unnatural.
I would bet some libraries you regularly use have these patterns internally. Another thing to think about is maybe a lot of people haven’t used patterns like this _because_ it’s overly complex and annoying.
this way it's not Svelte anymore
Not Svelte 4 :)
I find having to write "color.something" much more verbose than simply "$something". I like the experience when it's about writing the functionality but not when it's about using it.
Defining props is much less clean with runes, binding to them is weird and no destructing is also annoying.
Remember, stores are going absolutely nowhere. Meaning, if you have some sort of “global” state that’s a simple single value, you can still use a store! Maybe for something like “darkMode”. But for more complex state, like an object, you’d be doing the dot notation with stores anyway! (unless you destructured, which you can’t do in runes admittedly). Just remember that if your thought is “my global state was so simple it had no problems with stores” that’s great, you will forever be able to use them! Runes are meant to make the more complex parts more readable and performant!
too much magic arrghh
You think? I feel like Svelte 5 makes it feel _less_ magic than Svelte 4, but I embrace and appreciate the magic!
I'd rather see some real world examples of new syntax without constantly comparing with the old way. It's distracting .
Me: 🛌