850: Manage State in JavaScript Like a Pro!

Scott and Wes serve up state management in JavaScript, breaking down key concepts like reactive state, state updaters, and global vs local state. They also explore various approaches and libraries, mutation-based state, and tools like Zustand and xState, to help you manage state like a pro. Show Notes 00:00 Welcome to Syntax! 01:22 Brought to you by Sentry.io. 03:10 What is state? 03:29 Common state jargon. 03:48 Reactive State. 04:14 Store. 04:46 Immutable vs Mutable State. 05:53 State updaters. 06:15 Signals. Solid.js Signal Docs. 06:49 Observables. 07:07 UI is a function of state. 08:39 State Machine. 10:58 Binding state. 11:36 Global vs local. 11:49 Computed State, derived state, selector state. 12:41 Approaches to state management. 12:52 Reducer based. 16:39 Mutation based state. 21:17 Atom based state. 25:15 Ways to hold state. 25:17 Holding state in an object. 27:38 Holding state in the URL. Syntax Shows. 29:34 Holding state in IndexedDB, local storage, and cookies. 32:16 Holding state with FormData. 33:56 Holding state with Signals. Signals Proposal. 37:27 Holding state with the server database. 38:55 Global State vs Component State. Habit Path. 40:39 Sharing state. 42:58 State libraries. 45:26 Zustand. 50:24 Jotai. 51:50 xState. 54:56 Easy Peasy. 55:24 Pinia. 56:01 TanStack Query. 57:02 Sick Picks + Shameless Plugs. Sick Picks Scott: Cremo Mens Body Wash, Bentgo Adult. Wes: Adult Bento Box. Shameless Plugs Wes: Syntax on YouTube. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Syntax Today. We got a show for you on state management in JavaScript. This is kind of an interesting one because we all have to manage state in our application. And there are many different libraries out there. There's many different approaches. You're hearing all these words like signals, reducers, actions, immutable, reactivity, state machine, global, local. If you're using React, you're using a different framework. You're using vanilla JavaScript. There's all kinds of things to sort of consider. So we're going to do a show today that will sort of break down the different state management approaches, different ways to hold state, things that you should consider, as well as go through some of the more popular options in the state management world right now.

• 0:43Wes Bos?

  My name is Wes Boss. I am a developer from Canada. With me as always, Scott. How are you doing, Scott?

• 0:50Scott Tolinski?

  I'm doing good, man. Just chilling. Actually, literally chilling. It's cold here in Colorado. So, yeah.

• 0:56Wes Bos?

  Oh, man. We have, oh yeah, we had to open the windows last night. It's like, like summer weather still here, which is wild.

• 1:03Scott Tolinski?

  Oh, yeah.

• 1:04Wes Bos?

  Considering it was snowing this time last year.

• 1:07Scott Tolinski?

  We have the classic, uh, super cold at night, super hot during the day flow going on right now.

• 1:14Wes Bos?

  Oh, I'm into that. Yeah. Open the windows. Let me freeze.

• 1:17Scott Tolinski?

  Yep. And then open the windows. Let me cook during the day. That's right.

• 1:22Wes Bos?

  Real quick, let's talk about something that Sentry is behind. It's the open source pledge.com. So they just rolled this out. Basically, having, encouraging other companies to pledge part of their profits, part of their revenue to open source. So the open source pledge.com is a really cool initiative. You can go to it and see there are tons of companies on here that are paying actual maintainers. So you could take a look at the list. Sentry, 135 devs. They are contributing $3,704 per developer back towards open source. And there's a huge list of companies that have sort of taken the pledge. I mean, like, you know what? We use open source to run our business. It's probably time that we give

• 2:07Wes Bos?

  some of that money back to open source. Make sure that we have a healthy community. So check it out. And if you have a boss or you are a boss, I encourage you to sign up for it as well. Open source pledge.com.

• 2:18Scott Tolinski?

  Yeah. Hey, let's actually even shout out, maybe we should shout out some of these companies that are taking this pledge, one of which that I've been following for a little while is Emerge Tools. Do you follow Emerge Tools on Twitter?

• 2:29Wes Bos?

  No.

• 2:30Scott Tolinski?

  They're a good follow. They break down apps.

• 2:34Wes Bos?

  Oh, yes.

• 2:35Scott Tolinski?

  And they show, you know, what libraries apps are using. And these are all like iOS apps and production apps. And so they'll just open up the FedEx app and talk about like, what percentage of the app is localization and fonts and whatever. And it's always fascinating whenever one of these comes up. It's like, they have like, kind of like a Daisy Disk graph for dependencies for apps.

• 2:56Wes Bos?

  Yeah, I love that.

• 2:57Scott Tolinski?

  And kind of talk about where the size is going. So a shout out to Emerge Tools on Twitter specifically, I think is where I follow them or get the most information from them. But cool to see them on the open source pledge.

• 3:10Wes Bos?

  All right, let's talk about state. So what is state? State is a representation. It's data that represents the current condition of your application, right? The current state of your application. And it determines things like the behavior, how your application acts, as well as the appearance. What does it actually look like? So I thought, we're first going to start off with some common words that you're going to hear us talk about. So just go through some of the buzzwords. Then we'll talk about the sort of the three big approaches to state management. Waste the whole state, global versus component state. And then we'll go into state libraries that you could possibly be using. So first one we have here is reactive state. This is a word that you're going to hear quite a bit. And what that essentially

• 3:53Wes Bos?

  means is that when you're building an application, you take your state, your data, and you put it into your templates. A reactive state will update those templates when that state updates, right? A very simple example, you have a counter, you increment that value by one. Wherever that variable is that used in your templates will update itself.

• 4:14Scott Tolinski?

  Yes. Next one is store. And a store is just a word that people often use for a place where you put your state. I mean, people sometimes just call it a state. Sometimes people call it a store, a data store. Basically, a store is someplace that your data lives.

• 4:29Wes Bos?

  Yes. And a store often, we're going to talk about the different types of it, but a store will also often include the logic as to how that store can be interacted with, right? So it'll include a set of functions for updating, deleting, modifying the data in the store.

• 4:45Scott Tolinski?

  Words.

• 4:46Wes Bos?

  We also have immutable versus mutable. What this means is that can you directly reach into your state and update it directly? Or does it, is it updated via a set of updater functions? So immutability is the idea that you should not just simply, like, let's say you have a object called Wes and it has an age of, I forget how old I am, 37, 36, something like that.

• 5:16Wes Bos?

  And you want to increase the age, you don't, for, for in a mutable state, you would simply just say Wes that age plus plus, or Wes that age equals 100. A mutable state would have a function that takes in Wes and returns a new instance of Wes so that you're not actually going into the, the value and updating it.

• 5:39Scott Tolinski?

  Yeah. It'd be like if we were cloning Wes, like if we put Wes into a cloner and transported him somewhere else. Disassemble all of his atoms and create a new version of him with changes. Next one is state updaters. These are functions that update state. Now, this can be done very simply with just a, a simple like dot set state or a set state. And this can be done with a dot set, but this can also be done in a much more complex way of something like reducers, where you're taking in the old values or taking in the new values and you're manually merging them yourself.

• 6:15Wes Bos?

  A signal is, we're not going to go too deep into signals on this because we can do a whole show on it. We have, and we probably should do another one, but a signal is a way to manage state that has both a getter, which is how you consume the state, and a setter that you use to update it. And then there's this idea that if you want to listen for when that state has changed, that's called an effect. So that's another thing you're going to hear is basically just like watching for changes on that state is often called an effect.

• 6:48Scott Tolinski?

  Yes. Next one is observables, which with observables, you know, and the observer pattern in general is just you can think of you're observing something, you're, you're listening for something, you're waiting for something to change. So with observables, you're being able to listen for changes on them and respond accordingly.

• 7:07Wes Bos?

  Another kind of saying that you're going to hear is UI is a function of state. And what that means is that in order to get the UI for your application, it has to take in the data, meaning that you can derive any UI of your application based on its actual state. And as you get into more and more complex applications, for example, TL Draw is, is one of my favorite applications. This is like a little, a, not a little, it's a, it's a drawing application, like a whiteboard, right? And there's real time in there and you can like, you can select on something you've, you've drawn and you can right click. And the thing that always gets me is that when you, when you right click on one of the

• 7:52Wes Bos?

  pieces in the application, there's a whole context menu and the parts of that context menu depend on what you have selected, what maybe what color it is, if you've selected multiple things. And I often think about how complex that simple right click is on, on TL Draw because There are so many decisions that need to happen before they can simply display the the actual options that are there. And I always think about that as being a very good example of the UI of the right click takes in the entire world of what you've you've clicked and maybe even stuff behind it and it gives you a set of options to arrange them and copy paste them, move

• 8:36Wes Bos?

  them around, select them, delete them, etc.

• 8:39Scott Tolinski?

  Word. All right, next one is a state machine. And now a state machine is an interesting way of working with state where any individual state has basically several options that it can do, but only do from that state. So if you think about like, you have a piece of state, perhaps that state is a string. A lot of times when we're working state with state, we'll just call a set state and update that string to anything. But when you're working in a state machine, it doesn't quite work like that. We have a state machine, you have a piece of state, there's only a defined path of places it can go from that. So basically, you have your state and then you tell it which path to go next. And then now it's in that state and it can only then go from other places of state.

• 9:22Scott Tolinski?

  This kind of is at odds with when people use things like Boolean variables for things like is open or something like that. You're more or less like, all right, the status of this thing is now it is open and therefore that brings along a lot of other properties. And from open, where can this go? Well, it can only go to closed from open, you know, from open to closed. And then from there, you can build off this whole tree of a state machine.

• 9:46Wes Bos?

  Yes, it's a lot more complex. However, if you've ever been in an application where you think, hmm, I shouldn't be able to do that when this thing happens.

• 9:56Scott Tolinski?

  Totally.

• 9:56Wes Bos?

  Or like, if you have like a thousand Booleans or like, all right, I'm going to display the right click. And then you have a thousand if statements. So well, if if there's this is set, but they also have selected this. Or if you are currently in this mode, but you're allowed to do this. Holy hell, that can get very, very complicated very quickly. So I've not had to use a state machine in applications that I have built, but I have talked to lots of people that build much more complex applications, lots of desktop software. We had Andrew on who works at Descript and he says that is very complex to happen. That's a massive state machine.

• 10:34Scott Tolinski?

  Yeah, I tend to work with all of my state that is complex as even most of my state. I'm going to say in general as a state machine light where

• 10:43Wes Bos?

  Yes.

• 10:43Scott Tolinski?

  I'm not, I'm like refusing to use Boolean values for state in that sort of way. And I am more or less not, not adhering to something as strict as some of these libraries like X state, but still utilizing some of the, the principles.

• 10:57Wes Bos?

  The ideas behind it. Binding state, this is an idea of being able to update state when you are changing it. So like, for example, if you have a piece of state, which is like, uh, what's your name? Right. And then, then you also have that state in an input. If you change that input, then that state is often, um, needs to be bound to back to the state. So that when you change the input, the, that state is also updated. I feel like I'm saying state a lot.

• 11:27Scott Tolinski?

  Yeah, I feel like that's an unfortunate thing that's going to happen in this. It's really hard to, to even like discuss state without saying the word state. Another one is, is global versus local state. You could think of this as global is state that your entire application needs to access. Where local is state that only one specific, even like chunk or component needs to access.

• 11:49Wes Bos?

  Computed derived or selector state. This is the idea that your state is actual data. However, if you want to display that data in a, a different way, or if you want to generate state based off of that. For example, if you have a price for an item in your state, right? Or your cart might be 5,001. But when you actually want to display that value, you might use a derived state, which will then go ahead and, and format it. So it also could be state that needs to be like multiplied by two. And then you need to listen for when that state is higher than a certain value. So it's not simply just how to format it, but it could be a piece of state

• 12:34Wes Bos?

  that depends on some other state and needs to be recalculated every single time that it is updated.

• 12:41Scott Tolinski?

  Word.

• 12:41Wes Bos?

  All right. So let's talk about the kind of three ways to, to attack state. You have reducer based state, you have mutation based state, and you have atom based state. So reducer based state, and these are all.

• 12:56Wes Bos?

  Handy in different aspects of your application and sort of how you like to approach it. So a reducer based state is, is like Redux. Redux is probably the most popular reducer based state. However, there is, is several of them out there. And then the way that a reducer based state works is that you, you have a store, which is, it has your data inside of it. And then you have something that are called actions and actions are ways that you can update your state. They describe what will happen along with any arguments. So for example, you might want to increment a number by one. You might want to, you might have an array of comments and you want to add additional comment to that. You might want to delete an item from a list of posts.

• 13:41Wes Bos?

  So an action would be something like increment, add comment or remove thing. Whereas you have a reducer, the reducer is the actual function. That's the actual business logic as to how do I increment it? How do I add a comment? How do I remove an item from that array? The reducer takes in your current state, does the work and then out the other end returns you back the, the modified or updated state. So that's the, the whole idea there is that your state is immutable, meaning that you, you take your old state and then you return a new state from that. And the benefit to that immutability is you can have some really cool dev tools where you can sort of scrub back and say, oh, what happens if I don't do this specific action?

• 14:25Wes Bos?

  You can see what actions have been taken and you can sort of time step through that, which, which can be really handy in complex applications.

• 14:33Scott Tolinski?

  Yeah, totally. There's also the word dispatch where with a dispatch, it's basically how you trigger or fire that action. So we mentioned that the actions are the thing that you're doing. The reducer is the work itself and dispatching is the firing of that action. There's also subscribe where you're listening for the changes and you can use it to update the UI. I found this flow, when I did not understand or use Redux, I found this flow to be daunting from a viewpoint. Like looking at it, you'd say, yeah, man, that's a whole lot to update a variable. And I feel like a lot of people felt that way too. However, once I actually used Redux, I kind of gained a little bit of a fondness for it, which maybe, you know, it's like Stockholm syndrome with like.

• 15:18Scott Tolinski?

  React in general, where like at first you're like, ah, this is all too complex. And then later you're like, well, it's kind of nice.

• 15:25Wes Bos?

  I can kind of see.

• 15:26Scott Tolinski?

  Yeah. And eventually I kind of have taken a step back into the more simplistic view of things. But I still do understand the value of a flow like this for keeping things organized. I think the most important thing with something like this is that it is a highly organized system. And I think that can help a lot of developers maintain their applications.

• 15:46Wes Bos?

  Yeah, it's, there's a lot of boilerplate. Like if you simply want to have a variable of is cart open?

• 15:56Scott Tolinski?

  Yeah.

• 15:57Wes Bos?

  You're, you're, what you're doing is you're creating a store that has an action of open cart, close cart, toggle cart. You'll have a reducer that that will update that variable. Then you'll have a dispatcher which fires off the open cart action. And then you could also subscribe to it at a different part of your application. Because if the cart is open, then maybe you want to do something else in your navigation where the navigation is a bit smaller. It's, it's not for simple stuff like that. It's for when your application is extremely complex. And having a very rigid system in place allows for those things not to sort of get out of hand.

• 16:38Wes Bos?

  Because otherwise, if it's super simple, which is our next one, which is mutation based state, which is probably the simplest option out there, which is you simply create some sort of store. And like Svelte has a really good implementation of this. There's, there's kind of lots of them out there. You could, at the very simplest, you could just make a variable that has a number in it, or you could have an object with a couple of properties on it. And when you want to update that state, you simply do it like it was JavaScript. You say west.h equals 57, or you can delete a property or push an item into an array, right? Or, or filter that array and then overwrite the thing. That's mutation based.

• 17:21Wes Bos?

  And the way that that works is generally it either uses a getter, getters and setters on an object. Or on a class that you can use them on both. So in JavaScript, when you set a property and when you like you could say west age equals 50, or when you get a property, which is console.log west age, those are getters and setters. And by default, they're the same thing. But you can overwrite the logic with your own functions as to how does that value actually? And usually what happens is the actual value itself is internal on that class. It's either a private value on a class, or it's like an underscore age value that lives inside of

• 18:05Wes Bos?

  an object. And then you also have proxies as well, which is a proxy is sort of a function that sits in front of accessing an object. And you can sort of intercept when somebody runs a getter or a setter on that object, and you can determine what actually happens.

• 18:22Scott Tolinski?

  Yeah, you could think of a proxy as kind of like a stand in for the actual object, but it's been modified to have extra functionality added on to it. So it's like, kind of, like you said, it's intercepting, it has potentially additional functionality, and it represents the object itself. Proxies are kind of annoying when you have to work with them sometimes.

• 18:44Wes Bos?

  Oh, yeah.

• 18:44Scott Tolinski?

  For instance, the new state is all proxy based. And like, sometimes you want to spread out some state. And with dealing with the proxy, you actually have to take like a clone of that or a snapshot of it before you can actually access the real object behind the scenes.

• 18:59Wes Bos?

  Oh, yeah.

• 19:00Scott Tolinski?

  Yeah.

• 19:00Wes Bos?

  So I'm actually curious about this. You just upgraded the syntax website to Svelte 5.

• 19:05Scott Tolinski?

  Yes.

• 19:06Wes Bos?

  In Svelte 4, a lot of the state was just mutation based. I mean, you just create a variable, and you can put the variable somewhere, you can overwrite that variable with a new value, and it's all reactive, and it just works. So you don't, you don't have to know what a getter, a setter, or proxy is in most cases, because it simply just works. And then the Svelte compiler under the hood will take care of all that stuff. Is that still the case in Svelte 5?

• 19:31Scott Tolinski?

  In Svelte 5, you do have to understand a little bit more of the proxies, getters and setters. Because if you want to have like your own custom state function, right? Like a create state function that contains multiple state values and is like fine-grained reactivity. You need to use getters and setters if you're using a function for that or returning an object, right? But if you're using a class, you don't have to. So in Svelte 5, it doesn't feel as simple in that regard. But if you are just creating a basic state variable, that's an object or anything like that. You're just creating it as is, mutating it, whatever. So it's still mutation-based behind the scenes, or it's still mutation-based in general.

• 20:14Scott Tolinski?

  It isn't as simple as the writable, readable way they had it before. But I think it's better in a lot of ways. It's a little bit more explicit. There are times where it feels like I'm writing a lot more code. But I don't know if you ever got too much into like really custom stores in Svelte 4. We have one for the audio player on the syntax site. And that thing's a bit of a beast. And what I'm looking forward to most is converting that to a class and using that as some custom state as a class in Svelte 5. Which it's not, even though I did the migration, I didn't touch that code just yet. It's still the old way of doing it. But I think for big states, it feels a lot nicer.

• 20:58Wes Bos?

  Yeah, and that's actually a really good example of the difference between reducer-based state or like function-based state, you know, where you have an explicit function in order to interact with it versus atom-based state, which is our next one. So atom-based state is every, you can kind of think about it as if you've used use state in React. Kind of similar to that, whereas every piece of state is called an atom. And you break your state into many smaller pieces, right? So if you have a component that has a counter in it, an atom would be the actual counter.

• 21:38Wes Bos?

  And you can, in order to interact with that, you don't simply just update it directly, but you have a set of functions to update it or to access it. Whereas with use state in React, when you use it, the first item is the actual piece of state, and the second is the actual updater function. Atom-based state, probably the biggest ones out there are recoil and JOTI. Is that how you say it?

• 22:04Scott Tolinski?

  Yeah, JOTI is fine.

• 22:05Wes Bos?

  And the sort of difference between atom-based and reducer-based is that atom-based is more used for global state. If you want to have things that are sort of application-wide, and there's generally no way to define how it is updated. It simply is just your data and a function to update that state. Whereas with reducer-based state, you often want to define your data as well as a list of functions in how you can interact with it, right? So if you have a list of comments, you may only say, you may add a comment that has these values in it.

• 22:49Wes Bos?

  You may update a comment and you may remove a comment. Whereas with an atom-based state, you might just have an array of comments, and you can do whatever you want with that. There's no way for you to really define how that is. Of course, you can make a function separately, but that's not part of the state management. That's just part of your application.

• 23:09Scott Tolinski?

  Yeah. Cool.

• 23:10Wes Bos?

  Oh, sorry. One more thing is the benefit, I forgot to say, is that one of the big benefits of using this atom-based state has to do with some of the annoying parts around rendering in React, which is, I'll just read it straight from the JOTI website. They say, "Build state by combining atoms and renders are automatically optimized based on atom dependency. So this solves the extra re-render issue of React context, eliminates the need for memoization, and provides similar developer experience to signals while maintaining declarative programming models." So one of the annoying parts about React is that if you want to have some data available to you in a component,

• 23:52Wes Bos?

  If you pass the, if you have passed a fairly large state thing, especially if it's global state, if you pass that into a component because you need that piece, anytime any of that state is updated, the whole component re-renders. So the idea with Atom-based state is that you create these little pieces and you simply just pass in what you need, or you pull out what you need from the store itself, and then it will be smart enough to only re-render when that thing is needed. I always find that to be really annoying, because like Svelte does this, just figure out what I'm using and then don't re-render when I'm not using it. How about that? You know, and obviously, it's a lot more complex than that, but yeah.

• 24:36Scott Tolinski?

  I know. I know. I think that a lot of these state problems have come up from like ways to solve problems that were created by problems that were created by problems, you know, and it's like, next thing you know, you just have one thing to exist to solve a problem that something else created. And I don't know, I'm not smart enough to know if this felt way is scalable in the same way that the React way is. But one thing I really like about it is just, hey, you're not thinking about how many times is this thing rerunning or re-rendering. You're thinking about, is this value changed? Did this value change? If it changed, then update it. Otherwise, or update derived state, or anything like that. So to me, that makes more sense. But, you know, what do I know? Next one is ways to hold state. So you can hold state in all kinds of ways. We just

• 25:19Scott Tolinski?

  talked about it a little bit in the mutation base, where you can hold just state in a straight-up object. A lot of times, this could be like a function that creates an object too. You have a function, it creates an object, that object holds state. You can use getter and setter methods to set and get values from this. You can use functions or methods, sorry, you can use methods inside of there to perform actions and modify the state as well, instead of just getting it and setting it. And that's pretty common, right? Instead of always doing get and set, you would have a dot increment method that would take the state value and increment it inside of that object. Same thing with classes, right? With classes, you have these methods inside of classes. And again, they're modifying this internal state within classes.

• 26:02Scott Tolinski?

  It is funny how in JavaScript, we tend to use objects for things that most other languages would just go straight to classes for, just because classes are really newer and a syntactical sugar around objects anyways. But, you know, because of that, I kind of stayed away from classes for too long. And I, man, I tweeted out the other day, just how Svelte5 has been making me write a lot more classes lately. Not that it's making me, it's just the syntax ends up being a lot more concise without having to write getters and setters. And gosh, I kind of like writing classes. I don't know what's happened to me.

• 26:37Wes Bos?

  Yeah, I've always been a big fan of using classes for when everything needs to be self-contained. And almost always it's when I'm writing something in vanilla, where like, for example, you are, in a lot of my courses, we'll do something where like, we create a game, right? And that game will have internal state of what is the score, who are the players? And then we also have a whole bunch of methods to interact with that, right? You can increment the score, you can add players to it, you can pause the actual game. That's another one I do as well, which is a pausable set interval. You know, you want to be able to run a function every 500 seconds, but you want to be able to also pause it and stop after a certain amount of time.

• 27:22Wes Bos?

  That's if you want a little JavaScript exercise, that's a great one to do, is a pausable set interval that will stop itself after a certain amount of time. And then you can expose all of the ways to interact with that via the class methods. You know what the best state management library out there is?

• 27:41Scott Tolinski?

  I do, and I agree with this one, so you can go ahead and say it.

• 27:44Wes Bos?

  The URL. The browser's URL is the OG state management library, because if you are filtering something, if you need to make something sortable, shareable, whatever, simply just put it in the URL and have your application UI react based on that. If you take, if you go to syntax.fm and you go to shows and you filter for different types of shows, for how many shows you want, for sorting, and what page you are on.

• 28:20Wes Bos?

  All of those things are not buttons or whatever to be able to to do some sort of complex filtering. They're links. They're links. And we programmatically generate the links to those pages. But the state management for the show filtering is simply links. And you can control how you sort it, how many per page, what type of episode, all of that good stuff, simply by visiting different URLs. And because now we have push state, where you don't actually have to refresh the page when you do this type of thing, it makes a really nice state management library.

• 28:58Scott Tolinski?

  Yeah, the best part about it is, for me, is that they're shareable, right? And if you think about it, if you take a very like wide stance out your website or application, even just with a general URL or a general path in your application, you could really think about that as being state, right? When your website loads, or even like when your server gets that URL, it takes that and knows what page to load, because that's the state of your website at that point. So it is definitely the URL and query params are really super underutilized for this type of thing. Next one I have here is IndexedDB, local storage or cookies. There's also session storage, which I don't know about you, but I almost

• 29:42Scott Tolinski?

  find myself never using session storage. I don't know why. Maybe that's a gap in my knowledge.

• 29:47Wes Bos?

  Yeah. You know what? The use, the difference between session storage and local storages is if you have multiple tabs open at once, does, is that shared across the tabs? Or is it unique for that? Because there could be a situation where you are making, you're working on two things, right? And you want to save that, then that might be session storage. And also, session storage will clear itself.

• 30:16Scott Tolinski?

  When you close the tab.

• 30:16Wes Bos?

  When you, when you close the tab, which you may or may not want.

• 30:20Scott Tolinski?

  I know, I just don't, I, you know, maybe I think that doing the same thing in two different.

• 30:23Wes Bos?

  I rarely use it.

• 30:24Scott Tolinski?

  I rarely use it, if ever. But I think these often get overlooked as a place to store state, even though people do often store state inside of cookies. You could think of like, I mean, you're accepting a cookie banner and you're saving that information to say, yes, I accept that we're tracking or not tracking cookies. That You know, that save of that state is being saved into cookies, most likely. And likewise, index DB, and that's a whole database there you can save stuff in. Same with local storage and you can pull that stuff up later. We use that to store like the current, like if you're listening to a syntax episode on syntax.fm and at any given point, that timeline is updating and saving the state of that player into index DB.

• 31:10Scott Tolinski?

  And then when we want to load the site the next time, we want to start you off in the exact same place you left off. So we're saving that, we're capturing the state of that and keeping the state of the player in index DB and using that to control the interface when the page is loaded.

• 31:27Wes Bos?

  Maybe one, one thing we haven't talked about here, but is probably worth mentioning that you're talking about index DB is like, like sync engines, right? The whole local first, being able to communicate with the server and possibly even the database is, is often being attached to your state management, right?

• 31:46Scott Tolinski?

  Yeah, let me even tell you, I've been using a platform zero, uh, which I'm really excited about from the replica cache folks. I'm not going to go deep on this until they fully release it, which I'm sure they, they will somewhat soon. Or at least they'll release an alpha version of it. But when you work with something like that, where the cache, the front end cache of your site is one to one with your database and I'll save locally. You really do start to have your database be the state of your application. It's pretty dope.

• 32:16Wes Bos?

  That's wild. Uh, form data is, is a way to hold state. I thought this was, I was like, is that a state management library? And it kind of is. So form data is an API in JavaScript to hold data. Because forms, forms can be complex, right? You might have multiple inputs, you might have multiple inputs with the same name, right? Like, for example, if you have a pizza order form, you'll have toppings and you'll, you'll have multiple toppings that need to be stored. So you, form, form data is a great way to.

• 32:51Wes Bos?

  Store data, especially because that API is standard. It's standard in the browser, it's standard on the server. We're seeing a lot of remix React server components. I'm like, what are the other things? Form data, Svelte, pretty much all of these libraries that expect data to be sent to it is being sent via form data. So, and also form data has a really nice API. It has.

• 33:17Scott Tolinski?

  It's a nice.

• 33:17Wes Bos?

  Getter and setter methods. It has, sorry, you said what?

• 33:21Scott Tolinski?

  I said it's a nice-ish API. I would wish I could just do form data dot property. That would save me a lot of.

• 33:28Wes Bos?

  Yes, dot get, because you have to use dot get and dot set and dot has. And if you want to be able to loop over what is in your form data, it can be a little bit complex. But there's, there's methods for that, but it's, it's pretty sweet. You can check, it does, it has a dot has method. So if you want to check if your, your value is in there, it's pretty nifty. So form data, kind of a way to hold state, great way to set, at least to send your state from your client to your server.

• 33:56Scott Tolinski?

  Yeah, for sure. The next one we have here is signals. Now, it's so funny, we've done so many episodes talking about signals. But whenever I see like signals in this kind of context, I'm just always thinking like, what exactly makes them special? Do you know what I mean? Like, what exactly makes them interesting compared to, you know, some of these things? But a signal really is, it's a way of, it's like an observable state, right?

• 34:24Wes Bos?

  Signals are a great way to define reactive state, meaning that instead of in JavaScript, if you think about it, like not even in terms of React or, or any frameworks out there. If you think about, I have this piece of data that other people may care about when this data is, is updated. I may care in other parts of my application where when this data is updated, you may want to store that data in a signal. So that in other parts of your application, you can subscribe to that data. You can have an effect when that data has, has been updated. I always recommend to people, if you want to really understand signals, there's kind of two ways to do it.

• 35:06Wes Bos?

  First, go to the Solid JS docs and just read through their signals documentation in like 10 minutes. It's probably one of the best implementations of signals. The other one is preact JS. Has this has a signals library, which is not tied to React. So people always say, oh, I'm not using React. It's it. You can use it with vanilla JavaScript. So try to build a little application. Where when you update the data in vanilla JavaScript, anywhere that state is then used. Will will be updated and the preact JS. Library, it's like, I don't know, it's like 200 lines of code or something like that. And it's a really simple implementation that really helped me understand it. And then, of course, we have, sorry, go ahead.

• 35:50Scott Tolinski?

  Oh, no, I was gonna say, yeah. And also, another great place to learn about this is. The signals proposal, because they're proposing to add signals to JavaScript as a whole. Now, it's only stage one. But the explanation is really good, and it makes a great use case on why it even shows like. Computed properties, which we we mentioned a little bit, but let's say you have a value that's derived from another value. This is a good way to use signals because, again, it's if one value is changing, then we're able to. Modify another value based on that values change, right? You're having a computed property. And I know derived and computed properties are built in and baked into Svelte and view.

• 36:30Scott Tolinski?

  And honestly, there is a really great way to work because I feel like a lot of times we end up having derived state without even thinking about it.

• 36:37Wes Bos?

  Oh, yeah, absolutely. In in the React world, you you generally just like putting that into. Your templates or you have a function that will will derive it for you.

• 36:48Scott Tolinski?

  Then you have to worry about memoizing and.

• 36:50Wes Bos?

  Yeah, or if you want to listen for when that derive value is of a specific value. Then you're getting into having to to code like a custom use effect. So. I'm I'm pretty excited about this signals proposal. I'm I really hope that it makes it in.

• 37:06Scott Tolinski?

  Me too. Yeah, especially because it's how I've gotten used to working. So if that becomes. Baked in and since it's it's a lot of how you work in Svelte. I think, you know, their their plan is with their new state, I think they designed it around once this. Does get into the language, which I think inevitably it will, that they could just. You know, remove a lot of their library code from that. Another one that we don't often talk. Talk about, we did mention a little bit when we were mentioning local first is the server database can often store state. I think about like user preferences are often like application state, right? Whether that's a user theme, the whatever user preferences you have, those are more often saved in the actual database.

• 37:45Scott Tolinski?

  Because you want those to persist from device to device, or you want them to persist more so than just an individual client.

• 37:53Wes Bos?

  Yeah, and we talked about the sync engines. For example, in my course platform, we have some state which is where are you in the current video, right? You want to be able to do it. And then we also have state as how have you watched? A list of all the videos and which ones have you watched and how far along each of the videos are you? And that allows us to render out a list of videos and check off the ones you've watched and show you a little progress bar on the ones that you're half done. And that's, that's interesting because that state must live client side. Because it has to render out the list of videos and where you are and update every, every video update, which is every five, 10 seconds.

• 38:36Wes Bos?

  But then it also has to be saved server side, because if you, you come back the next day, you want all that data to be done, right? And that's where you get into needing a sync engine or just a, just a function that pings that data to your backend and actually saves it.

• 38:54Scott Tolinski?

  Word.

• 38:55Wes Bos?

  Global versus component state, the, we kind of covered this, but the idea of global state is that something that needs to be accessed anywhere inside of your application. And then a component or local state is state that generally just exists inside of that component. So if you have a contact form, you might just have local state inside of that contact form to manage the inputs, manage any errors that need to be displayed, anything else like that, right? Whereas a global state may be something about who is the, the current user that is viewing this type of thing, right? You need information about the user everywhere, or is, is the cart currently open or what?

• 39:38Wes Bos?

  Video is the current user is watching. You may need that data globally. And if that's the case, you stick it globally.

• 39:46Scott Tolinski?

  Yeah, I know. An example I had on this is my habit tracker. What month you're on, because it shows a month by month view. Right? Several parts of the application need to know what month you're on at any given point, whether it is the list of habits or any sort of form you have, things that are not connected in the tree. This is like important state for the entire application to know. We're like, yeah, you have a modal or a drawer. That thing is local state. It's either open or it's closed. Right?

• 40:15Wes Bos?

  And global state doesn't have to be like application wide. It can be something that lives just at a certain level. Cause like, for example, if you wanted to show multiple months at once, then you would have two of those components, each with their own global-ish state. Right? It's local to some component. Yeah. Branch state. That's a good way to put it.

• 40:38Scott Tolinski?

  Yeah, totally.

• 40:39Wes Bos?

  Sharing state. How do you share state? There's kind of two ways you can do it. You can import and export the state into the components that you need. This is generally my preferred way to do it where you have like a store dot TS file. You create the store in there along with any other functions as to how to update it. And then anywhere you need that in your application, you will then import it. That's, that's good for global state. The other way to do it is you inject it at the level that you need it. And then you can pass it down somehow, either via context in React is a common way to do it. Or you simply use prop drilling, which is you pass it down via props to three levels.

• 41:22Wes Bos?

  Anywhere past two or three levels, it starts to get a bit hairy.

• 41:26Scott Tolinski?

  Yeah. And this actually is something interesting. If you're working with server side state, you kind of always have to be careful. Like if we have server side global state and it's being defined and created outside of the context of the current like loading flow, that state could be created accidentally globally server side. So you do kind of have to pay attention to is this state being created? For this specific user in their specific path, or is the state being created globally and all of a sudden we're shoving sensitive information into this this global store by accident that perhaps is available to the entire server, right?

• 42:07Wes Bos?

  Yeah, and that that simply can be a variable that is scoped to your module. So you have a handler where someone visits a page on their website. Inside of that handler, you're you're going to have local variables, right? But if you touch a variable that is above that handler, but still inside of the module, those are shared amongst, at least in JavaScript, it's not the same in in other languages like PHP. But those variables are shared and you you might want that. That's that's great for sharing data between requests. For example, on the syntax screenshot tool that we use for the Open Graph images, we stick a global variable for the browser that takes the screenshot so that it's faster

• 42:51Wes Bos?

  every single time that you use it. But if it's sensitive state, you don't want to do that, right?

• 42:56Scott Tolinski?

  Totally right. Yeah, absolutely. Let's talk about state libraries specifically. We've talked about a lot of these over the course of this episode. But if you're wondering about state libraries, it is funny that the way that this kind of works is that you have a whole ton of state libraries for React. And then you have Solid has their own signals based implementation. Vue has their own state and in like, kind of built in state with Pinia. And then you have Svelte, which has its own state implementation. So when we're talking about state libraries, it almost has to be like, these are the state libraries for React. Because I don't know why, but it feels like React is just one of the ones where they

• 43:41Scott Tolinski?

  they have the local state figured out, but maybe like more advanced state, they're just like, all right, we'll leave it to user land. I mean, I don't know. Do you feel like you need a library, even before we get into the libraries?

• 43:53Wes Bos?

  Yes.

• 43:54Scott Tolinski?

  In React, do you feel like you need a library beyond context and state?

• 43:59Wes Bos?

  I do because of the re-rendering issues in React, right? Ideally, you use state for whatever you want, you stick it in a global context, and then you can grab it out of context whenever it is that you need it. But there's performance issues that sort of come along with that. And I don't absolutely love the API for that type of thing. I'd rather just import it wherever I want. And you can kind of get that API with a custom hook. But I prefer the other options that are out there when I'm doing a little bit more complex stuff. So I'll give you an example.

• 44:42Wes Bos?

  So I just rewrote my checkout for my courses. And I was like, hmm, I need something to hold all of the state for the checkout, right? Because there's going to be all the information that the user has typed into the boxes. There's going to be information about what course they're trying to buy. There's coupon code information. There's error and success messages that need to be displayed. All kinds of stuff that goes along with that. And to make it even harder on myself, I wrote the checkout in React, but the actual website itself is just vanilla JavaScript. And I needed to be able to share the state between vanilla JavaScript and in the React world.

• 45:27Wes Bos?

  So I actually opted to go with Zoo Stand after looking at all of them. And it's a pretty nifty one. First of all, because it works in vanilla JavaScript, which is something that a lot of times people need, right? You might not be using a framework. You might just be writing some vanilla JavaScript because it's totally doable. But you still need the ability to listen for changes and to be a little bit more complex with how things work. So Zoo Stand was... Was my choice there. And the way that Zoo Stand works is that you create a store with your data in it. And then you also define the updater functions that go along with it.

• 46:08Wes Bos?

  So if you, their, their example is you have a store called a bear store and you have how many bears you have, you have zero. And then you can also define increase population and remove all bear functions, which will increment or reset the number of bears in that store. I don't absolutely love the API because it makes you, when you want to use one of those functions, or you want to use a value from your store, I'm used to just like bearstore.bears, you know, I just want to reference it. But because of the way that rendering in React

• 46:47Wes Bos?

  works, they say it's better to use this like weird callback function API where you simply just pick and choose the parts you want for that component. And the benefit to that is that you explicitly are telling it what you're using. But this comes back to my whole, can't you just figure that out for me?

• 47:08Scott Tolinski?

  I know.

• 47:08Wes Bos?

  I'm just using the variables.

• 47:10Scott Tolinski?

  I know. I like Zoo Stand the most in the React ecosystem. I have, it's funny, I spent so much time in the React ecosystem that I used Zoo Stand in production code. I've used Redux in production code. I, I never really got into Mob X. And Mob X is kind of an interesting state because people like Mob X. And what's interesting about Mob X is that there's also Mob X state tree. And like, just like with Redux, when you're talking about Redux a lot of time, people have their own Redux stack of all these different Redux thunk, whatever stuff. And I honestly, the amount of things there, whether it's using

• 47:54Scott Tolinski?

  just Mob X, or you have to use Mob X state tree, or whatever, that conversation has turned me off so much from using that I never used it, even though I'm quite sure that I would like Mob X based on what I've heard about it. But again, it feels too complex to me in that sort of way. And I'm sure it's just a skill issue or something I haven't really, you know, it's not anything I've done before. But

• 48:19Scott Tolinski?

  Yeah, I don't know. I don't have too many thoughts about MobX other than I know people like it and I know people use MobX State Tree a lot. Have you done any MobX work?

• 48:28Wes Bos?

  I have not, and I think it's just due to not necessarily needing that types of thing, right? The types of applications that people are building when they use MobX or Redux or Xstate, Xstate Store, these libraries require a lot more boilerplate. And I also just feel exhausted looking at the documentation for these types of things. Because like the simply setting up a variable that needs to be updated. Wow, that it requires its own file and like 40 lines of code. But I understand that that's not everybody's use case. People want to have full control over how this data is updated and how it's stored and how you can subscribe to it and all of that good stuff.

• 49:13Wes Bos?

  So I certainly understand it, especially as you get into more complex applications. Like for example, their most highest sponsor for MobX is Canva, right? Oh, you're building entire Photoshop in the browser? Yeah, you probably are gonna be thinking a lot about state management.

• 49:31Scott Tolinski?

  Yeah, I know. I do feel like, man, I feel like isn't MobX, MobX is signals, is it not? Or is it observables?

• 49:40Wes Bos?

  It's observable based.

• 49:41Scott Tolinski?

  Yeah, it's observable based. So in just looking at the docs for MobX in general, it looks like a slightly more complex version of what I'm using in Svelte. So for me, I'm sure I would like it if I got past that initial feeling of, oof. Because I felt that way about Redux. And when I started using Redux again, like I definitely got it more. I don't think I ever like truly was like, yeah, Redux the best. But I do understand the utility of it. And so maybe that's just, I bet it's just a blindness, a skill issue. If you're using MobX, MobX State Tree, and you want to kind of give us a, what the heck's the difference there? What do you actually use? What are people actually using in MobX land? I want to hear about it.

• 50:25Wes Bos?

  There's also Joe tie, am I saying it right? Jaw tie?

• 50:29Scott Tolinski?

  Joe tie, yeah.

• 50:30Wes Bos?

  Joe tie.

• 50:31Scott Tolinski?

  Yeah, two syllables, Joe tie.

• 50:33Wes Bos?

  So I explained earlier that Joe tie is more of like a primitive. And if you want, just like quickly get up and running, not to say that it can't be used for complex stuff, but if you want, especially for global state, Joe tie is really good. It's similar to how React does use state and you can combine them together. It's a really nice API and often used for, you can use Joe tie and Zustan together. I believe they're by the same developer. Is that true?

• 51:05Scott Tolinski?

  It's possible. I felt like they were at some point, but I guess I don't know now that you say that.

• 51:11Wes Bos?

  Yeah, hold on, let me, let me look this up. Zustan and Joe tie are written by the same guy and oh, even Voltio? This is another one I've not checked out as well. Proxy state management for vanilla and React. Man, and the same guy is working on like Waku, which is a React server component framework. So certainly those are all worth, worth checking out. And it's, it's very clear that if the same guy has built three state management libraries that are very good, it's clear that there's different ways to approach and solve these problems.

• 51:47Scott Tolinski?

  Now, if you're listening to this episode, you know the answer to that. There's also Xstate, which we talked a lot about state machines. And Xstate is a really cool platform because it basically allows you to have a system of working within state machines specifically. And it feels like something, again, that if you're building complex applications, Xstate feels like it would be a really great option to go with, especially if you're having a hard time wrangling like the actual state of things. And there's a great little visualizer that they have on the site and helps you build state with a visualizer. I do like all of that. What is this Xstate store you have posted here?

• 52:28Wes Bos?

  Yeah, so Xstate store is from David K. Piano and it's sort of a simpler version of Xstate. I don't know if this is true, but I think a lot of people say that Xstate is cool, but I don't necessarily have those problems. I've said that many times, right? So Xstate store is sort of a simpler version of that where you can get up and running. It's very similar to the reducer pattern that we just said, which is you create your store, you create your actual initial data in it, and then you can define the function updater functions that how you can interact with that actual data. I tried

• 53:08Wes Bos?

  it out when I was evaluating it for my cart checkout. But again, it just felt, there was, there's two things. First, it felt like a little bit too much boilerplate code for me. It was not needed. And then the other one was, I didn't like that when, when you want to run a function, like for example, they have an example where they have a donut store and they have zero donuts. And then when you want to add a donut, what I would like is donutstore add donut function. But what it actually is, is donutstore send, pass an object with a type, and the type is a string of add donut. And again, I get

• 53:52Wes Bos?

  that because it's very, very complex, but I don't like passing my like, functions as strings. And I know that people are probably cringing at me right now, but I just want a nice function that I can run. And Zoo Stand gives you that.

• 54:07Scott Tolinski?

  You're just trying to function. Remember that song?

• 54:10Wes Bos?

  Or a method, I should be saying.

• 54:11Scott Tolinski?

  I know, you should be saying that. Oh, my God. What year did that come out? 2020, 2019? Maybe even older than that. Oh, man, this is gonna be really embarrassing if it's like 2015. Uh, hold on, I'm just trying to function. Oh, no. Oh, my God, Wes, this song came out 12 years ago.

• 54:33Wes Bos?

  Oh, my gosh.

• 54:34Scott Tolinski?

  Came out 2012. And I was thinking.

• 54:36Wes Bos?

  2012 in my mind will always be eight years ago, no matter how fast the things go. 2012 was eight years ago.

• 54:44Scott Tolinski?

  And you know, I should have known it was this long ago because they made a joke about it on Workaholics and that show was at its peak in 2012, probably.

• 54:56Wes Bos?

  Other state management libraries, there's another one I found called EZPEEZY, which is similar to Redux, but kind of a, kind of a nifty, nifty little API for working with it. And it looks like it's in, under very active development, a vegetarian state, friendly state management for React. So this one looks pretty cool. It has a whole like React Hooks API with it.

• 55:23Scott Tolinski?

  Yeah. And, and for Vue, we mentioned Pina, or it's up, it's up, it's.

• 55:30Wes Bos?

  Pina.

• 55:31Scott Tolinski?

  Pinea.

• 55:32Wes Bos?

  Pinea.

• 55:34Scott Tolinski?

  Pina.

• 55:34Wes Bos?

  P I N A.

• 55:36Scott Tolinski?

  No, it isn't. It's P I N I A, which I thought it was.

• 55:41Wes Bos?

  Oh, yeah. You're right.

• 55:42Scott Tolinski?

  Wow. This is a, yeah, this is a definitely a moment for me. I thought it was the same way that you were saying it was. But I do think a lot of people just use the built-in Vue state. But if you need like.

• 55:52Wes Bos?

  Yeah.

• 55:53Scott Tolinski?

  Bigger state, more modular, safe. This is like the community approved one, so to say. This is what people are using.

• 56:01Wes Bos?

  If you're doing a lot of like fetching between APIs, back and forth, doing mutations, being able to update data, Tensac Query is, is one. It's like, I would consider that state management as well as like a whole HTTP library. Because what it does is you can give it like a promise, which is post to a endpoint to update some data, or use a get request to, to load in data. And then you also get variables, like loading variables, and you get to, you can control how the data comes back, you can cache it, you can refetch it. So Tensac Query is kind of an interesting one, because it's a state management library, plus a whole bunch of stuff for working.

• 56:47Wes Bos?

  Working with the server.

• 56:49Scott Tolinski?

  All right. Well, that is it. That's a lot of stuff.

• 56:51Wes Bos?

  Yes.

• 56:52Scott Tolinski?

  That is state in JavaScript. I know a lot of these things are React, a state in React, but this is state JavaScript in general. And a lot of these libraries that we did mention can be used with vanilla as well. Let's get into the part of the show where we talk about sick picks. I have a sick pick for you today and it was one, because we just did our holiday sick pick episode. It's one that I actually had in that, but we hadn't, I didn't have it as a normal sick pick. So we'll do it again, just in case that episode didn't appeal to you. And I don't know about you, Wes, but I've been looking for men's body wash for a long time. That is like-

• 57:26Wes Bos?

  I have not been looking for that. No.

• 57:28Scott Tolinski?

  Yeah. I don't, I don't know why, but like I'd never found a lot of men's body wash that I really liked. I know a lot of it's just cheap garbage or whatever, or it just smells like normal. But I wanted something a little bit more like manly smelling. So I found this brand, this Cremo, Cremo, and they all are like branded after different types of like whiskey, whatever. And for the most part, you don't have to worry. It's not like it smells like whiskey. But I, I found this stuff to be really nice. Just about everyone that I've smelled so far has a bit stronger of a smell, but it is a nice kind of like deep and smoky type of smell in general, or those types of things, rather than like, I don't know, just lavender and eucalyptus. So, yeah, I've been a fan of

• 58:11Scott Tolinski?

  this. I think somebody recommended it on Reddit. And since then, I've tried a few different ones. And they make shampoos and conditioners and stuff as well. So if you're out there and you're looking for a little bit more of like a manly dude smell, this is, this is pretty good.

• 58:27Wes Bos?

  I, I'm a big fan of the Suave Zito. They have a body wash, but they also just have like a bar of soap that smells amazing. And it's a huge bar of soap and lasts forever. So I've been, I've been using that for a couple of years now. A big fan of that. And my kids, my, I don't, my kids don't love the smell. You know, like when you're a kid and like you would smell some like old dude with like musky cologne. I wonder if it's similar to that. I love the Suave Zito scent that they have, but my kids don't love it.

• 58:59Wes Bos?

  I'm gonna sick pick a bento box that we got for our kids. So we switched from sending our kids to school with lunch pails to just sending them with a single bento box. Because what was happening is they would come home and like the, the school doesn't want you to use like any plastic bags or anything to give them their snacks. And so we've, we were having like a thousand, a whole dishwasher full of these little cups that you had to wash. And it was getting to be a bit much. So we're like, what if we move to bento boxes?

• 59:30Scott Tolinski?

  And yeah, we tried a couple of them out, but they're all way too small to actually like,

• 59:36Wes Bos?

  like, what are these kids eating? Like one cucumber and like half a sandwich? Like none of them actually fit a full sandwich in there. So we finally found, it's called an adult bento box, which is silly because they are fantastic. It's three levels and they have rubber seals on them. So you can, you can send them with wet stuff or jello. They're, they're microwavable so they can pop the bottom off, throw it in the microwave at school. And I searched for probably a year. My wife is like, we need bento boxes. And I would be like, these all are awful. They're all way too small. And we finally found one that we're, we're a big fan of. So I'll link it up. It's, it's called the JS cares bento box with the three levels on it.

• 1:00:19Scott Tolinski?

  Wow. Okay. I'm gonna actually even follow this up because Courtney has a three level bento box that she uses for her lunch, which is by Bentgo. And I think it's really nice because it has like a, a thing for salad dressing and has a spot for a fork to get stuck in there too. So you can always have a, a fork utensil. And I actually really like hers. I don't have one myself because I'm always eating here. We got the, the kids Bentgo ones for the kids, but yeah, they are pretty small.

• 1:00:48Wes Bos?

  We saw, we looked at them. We went to Costco and we looked at the, the bent, bent, yeah, Bentgo. And there's the dividers are like half the size of, they're way too thick. And then they got, some of them have like, like water in them. So you can freeze them and it maintains cold. And like, that's too heavy for the kids backpacks.

• 1:01:07Scott Tolinski?

  I, I does, I do feel like ours are too small for stuff. Cause when I'm filling my kids lunchbox, I'm like, how am I supposed to get all of this stuff in here?

• 1:01:15Wes Bos?

  That was the problem we had. We, because we looked at that Costco sells those Bentgo ones and they're, they're no good.

• 1:01:22Scott Tolinski?

  Well, we use them. They're nice, but they're too small for sure.

• 1:01:25Wes Bos?

  Yeah, definitely check this one out.

• 1:01:27Scott Tolinski?

  Yeah, cool. Sick.

• 1:01:29Wes Bos?

  All right. Shameless plugs. Check out the Syntax YouTube channel. Subscribe, watch. CJ just released a video on mapping software. So alternatives to Google Maps and really good video. You're gonna want to check that one out.

• 1:01:44Scott Tolinski?

  Yeah, super good. Cool. Well, this is as real as always, so we will see you in the next one.

• 1:01:48Wes Bos?

  Peace.