Welcome to Syntax on this. What? No, I'm trying to be animated because it's going to be on video now. Although, should we do a little bit of faces first?
Yeah, let's just leave all this in, okay? Welcome to Syntax, and this is episode number 723. We're going to be talking all about Svelte 5, what you need to know, what's important, what the big picture stuff is, and what it's all about. And you know what?
Welcome, everybody. This is officially the first video episode of Syntax. Now, you may have seen some prior episodes being popped up, but we decided to just take some of our best episodes of the past couple of months and just throw them up, and those weren't actually recorded as being a quote-unquote video podcast. So, this is going to be the format going forward here, and you may see some tweaks along the way.
And what we're going to be doing here, don't fret for all you audio listeners out there, not much is going to change for you. We're not going to be describing things that you're seeing on screen. You know, perhaps in the future, if we are talking about code, we'll be showing some code, but we're not going to speak about it any differently than we are currently. So, welcome, Wes.
How's it going? Going good. Pretty stuff to be here. I've been awesome with my mic and everything.
Have we even, like, should we introduce Randy, or what episode do we introduce Randy? Maybe we should introduce him on the Potluck episode. Randy, you're just going to have to sit in the shadows for one more episode, and then we can introduce you into the next one. We're going to want to make sure that you have error and exception handling tracking because, hey, if you introduce anything, you could break your code.
You know what breaks code? Writing code. If you write code at all, well, you'll have an opportunity to have a bug slip in there. And more than just bug tracking, I think this goes right along with some of the messages of Svelte 5.
You want to be tracking that speed and the size of your code base, and that's one of those things that Svelte 5 really nails, and Sentry can do all of that for you. You can see exactly how fast your application is running and what you're serving up to your users at any given point. So, check it out at sentry.io forward slash syntax and give it a try today. All right, Svelte 5, Wes, to give you some background here, I have been cranking on a real-world app.
I've mentioned it a couple times on here. It says habit-tracking app. That part's not important. The important part is that I've been getting my hands really dirty with Svelte 5.
I've been using just about as many of the APIs as I can in a real-world context. I've been finding the pain points. I've been, you know, really enjoying the experience. And then just yesterday, I got to talk with the Svelte 5 team a little bit about Svelte 5 and, you know, where it's at and what's going to change.
So, I feel like I have some pretty good info here. Big picture here is that most of the APIs in Svelte 5 are finalized. Now, granted, there could be some new stuff specifically around animations, but for the most part, you can take a look at runes today in the previews or the docs and have a pretty good idea of what the end result will look like once this stuff is released. The big, in my mind, and this is not from the Svelte team, by the way.
A lot of this is my thoughts. My impression is that Svelte 5 is about three things. It's about speed, simplicity, and size, which tracks that it's S. Svelte team, if you want to use the fact that Svelte 5 is speed, we could come up with two more S's if you want, and then you could have five things.
No, a triangle. A triangle, speed, simplicity, and size. And you'll see this pop up in a lot of ways throughout the course of this. Speed, it's very fast, like very, very fast.
Size, bundles are very, very small. We will talk more about that. And simplicity in these APIs, what it's doing is it's essentially taking out a lot of the places in Svelte where it felt like there may have been one or more ways to do things and really nail it down to, like, here's the way in which you do things now, which is great in terms of simplicity. Yeah.
All right. Let's hear it. I want to know what all these features are because we've got the syntax site, and I'm sure I would love to implement some of our new features with these things. So it's released, right?
Are we able to update our site to Svelte 5? I know we updated it to Svelte Kit 2 just a couple days ago. This is not released. It's still in beta.
It may even be alpha. Allylator is in the next flag. It's in the next flag. Now, I suspect a release candidate is coming sometime in the next month and a half.
You know, I would imagine that you're going to get to a release candidate phase here shortly. So that's good news for anybody who's looking to adopt this stuff. That's it. I'm running an app in production with this stuff right now using the next version of it, and that's not a smart idea.
But if you're like me, sometimes you forego smart ideas to do fun of this. Yeah. All right. So what are runes?
Tell me. I'm dying to know here. Yeah. Okay.
Well, the rune kind of refers to the idea that in Svelte, you know how we occasionally have, like, some weird magic symbols in Svelte. You have the dollar sign to indicate reactivity, right? Yeah. And sometimes you have double dollar signs to get rest props.
Well, runes kind of, like, takes that idea and defines, like, all right, we have the dollar sign, and that's going to be considered, like, the magic symbol. It's the rune, right? It's the symbol that indicates, hey, there's something interesting going on here. And it really tackles a couple of big areas.
One, state. In Svelte before, you could do state by just having a variable, or you had a writable or a readable. You had lots of ways of doing state. In Svelte, five, state is being done through the dollar sign state rune.
You create a state, and then you can update it reactively within a component. You can create bigger, better global stores outside of components and have them use the exact same APIs, which was one of the problems before with Svelte, was that if you're pulling state outside of your components, now you're using different APIs than if you're working with state locally. Yeah, that was always a bit funky. A bit funky.
And another thing is that, like, big custom stores become way easier to reason about and work in. So, like, you'll know that we have a big old custom store for our audio player, which many of you have noticed occasionally causes annoying bugs here and there. And many of that stuff is, like, when I'm working in Svelte 5, I'm thinking, man, that player code's going to be great to refactor. It's going to feel awesome to use using this new state group.
They're based on signals, which is something that you don't have to worry about. They're under the hood. Oh, that's actually kind of nice. You don't have to really know what a signal is.
You still have to know what a variable is, right? Like, we're not moving to set state, right? We're still using mutable variables. So if I make a state and it's an array, I can still use push and slice and all my mutating values just fine.
And it's reactive variables? Correct, yes. And that's really the benefit of this stuff is when people ask me very frequently, hey, it looks kind of like React. And I think it does not feel like React because, one, you still get that variable mutating reactivity.
You get, like, fine-grained reactivity. And, like, let's say you have an object full of a bunch of props. You can go in and reactively update just, like, one of those values, right? And because it is signals-based, you end up getting a lot of benefits overall in terms of this fine-grained reactivity.
But in reality, again, it just functions one way. And once you get used to it, it's very, very nice in many ways. You also have this derived rune where you can essentially track a rune to have a derived value. Let's say you have a state value that's two.
You have a derived value that's your state times two. That derive will always be in sync with the state value. If you update that state value, derive will update as well. That's a really nice way of doing things, I think.
We have that in a couple spots on the syntax website where we take our state, and then I need to, like, derive some values, right? Like, I think in some spots, I think we filter an array depending on the values. And it was always a little bit funky where you have to, like, sometimes wrap, like, do the dollar sign colon and then wrap a whole block inside of that and then reach outside and update another state variable. This derived is really nice because you can say, like, okay, like, it's not a new piece of state, but you should be watching internally what your pieces of state are doing.
And I actually went through not these felt state signals, but I went through the preact signals. So if you ever want to read a fantastic, I don't know, it's probably 800 lines of code or 500 lines of code, go look at the preact signals. It's not our only React thing. It can be used with vanilla JavaScript.
And it's a single file for the entire library. And how they detect whether variables inside of a derived function are changed is really interesting. It's essentially just watching for variables that change. And it says, oh, something inside of me changed.
I must then update my derived value. Yeah. Yeah. And, like, Vue, they're called, like, computed variables.
It's something that I think works really well. I've been using it quite a bit. You know, a lot of the runes kind of videos that people have been showing about describing them show, like, situations where, you know, when you console log something, your state can kind of get out of sync because of perhaps, like, it's an enclosure or you're doing some, you know, you're just trying to understand what this variable is at any given time. And I personally don't always hit those.
But when I do hit those issues, they are kind of confusing. Like, why is this value not what I'm expecting it to be? And I think a lot of what this state variable or state rune does, besides just giving you one way to do state, is it makes working with state more reliable and generally more flexible. There are some things where you have to do gitters inside of, like, big old custom stores.
That will be a learning experience for some folks. You cannot export a primitive state. So if you do export const variable that is a state and that state value is just a string, that will not be reactive. So you have to throw that in an object or a custom store.
That's something you can do with writables that you can't do anymore. But, again, these are going to be small learning experiences that people are going to get past. And there's most likely going to be errors in your VS code that says, hey, don't do that. Do this instead.
Next is dollar sign props. And this is a new way of doing props. Sorry, I just looked at the example before you even explained it. And I was like, this is, I could, if you go back to the first episode on Svelte, I could not understand the export thing of the Svelte component.
So, sorry, go ahead. Yeah, and you're right. And not only can, were you, like, the type of person who'd be like, I don't get this export const props, which is how you did props before. And you have to do each prop individually.
This dollar sign prop solves so many issues around props being weird in Svelte. Basically, you say let, and then you destructure your values out of an object equals props. The reason why this rules is that, one, you can do all of the types for all of your props at once. You don't have to type each prop individually.
So you can pass types in. That solves a lot of issues. Two, rest props in Svelte were weird before. If you wanted to get the rest of the props that maybe weren't exported, you did this dollar sign, dollar sign props.
Now you just use the spread operator like you would in normal JavaScript. That greatly simplifies it. That's going to be really handy for, like, if you have, like, a presentational component, and then you have, like, the actual, like, component that does your functionality. Often, you find yourself passing, hot potatoing it just from the presentational component down to the functional component, and you're rewriting it many times.
I found that really frustrating to do, and this will allow you just to spread them all down. That's something we haven't been able to do in React for a long time. Will, I have a question. You might not know the answer to this.
Is that, is class going to be involved in those props? That's one thing that always drove me crazy is you can't pass a class from a custom component down to the div unless you name it something like class with a Z. Oh, man. That is not something I know, but I can actually test really, really quickly here.
I'll explain why I want this. So often, I'll build a custom component in Svelte, and I want to slap a class on it because I want to style it in a certain way. And you're kind of crossing the, like, style boundary there. Where you specify the class, that's sort of done, like, maybe that's done in your page layout, and your page styles will be applied there.
And then you go inside of your component, and any styles that you write inside of that component will then be applied. And I guess Svelte doesn't know that you use a specific class and it's being passed in. But I do find that really frustrating because I often just want to, oh, I'm using this component, but it's, like, a different version of it. And you find yourself just, like, re-implementing the whole class structure.
Like, you make a prop called isbig or card layout or something like that, and it's just like, classes do this already. Yeah, so in the preview, I am getting unexpected keyword class when I try to do that. That doesn't mean necessarily that that's the way it will be. That's a great thing that I think we should ping the Svelte team about.
Because when I was talking to them yesterday, they wanted to know about all these little weird things that you could think of. Yeah. And that's a good one. I don't think you actually are able to destructure the word class because class is a reserved word.
And that's why React has class name, unfortunately. Yeah, yeah, okay. But if you destructure it with a REST, like, you collect them all with dot, dot, dot, it's probably not in there, hey? Let me actually try that.
Because it's not a prop. It's an HTML attribute. I don't know how they would be able to do, like, the tree shake your CSS. So in Svelte, if you have a class that is not used in a component and has a bunch of CSS associated with it, Svelte doesn't, it just throws that CSS out, right?
It's unused. And it has to be statically analyzed. So if the class is written in a different file, I don't know how they would figure that out. And maybe I'm just, like, not doing it right, but I always found that to be a bit of a pain.
So I'm able to pass class as a prop with REST, and that seems to work if you use the REST, but you cannot destructure class. Oh, but it is collected in the REST? It is collected in the REST. And I was able to even output it into a template.
I can make this available to anybody who wants, so I'm just working in the Svelte rebel here. So interesting enough. Next one is going to be the effect, which I think this is the one, the rune effect that people look at this and they say, it kind of feels like React, doesn't it? And I'm here to say it does not feel like React, because I think the things that feel yucky about the React are the dependency array, and maybe not necessarily knowing what's going to set it off.
With Svelte, effect essentially just replaces the dollar sign colon block syntax, and that is a good thing in my mind, because it's way more predictable. Another cool thing about the effect is that it's removed entirely from server-side rendered code, so your server-side bundle is smaller, which is great. Svelte can be smart enough to say, hey, we know this is only going to run on a side effect. When something else happens, you can run.
So what that means, Wes, is since it's removed from your server-side code, you could throw, like, a document dot whatever inside of there. Oh, or an entire client-side library. Or an entire client-side library. In their demo, they were doing, like, a Canvas-style thing, and the reason why that rules is because if you've ever worked in React in a server-side rendered context, you'll know that you can't use effect.
You have to use isomorphic effect for server-side content, or, you know, if you try to throw a document anywhere in a React component like that, it's going to complain, unless, of course, you're doing these new client-side components. Yeah. Someone might be asking, like, who cares about how big your server-side functions are, your bundles are on the server-side, right? Like, it doesn't really matter, does it?
No. And the answer is, it actually does matter. Now that we're going a lot more to, like, serverless and edge functions, the smaller they are, the faster they will be parsed and sort of boot up. And also, there's a hard limit to how much code you can put in a serverless function, edge function, and you do end up butting up against them.
Especially sometimes you have these little libraries where you don't expect them to be huge. And in the next potluck, we have a question exactly on that, is the things that accidentally don't get tree-shook in can actually really bloat your end bundle. Yeah. So the cool thing about effect here is, again, it functions kind of like the React use effect in which it runs when something has changed.
Now, when does it run? It's not about component re-renders itself. We're not thinking about a function recalling itself like you do in React. You're thinking more or less, is the stuff that's used inside of here need to be updated?
Or, you know, when something happens, when something changes that's referenced inside of that effect, that effect will need to rerun. And so that's it. You don't have to worry about infinite loops. You don't have to worry about dependency arrays.
Another really neat room here is the inspect room. And actually, I'm sorry, before we get off effect, you can actually do nest effects, too, which is kind of blowing my mind right now. Okay. And I have it.
Yeah. So in Rich's example, he showed, like, both the initialization script as well as, like, the listening script for a canvas drawing app. So an effect would probably be handy if you were watching... like let's say you have a name variable and somebody types into a text box and changes their name, you might want to write an effect that then updates that value in the database whenever they type on it.
Is that maybe an example of when you use an effect? Maybe. Yeah, I'm going to tell you what. Effect pretty much replaces any time you would think about doing dollar sign colon a block.
Okay, just when this code variables change. So it's not derived. You're not figuring out new state. Correct.
In fact, that's a thing they want you to know is that if you're thinking about changing state when some state changes, doing something when some state changes, you probably want to use derive. Kind of like an ad event listener for a piece of state when you want to have a side effect. You want to send some data elsewhere. You want to log something or maybe not even log.
We'll talk about the next one. Yeah, and one way that sounds different from React is that you're more frequently working with the DOM itself. And so I think use effect is going to be particularly useful when working with the DOM itself. Next is inspect, which is kind of like console log, but you'll know that because unlike React, it's spelled isn't just a function that runs.
Console log would only run once unless you did the dollar sign colon console log, which was obnoxious, but it made sense. Now we have this inspector which is actually way better than a console log because it gives you context. It says, oh, this was an updated event. So in your console, say a component or variable updated or I'll just say updated or init based on what the event was that caused this thing to change.
So it is essentially a reactive console log, but it gives you a lot of context and there's like more freedom in here where there's even a callback. You can throw in a debugger statement in there. If you're the type of person who loves to use the debugger, it works really, really well in that context as well. Oh, I like that as well.
That's again, that's something I use quite a bit is you throw a console log in like right before you render and if you want it to rerun when the values change because you want to see what the actual updated values look like, it seems like, usually I would think like, you could say, oh, maybe this feels like you're adding more complexity. But in the end, I think every single thing here adds to the simplicity of Svelte because there now becomes one way of doing things and that way is both good, very good, easy, and very, very fast. So I love all of that. Next up is snippets.
That can actually be the fourth S in the five S's that we were talking about. Speed, simplicity, size, snippets, and Scott, there we go. Pentagram with Scott on the top. Yes, I love that.
I love that for me to be included in the Svelte I release. Snippets are basically inline components. This is something that I know Wes has been asking for for a long time. People in React land love to have multiple components per file.
Maybe you're just breaking out a singular section of a component that gets looped around. You don't want to create a whole new file, a whole new component just to do that, the whole rigmarole of exporting and passing props. Now you have snippets, which are essentially you're defining a section of code that can be reused as a snippet and then you call it like a function using the at render keyword. You do at render the function and you pass in your props.
Small caveats here, you can only pass in one argument to this, which is fine because if you need more arguments passed in, you just pass them in as an object. So not really anything crazy or different there. I know. It's getting there, but like, okay, so now I'm building components with multiple props but then if I want multiple in a file, then I got to like, I got to move it from multiple props to this like weird object.
It's not weird objects, it's just an object, but all right, I'll take it because I certainly hated having to put things in a separate file when it's, especially with an if else, like you have the same component and you want to render, you want to render it this way if this is the case and this way if it's the case and oh, I need to render this in two spots. Now I have to put this whole thing in a separate file. So I'll take it. I think in practice you'll like it.
I've been using it pretty gratuitously throughout my app and in fact at one point I think I had like four snippets in one file and it was really easy to reason about in that regard. I have since chilled out a little bit on the snippets and moved things into actual components as the application has grown but I think that's a good indication of how you'll probably end up using this stuff, right? Because oftentimes when you are prototyping you're just trying to throw something down, right? You're trying to throw it down, get it working and then maybe as the application grows and you see, oh wait, I actually need to use this component elsewhere, perhaps I will turn it into an actual component.
And I bet, I don't know if this is the case, I don't see anything but I bet you can infer the types from the props object. So you could just say like, you could use typescripts partial type of props, I bet, I bet that would work so you're not like doing a whole bunch of typing. You could say like, all right, well this function is taking a partial or pick, you're picking these two props out of all the props that were passed in. So I don't think it would be as bad as I'm thinking.
You're not going to have to individually type those props as far as I know. Oh, really? Yeah, and let me even double check that with my code base right now. Right now it's not possible to add types to snippets and the parameters is something we hope to address before we ship Svelte 5.
Okay. Because you're essentially just making a function, right? It is a function. You would have to type the function itself, right?
Otherwise you don't know what to pass it or what the type of the data is coming in. Yeah, that tracks. Okay, cool. Another cool thing about snippets is they can be passed as props.
So you could have like a wrapper component and you could throw a snippet as a prop and then access that inside of the component itself. And the neat thing about this is it kind of replaces the need for slots because passed snippets are way more powerful than slots where I think we still need to see some code examples about what that looks like considering slots are used throughout SvelteKit but if you're doing that you probably should just make a component, right? Yes, probably. I know there becomes a whole thing there, right?
Where at what point does it become a component? And if you look at my code base over time you can see that most of my snippets did become components once I needed more out of them. Next up is events and this could be the last well maybe not the last thing here we can move it along though. Events is on colon click was kind of a fancy Svelte syntax and now just becomes the straight up on click.
And that's the same with all events for Svelte components. They all just become the on whatever attribute that exists within the browser, right? So you're now getting to again align yourself with the browser no more fancy naming special situations there. I kind of like that though.
Yeah, but if it stood out or what? Yeah, I just kind of like the syntax of it. I never liked the fact that on click was not camel cased and it's just like on click, right? Especially if you have custom events.
And I just asked them about this, yeah. This custom events. I'm also seeing here the pipe to prevent default is gone forever. I love that.
Let me tell you in my conversation with the Svelte team that was like one of the things because they mentioned very clearly in the docs that the prevent default is gone and I had to ask just because I wanted to truly make sure that it was gone. The way they see it is that you can just do a wrapper function around it and they might even export those from Svelte, you know. It seems like it's not the same, but yeah. All of these new features that they've been rolling out are just JavaScript, right?
Yeah, yeah, yeah. They're all JavaScript and now they're getting rid of the custom syntax and they're getting rid of some of the magic. What's the Svelte 6 endgame here, you know? The Svelte 6 endgame, I think, is more of a focus on the simplicity and it does feel like you're aligning with the way they're describing it is I think it's like magic, not magical or something.
I believe that was the same. Yeah, we're like they want it to feel like magic but they don't want it to feel unpredictable and so a lot of this is like aligning with browser APIs and you saw that with Svelte a little bit, right? Their usage of progressively enhancing forms. You're aligning with real HTML APIs, you're just enhancing them further.
Last little bit here are two new built-in functions. There's a few built-in functions to Svelte, like tick is one that we've used before to, you know, essentially get the next tick in Svelte. It can be useful in context in which you just want to wait a frame, you know? Yeah, like you want to put something at the end of the event loop.
So I have a package that is incredibly popular called wait. That's essentially a promise that resolves after over many seconds you pass it in and I use it all time for just wait zero and Svelte says, hey, you don't need that. Svelte has it built in. Yeah, and it's great.
One of my favorite APIs I use it all the time when I need it but now there's two new ones called untrack and unstate. Unstate just removes reactivity from a state variable something that if you wanted to like really dive into maybe some perf there you have something that you don't need to update you can unstate it and untrack I think is actually kind of interesting. You use it in an effect but it removes something from being treated as a dependency because remember in Svelte you don't have to have the dependency array but let's say your effect is running too often because something is updating inside of your if you want to remove something you use the unattrack function and it's kind of like a reverse dependency array but only if you want it. Let me think about how that might work.
So you have an effect that is rerunning every single time the name changes and we also need another variable inside of that effect but that variable updates too often, right? So you say, okay, you still pass the data in but don't rerun me when that variable changes. Only rerun me when the rest of the tract values are. They're done.
That's nice. I can see that. Oh, I have a good example. Don't rerun every single time someone moves the mouse, you know?
So pass it in but don't rerun. Yeah, those are nice little performance enhancing ones and there's several things I didn't mention like state.frozen or effect.pre effect.active effect.root There are nuanced topics here that you're not going to need to get into in 99% cases because let me tell you I built a whole app with user accounts and databases and I haven't used these once so for the most part these are things that only advanced users are going to want to dive into and not stuff you're going to need to think about too much. So let's talk about the last benefits of this before I give my final thoughts. Smaller output.
Here's a post from Reddit. I migrated 147 components and my output is 55% smaller. So that seems like a pretty huge win. I think they just removed a lot of the stuff from Svelte.
Just got rid of it. Just got rid of it, yeah. So that's one of the big things they wanted to emphasize is that your code probably will be well not probably it will be smaller if you use these new APIs. And in the eventual situation like who knows if this happens or not but in the eventual situation where signals get added to the browser you would then lose even that much more code from your end bundle.
So that's something to think about. Speed. It's very, very fast. I've included the benchmarks here.
The Svelte team did want me to let you know that like these benchmarks are you know some people optimize their demos for these benchmarks and therefore you should take all of these benchmarks with a grain of salt but even taking them with a grain of salt Svelte 5 version Next35 is approaching native vanilla JS speeds all around and compared to React or any of these other frameworks it blows them out of the water. So it's shockingly fast. Yeah I'm looking what is faster on this benchmark than Svelte 5? So solid is just beside it above it.
Vanilla JS Million JS is really the only one that I've heard of on this list. Right. It's impressive. It's super duper fast and they wanted me to let you know that it's faster even than this kind of leads you on because it's going to be faster in normal use cases that are not like benchmark specific use cases right like in real world use cases you're going to notice a speed but they also said the framework shouldn't be the bottleneck ever that's not going to be your bottleneck it's going to be other things so we're approaching a situation here with many frameworks where the framework is not the bottleneck it's that fast.
Suspected release like I said hopefully we're going to see an RC sometime before March could be around March who knows nothing official there there will be a code mod of some kind as well to help you update who knows what that looks like but it could probably be taking care of a lot of the easy stuff for you like changing props to be the props room who knows my thoughts overall this stuff kicks ass I do like it a lot in usage I think you know there is maybe a little bit of a learning curve but I found myself wishing that I was working in these spell APIs when I was working on some of the writable bugs that I was having I feel like the state's way more predictable easier to reason about it does not feel like React if that's your concern the word effect does not make it react there's a lot of really spellty things about this overall you can also try today the preview app I'll have a link to that in the show notes if you want to just get your hands dirty with some of this yourself what about backwards compat with the older APIs is that stuff going to stick around or is it going to be a big like no you got to move all your stuff over in one good almost nothing is like removed from spell 5 so there are situations where you become in runes mode where things don't work anymore so it will allow you to migrate one component at a time and again hopefully with that code mod eases some of the pain if you have a lot of components that you're working with but yeah you can do incremental adoption you can say oh all my new components are going to use this stuff or whatever or you can do it all in one fell swoop I have found again most of the time I'm removing code my code feels easier to write and there's less foot guns I think there's less like weird special circumstances sweet I think this looks very very simple like it's I feel like I understand it you know not I built a couple things in Svelte obviously built a syntax website in Svelte and I feel like I know it pretty well but this stuff seems very very simple very approachable so I'm pretty stoked about it yeah I think when I first saw it I was concerned and then just like most things with the Svelte team after spending some time with it I really truly see their vision and it all feels more simplistic in the end I do have my code base I'm working on too if you want to see how I'm using this don't judge the code a lot this is scratchy stuff but there's some like real world examples like in mine I have like a global state store of dates and derived dates and getters and setters and more complex stuff and so check it out beautiful all right thanks everyone we'll catch you later peace peace