React State Round Up

You're listening to Syntax, the podcast with the tastiest web development treats out there. Strap yourself in and get ready.

Tolinski and Wes Bos.

Welcome to Syntax.

This podcast is the tastiest web development treat podcast in the world. Woah. Yeah. Just switching it up a little. Switching it out. Yeah. You know? Today, we're talking about React State. We're gonna do a roundup. So Scott and I both have a big bag of Arby's that we're chowing down on right now. We're gonna do a roundup of all of the different not all of them, but a handful of different React Scott libraries.

Would you use them? Why would you need to use them? What's the pros? What's the cons? But I think it's gonna be a good one. We are sponsored today by Sanity, which is a structured content CMS and Sentries error and exception tracking. We'll talk about them partway through the episode. My name is Wes Bos. I'm a developer from Canada. And with me, as always, is mister Scott Tolinski. How are you doing today, Scott? Hey. I'm doing good. I got a dog barking in the background.

That's how you know it's, it's gonna be a great episode. Right? No. I I'm doing good. You know, I'm, I'm I'm jazzed up. I'm ready for the week. I got a course coming out this week, so I'm, in that mode. I gotta edit a whole ton of videos tonight, and, I'm really excited about getting this course out because I'm I'm really into it. So yeah.

Awesome. That's great.

Well, let's just get on into it. You, you wanna kick it off there with the 1st library?

Yeah. Let's get it going here. 1st library is not a library, but it's part of React, and that's context.

Node, I figured we would do this like this. We would first start off with, like, a little bit of have we each used it and what our experiences are with Sanity technology and then maybe get into some pros and cons.

So I should state, 1st and foremost, that I absolutely have used React Context. In fact, that's currently how we do all of our, like, application state, not like the data state, but all the application state in our, Vercel up tutorials is done via React context using the fabulous use context hooks JS well as several contexts.

I think we have, like, 5 or 6 different contexts that we have, and they're all maybe split up in terms of, like, what their use cases. So we have a context for the checkout.

We have a context for, you know, the navigation. Is the nav open? That kind of thing. We have a context for okay. I have one for the login window. If the application is currently loading, I have Node for alerts. I have Node for user information. I have one for the search context for the checkout experience.

So you've broken those up into a whole bunch of different React contexts, and, that's what we're using.

Awesome. That I use React context myself. And we should say that, like, React context is not actually a Scott, does not actually hold any data.

Context is simply just a way to get something that is higher up in your application to a and inject it into wherever it is that you need it, generally a lower place.

And it's sort of an alternative to using where you would have to pass the data down every single time. So the actual, like, state part of React context is just plain old React state or or, really, you could put it anywhere, but, likely, you you put your state in React Scott. And then you also have your updater functions and any other logic functions that that need to to come along with that. And then you can export those things and and sort of ship them off via contacts, or you put them in contacts. And then wherever it is that you need them, you can you can access them with a use context hook, which is pretty nifty.

Or or check this out. Yep. Here's what we do. This is fantastic. I'm gonna blow some minds here of people who haven't done this before, maybe yourself included, Wes. What we do and by we, I mean, I myself because I made this. What we do is that we take for all of our contexts.

We basically just export a function that returns the used context of the context itself. So here's the line of code. The x like, for my alert context, I export a function called use alert, which is really just a function that returns use context with the alert context in it. So, therefore, we now have a use alert, so I never need to import use context itself when I'm using anything. All I do is import use alert and then can pull out the things.

So what it saves you is it saves you from having to import the context and import use context and allows you just to import One thing.

The Node thing. And it's it's a little bit more explicit. It's more readable. And to me, it's just nice nice little shorthand. Yeah. We I we do that in my upcoming,

advanced React rerecord. So we have, like, a used cart. And it's great because you can you don't even have to understand that it's context after you're done building that hook. And you can simply just say, like, const cart items equals use cart. Yeah. And it would return to you the data, and then you can use that you can go ahead and just use that data. It almost seems like magic. So, yeah, big fan of that. I'm glad you said that because you can tuck it away nicely like that. Yeah. So pros to that, that's built into React. It can be as simple or as complex as you want. There's no, like, sort of best practices around this. There's a couple libraries out there that sort of teach you to do that. I've never used a library for it because I've not seen the use case. I've just stuck my state in context, which is cool.

And then the cons to that, it takes effort to optimize.

And Scott wrote that. You wanna explain what does that mean and why it takes effort to optimize?

Yeah. If you just go ham with context and throw everything into 1 context or you just start keeping everything sort of willy nilly into a context that could be rerendered when any of its values change, you Scott keep in mind that those Yarn basically, you know, a React component that is going to, again, rerender when anything triggers a rerender on that. So if you if you're keeping too much state or unrelated state into various providers, you can trigger rerenders when you are, unintended to.

So it's it's sort of a best practice, then you would say don't put too much stuff. That's why why you you say I have, like, 3 or 4 states in my application. Instead of just putting it all into 1 global context, you have multiple, and and that avoids those unnecessary rerenders because you're only using it where you need Node? As far as I understand, yes.

There there seems to be a lot of, like, posts around optimizing context, and and some of them talk about using use memo and whatever. But I personally haven't had a need to do anything beyond splitting up my contacts Yes. Into, like, things that would, you know, actually make sense in being together. As in, like, the alert context only cares about the alert stuff, and

checkout only cares about the checkout. You know? It seems like one of those, like, those things that I wish React would just take care of for me. Yes. Because I it's just such a simple, beautiful API.

You stick your stuff in a in a context. You access it via hook or you make your own, and it just works. And, like and then and then you get people come and be like, well, you should wrap news memo on that sometimes, and here's why. And I'm just like, Wes,

mhmm. This is why people don't, like, react. Yeah. This is exactly why people don't react. And and it's funny because, like, if you look at Svelte I I hate I hate doing this because this is like now that I've learned Svelte, I'm gonna just keep on going. That to me. I'm at the trombone over here. Vercel person's face. I know. I'm I really hate this, and I hate that it's it's obnoxious that I'm even doing this. But, if you look at how how they manage state, it is it's like its own thing. You don't have to worry about providers. You don't have to worry about wrapping stuff.

You just get something. You said something. You update something or whatever, and it still JS. And it can still be as robust as you want it to, but they don't like I don't know. They don't make you think about these optimizations. They don't make you think about this kind of stuff.

Yeah. I I like that as well. I wish React would do a little bit more than that, But then again, like, I don't run into that issue all that often or or ever, really. I've never run into performance issues or rerendering issues with context, so, maybe I am using it properly.

Yeah. Right. I know. I I have run into issues myself personally where it was, like, doing things that I wasn't intending it to do because of that loading order or whether or not there were like, for instance, I threw my checkout stuff into a context, and then all of a sudden, it was loading my API keys, you know, on every page load not on every page load, but on the initial page load even when somebody wasn't accessing the checkout. Oh, yeah. So then you have to put in, like, a use lazy query into Apollo to to get the right query happening and stuff like that. So, I mean, there's definitely foot guns, possible foot guns. So next step is Redux.

Now Redux is, you know, king of the hill. It's been around for, well, forever at this point in terms of in web developer years. It's been around for a very long time. We have both used it. Correct? Yep. Yeah. Yeah. I did a whole course on on on Redux myself, and I did a couple little podcasts on it. Yeah. We both did courses on Redux. That's why jokingly mentioned that. We both used it. So we got we both got experience with Redux.

It has a huge user base. It has a huge legacy of, growth and improvements and changing with the times. It's not like, one of those stagnant libraries that was just created, and who knows when it was last updated. Redux has evolved.

It, you know, has a hooks interface and those kind of things.

So it does have a modern API.

I used to have Vercel up tutorials on Redux before we moved to straight up context.

Actually, we might have moved to Apollo State at some point in the you Scott realize that I use a lot of these libraries as, like, testing grounds for learning them. So when I say Vercel up tutorials was on Apollo State, yes. Sure. Our entire application was on Apollo State, and then it it was on or it was on Redux before. Yes. It was on these things. But I I'm rewriting this application because it's code I really know. And if I get to try this library in the context of code I really know, it really helps me understand it. So I'm not just, like, that crazy about switching libraries.

I I just like to use my own code as, like, a a playground for, learning new things. So the level of tutorials at one point was in Redux, and, the things I like most about the Redux were the dev tools. So it's fantastic to be able to see everything. That was great. What they call that the with the time? Time travel time travel Wes you can see every single state, that's sort of ever existed in your application, and you can go back and forth between them. Love that. Yeah. It was it was really cool, and you could also, like, turn

ones off. So if you did if you did 5 changes to state, you could go and turn the third one off, and your application would rerender as if that 1 piece of updated state never happened, which like, that you don't need that every single day, but it it is kinda interesting if you're debugging something. You know, sometimes where you get into these issues where it only happens when like, right now, I'm I'm Wes have a trouble with the suspension on our car. It only happens when, you leave the car for 24 hours and you you go to it and you turn it off. You turn it on and then off, and then come back and turn it on within 10 minutes. And then I'm like, this is such a weird sequence of events that it needs to that it happens. And if I had Redux dev tools for that, I could just, like, look at the like, turn it on, wait 10 minutes, turn it back off. I could, like, look at all of that and then just turn things on and off and be able to see which of these things contributed to the actual bug that was happening.

Yeah. I always really like that. Yeah. It's it's it's pretty cool. I, what another thing I really like about Redux, and this is also something I don't like about it. But, so when you have Redux, you have to have, I forget the what are the names of all of them? You have your reducer. You have your action. I know. Your actions.

Reducer.

Action.

It's been so while, like, one of my my biggest pet peeves about using Redux is that Your dispatch. Your dispatch. It had all those terms and lingo you had to learn, and and I think that

made it tough to learn. There's all those things, which is frustrating to learn. And often, you find yourself, like, with 3 or 4 different files in order to just update Node simple little thing. But a lot of people really like that because there was a very clear way on how to do this, and and that's something you don't often get with in the React world is like, oh, here's a couple different ways you can possibly do it. This is just like you make your reducer. You have an action. It has a payload. You dispatch that action. Your reducer will take in some data and return it. And that's, like, a very clear, crisp way forward, which is pretty cool for lot of people who want, like, a a just a recipe. That's what I'm looking for. Yeah. I just want a recipe on how to add data to my application, how to update that data.

Yeah. I always laugh that it Wes, like, the thing that calls the thing that calls a thing. You know? And and I think for users, like, beginners coming to Redux specifically, they don't understand why am I doing this. Like, what like, why is this why is this needed when it seems like it would be so easy to just update a variable or run, use Scott, but then you have the whole situation of actions and this you know, dispatch and all that stuff, it's just very confusing. Immutability thrown in there. It's usually their 1st

run-in with the this concept of immutability and not overriding things, and they have to spread the object into it or know what a deep clone is. Like, I also think, like, that was people's first introduction 3 or 4 years ago, a lot of this immutable functional programming. So you you threw that in as well, and it it probably confused more people than it actually helped.

Yeah. A lot of new concepts, a lot of language, a lot of syntax. And some of that stuff to me feels like it could've just been swept under the rug and made a little bit easier. That's the type of the APIs that I like is when things get swept under the rug just a little bit. But, of course, you know, different strokes for different folks. I I think there was also a bit of confusion around, like, what additional packages you Node. Because when people talk about using Redux, they're always like, I use Redux with Redux ducks and Redux orangutan and,

Redux Redux tree thing. And Touching data was like a whole another thing.

Redux snake ESLint, and, I use them altogether to do, you know, just very simple. So it's, like, very, like, weird to me, to know when to use, you know, whether it is saga or oh, man. I can't even remember all of the different Redux additions or Redux modifications or something like that, but it JS very confusing for new people. Thunk. Yes. Thunk.

Yeah. Come on. Like, I when you get into Redux, you're like, oh, I have this problem with Redux. This is annoying. Then you Google the problem, and somebody's like, use func, and then you use thump. Right? But then you're like, wait. Why why isn't this just part of it? Or why isn't this just the way That's weird that there Wes no, like, data fetching story built into Redux. And I I I get that that's not what it's for, but Yeah. It's mostly a little overkill. That was using it was fetching data from a server and throwing it into to Redux.

Yeah. So Redux has a lot of positives. And at the same time, there are a fair amount of negatives too, but it's a it's a fantastic choice. If you're looking to build your application on Redux, there's really no reason not to, especially if you're good with Redux. It it is a fantastic library. Even in 2020, there's there's really not a ton of reasons other than it is confusing and hard to learn. Those are pretty much the big ones. Well, it's sort of fallen out of love in the last year or so, and I think the reasoning behind that is,

like, when Redux came out, it seemed to be like people thought like, I remember people saying, like, React Scott is dead. Like, don't put anything in state. Everything goes in Redux. Weird. And, it it was like a weird time. And and then I think over the over the years, a lot of people were sort of looking at it and going like, you know what? We don't we don't actually need this for our application. There's certainly lots of applications that do need a very robust state management library like this, but we can get away with just using state, especially once context came out that was available to absolutely everybody.

That was huge because then you like, I think a lot of people are just using Redux just for the ability to inject state at whatever level that they need it. Yeah. Which to me seems crazy, but that's just the way it is, you know? Yeah. There wasn't any other way to do that in React before Redux or sorry, before context came along.

I did it via Meteor Meteor stuff, which is funny. We'll talk about a little bit later on in this. So it's like I had maybe a solution to that before the rest of the React world did just because I was using a

larger framework or something. I thought Meteor was dead, Scott. Yeah. It is. It's totally dead. Right? I mean, I Oh, I can't believe someone tweeted that. I thought it was a joke.

It's not a joke. Anytime you tweet anything about meteor people and it's like it actually makes me nothing will get the fists clenched faster. I'm like, oh, that's.

I like turn into a a motorcycle engine.

So okay. Let's keep it moving here. Next up is X Scott. X State, Wes. Have you used X State? I have not. I I feel like I've got a pretty good grasp on the the whys and the hows and the Scott of the ideas behind it, which are important because because we had David on the podcast.

But still looking for that project where I'm gonna gonna use it. I know. I thought I had found mine because I have used it, but I have not used it in any real capacity. I've used it in, like, toy capacities. You know? I've built built this some demos in it.

So, the thing about x state is it enforces really solid design patterns. Right? To use x state, you must know and understand the state machines. Right? And to know and understand state machines, it inherently is going to make you follow a pattern that is going to be a little bit more strict than some of these other ones, which JS, I mean, that's a pro of Redux too. Right? It's it's more strict in how you use it. This is how you use it. It's it it creates a very state safe state, you could say, as in, by not using Boolean variables to manage your UI, essentially, you are able to then have state that is a little bit more reliable in terms of not potentially producing UI bugs or errors.

And it also includes some really awesome tooling. I don't know if you've ever seen the x Scott.

Is it like a it's like a visualizer.

Yeah. The x x state.

Called the visualizer. Okay. Cool. I was just pulling that word out. So it is called the x state visualizer.

You haven't seen this before, just, I'll I'll put it in the show notes, the x state .js.orgforward/vis.

Again, I'll put that link in the show notes.

It's fantastic.

Really, really cool. Big, big fan.

Cons for x state warp that it it it includes some knowledge overhead where, like, you have to know and understand what state machines Yarn, do, and why why you would need them or want them because the code is going to be a little bit more complex. The syntax is definitely a little bit more complex to parse. If you haven't worked with state machines before, you might not understand it. And to me, personally, just looking at some x state code, I don't necessarily know what's going on off the bat until I really dive into the x state itself. Right? Like, when I first looked at maybe even like a basic one, I'm like, okay. I see this on fetch or whatever. Like, okay. How does this all work? So there's a little bit of mystery for for new people here. So, x date's a really interesting one. For those of you who want to learn a little bit more about x State, we did an episode let's find that episode.

206.

206.

Episode 206, Scott Machines, CSS animations with David Kaye Piano. Good one to listen to. Also, I did a a a fairly decent explanation about state machines in the last potluck, I think. So, check that out, if you wanna learn a little bit more about x Scott. What else should we check out, Scott? Well, well, okay. So that's a good transition, but have gone with something like if if your state is getting out of hand, maybe you should bring an x state to give it a little bit more sanity or something. That's I like that. That's that that's maybe where I would have gone. And I'm talking about Sanity at Sanity dot I o, which is the structured content CMS that is very fantastic. Do you wanna talk a little bit about Sanity, Wes? I do. I do. So this is a our sponsor

for today, one of our sponsors. And, they are they call themselves a structured content CMS.

Now what that means is that it's a it's essentially a headless CMS where you you start up a Sanity project. You create all of your different data types. You can relate them to each other. You create all the fields on each of those data types, and then you can fire this thing up. And, one option, which I think a lot most people probably use, is they also have this thing called Sanity Studio, which is a React application. It's it's really cool. It's like they host it for you, but you can also hack on it. So you can, like, deploy Sanity Studio either to your own or or to their own hosting, which is cool. And then you can create all of your own custom inputs if you need need it. So I'm working on my Gatsby course right now, and we're using Sanity in there. And, 1 Node input that they didn't have, was a price input. They have a number input, but not a price input. And I store all of my prices in cents. And sometimes that's that's confusing for That's really smart. Yeah. It's it's because then you don't have to do decimal math.

It's great. Well, I I I store mine in strings, like a string of a price. Do you really? Do you know what I mean? And then I can and then I convert it. Yeah. Which I don't know if that was the right call, but it was a call I made a long time ago Wes I was first starting this. It was like a it was a call I made several several years ago, and it was just like, okay. Whatever.

So I I I have to convert it, and that that's just like the a pain I feel like it ever since. I wouldn't yeah. Yeah. I I did early on, I didn't use cents. And there's it's a problem where if you have decimals, and decimals in JavaScript aren't easy anyways.

So I I personally have this in my own my own back end for my own course Wes the cents I I like if my if my assistant wants to give a refund, she has to mention how many cents she wants to refund. And that's confusing because, like like, what's $27.82 Node cents? I guess you just take No clue. Take the decimal out. But I don't get I don't know. Kind of scary when refunding someone because don't know if you're gonna accidentally pop an extra 0 on there.

So I just put, like, a little, thing above it. As you type, it will just replay it and format it with the dollar sign and commas and things like that. And so I built that same input for Sanity.

And I was like, this is great. Like, Sanity has, like, 98% of the things I want, but they didn't have this Node specific input that I wanted. So I just built it myself, and I deployed it to my own Sanity. Then I pull it all in. They have a GraphQL API. They have a, this really cool syntax language called Grok. You can pull it into your Next. Js site, your Gatsby site, you name it. So check it out on your next project. Sanity.

Io forward slash syntax. That's gonna get you double the free usage tier. Thanks so much to Sanity for sponsoring.

Awesome.

So let's keep it moving here into the next one. Now, Wes, I don't know if you've heard of this library, but I had really taken some time to, evaluate this library in terms of maybe the next React Scott library I should look at, not for obviously moving my project, but the next one I should look at as being, like, a serious contender here. And, this one is Zoos stand.

Zoos stand is really cool. I don't know if you've seen Zoos stand before, but it's a small, fast, scalable, scalable, bare bones Scott management solutions with it is a comfy API based on hooks.

It's not boilerplate y at all or opinionated.

So it's very cool. I really like the syntax for this. And in terms of, like if we were to give a syntax dollar signs, you know, I would say this JS, like, a $1.1 sign, syntax because, like, it is it's very, like, it's very simple. Very cheap.

It's not gonna take up a ton of ton of space in your code here. I'm not saying it's not it's not fancy because it's it's fancy. It's it's it's, very, it's very powerful, but it's not complex. Right? It's not expensive.

So to me, I like Zoos stand. It's basically a a simpler version of, like, kind of what you do in Redux. It almost feels to me like a more of a, like a a use state or use, reducer kind of way of just doing your entire global state. It has a fairly growing community at 2.6,000 GitHub stars. I don't know how many how many usages it has. It's a small library. And when it's m zipped, it's only 647 bytes.

Yeah. Wow. So that's not exactly adding a ton of code to your application. Yeah. Scott's uncovering it. Not a lot. About

7 1000, 8 1000 weekly downloads, which is not a ton.

So maybe you're uncovering really cool. It's from the folks at React Spring, so there's some good devs behind it.

This is pretty cool. So it I like the API on this. Funny.

I have a little callout here, and this is Scott's underground hot pick or underdog hot pick.

Underdog or underground, whichever one you want. And I like this. One of the cool things that I really like about this more than any other of these options, you don't have any providers. You don't have to wrap your code in a provider.

You know, I don't know about you, but my code looks like provider, provider, provider, provider, provider. You know? It's like a a giant pyramid of providers and then the actual application. So,

for that alone, I kinda like this. So how does it how does it, surface

the Just hooks. It's all hooks. Oh, it's they're probably,

I forget what's the the pattern for this Wes the first time it runs.

Memoize? Yeah. Yes. There you go. They're probably Memoize under the hood.

And they they use React Redux dev tools? Does it say that? Because I don't know if that's Yeah. At the very bottom. Dev tools take the store function as its first argument and option. Oh, that's cool. So you can use the Redux dev tools with this.

That's fun. Woah.

This is a sick Scott.

Zeus it out. And they got a cute little bear logo. It's a bear playing a guitar saying Zusdand.

I don't know what that word means, but I like it. I'm sure it.

Okay. I only I only know that because I googled Zoos stand, and it translated it for me.

Oh, that's fun.

Yeah. And there's a neat little demo. So, yeah, check it out. It seems like a a cool option. And to me, like, this is this is what hooks are all about. I think it's a, really neat evolution of how we view Scott in React. Beautiful. Next Node we have here is Apollo.

So Apollo is the we should probably say Apollo client here. So Apollo is like the GraphQL company, and they have Apollo Server and they have a bunch of monitoring products. But probably when we say Apollo, a lot of you are thinking of the Apollo client, which allows you to fetch data via queries JS well as send out data mutations, via queries as well. They have a really nice, React API that's, all hooks based used for, interacting with both the queries and your mutations and variables and and things like that. I've used Apollo quite a bit myself, in my advanced React course JS well as a couple other side projects.

I am a big fan of of how it works. They have a really nice cache that is built in. And Apollo 3, which is not released yet but will be fairly soon, has even more fine grained control over the cache. So sometimes you get into this, like, very aggressively cache situation, especially with pagination.

And now there is a really slick API that will allow you to clear out the cache as well as reuse items in your cache throughout multiple queries. And let let me explain that really quickly JS if you have a previously in in Apollo is if you have a query that has something like page 3 in the query and then you you query page 4, and those are 2 separate queries. And even if the item the items that are returned have some overlap between those 2 queries, previously, Apollo would think that those are 2 separate items because they're different queries. But, now they allow you to ignore specific parts of the query and then just sort of meld them all into 1. And they have this really cool API that allow you to read and merge the items as they come in. So big fan of how Apollo works. And the lazy query too. Yeah. Yeah. The lazy query is great because you don't need to use that. You Node, sometimes you don't wanna fire off a query on page load. You just wanna fire it off when somebody clicks a button or I specifically use that my search.

Mhmm. I don't want to fire off a query when the search loads. I wanna fire it off when somebody starts typing. So you can use lazy query for that.

I know. I'd always used mutations, and now it's like, oh, okay. Now you can actually use what makes sense. Right?

Yeah. Yeah. Exactly. I what I had done in the past is, like, I, like, queried it and then, like, had, like, a global or not global variable, but a scoped variable that was accessible, and then you store access to the client once it comes back. And it was a mess. So this is way better. Yeah. Mess.

And we should also mention, Apollo Scott, like the client state state. Yes. Oh, yeah. So in addition to you know, with your data because a lot of these libraries, they they just you know, Apollo client is more for, like, pulling in your data. Right? But in addition, there JS also, like, actual, like, application state features in here in the client state, and it's really nice to be able to include that with your Apollo queries. But I found in practice, it was a bit heavy handed in terms of the syntax, and it just didn't feel right to me after living with it for quite a bit of time.

Yeah. I I was the same way as well. It's just, like, it Wes way too too hard. And, ideally, I would love to have, like, my, like, my fetch data and my local state in the same thing. It just was it was too much for me. And I I think it's since been updated, but it still wasn't as simple as just using context for me. Totally.

So pros and cons. Works well with your GraphQL API, and they have dev tools. So those are pros for me.

But the cons, it's complex for, like, state application. Like, if you're trying to just change Node is the navigation open? Right? To do something like that is ends up being way too complex for what it JS. Right? We're just swapping a bullion.

Also, the dev tools for me are also going under a con because half the time for me, they do not work correctly. And, specifically, with local state, like, if I'm querying local state, you have to have the load from cache checkbox checked or I I I don't know. By the time I I dropped this, Apollo client for my application state, my local state, it, like, was never working correctly for me with the dev tools. So dev tools for me are always a bit hit or miss, and, yeah, that that's really my my my negatives for Apollo.

Awesome. Next 1 we have is RxJS, and this is not something I've ever used myself. So I I'll not do a great job at explaining it, but it is, according to the docs, a library for composing asynchronous and event based programs using the observable sequences. So an observable is not exactly, but kind of similar to, like, an event listener where you, like, say, when this thing happens, go ahead and and do this.

And you can do that with data as well, where you're you're waiting for data to come in and when it does come in, you can go ahead and and react to it. So I don't have a whole lot. I don't even know if it fits perfectly into this. But as Yarn as I can understand from the docs, it is a state management library as well.

Yeah. It's funny because when you you asked about this, I was like, do people use that for state? I mean, that's that's where I'm at with RxJS.

I don't even know what people use it for, which is kind of weird that I would even say that considering how popular it is. Yeah. It's super popular. It is popular. And I like how they say think of it as the lodash for events.

Okay? So to me, I just I don't know, what the exact way of using this is in any sort of way that, I would use it, but a lot of people seem to do, and it seems to be very popular for for various use cases. So, maybe that's a a large gap in my we all got gaps, and RxJS JS a gap in my understanding of things.

Next up is React Query. Have you seen React Query, Wes? No. I haven't. What is it? Oh, come on. Come on, Wes. What what's going on over there? No. It's a React Query. Actually, if if we wanna talk about guests, Tanner Lindsay, if you're listening to this or if you're interested in coming on the show, we gotta have Tanner on the show, because this library is fantastic, and it's a huge growing community of 8.6 thousand, stars on GitHub, and it works with a whole bunch of stuff. It's really cool.

I've I've really thought about using React Query. You can even use React Query to do things like fetch from your GraphQL API. So React Query JS, basically, it's hooks for fetching, caching, and updating asynchronous data in React.

So they basically you remember the library SWR from Vercel? So it's it's similar to similar to that.

What I've really found about this is that it it takes a lot of stuff that you know, some of the APIs might not be that crazy for us using Apollo, right, considering we just do use mutation pass in the whatever.

But they have, like, a use mutation hook that you can have yourself outside of Apollo. So, they have, like, use query, use mutation, those types of things, and it passes back the status, the data, the error, just like Apollo would in in those kind of ways, but for working without outside of GraphQL APIs. They're working with whatever you want rather than just specifically Apollo.

And the cache tools are really nice too. There's a whole bunch of stuff here, including some really, really, really fantastic dev tools. I've heard nothing but fantastic things about React Query from those of, those, who have used it.

I know, the people who who use it are are definitely very into it. Tanner JS a pretty pretty smart dude from all of the stuff that I've seen, his talks and stuff. So I I'm really into learning more about React Query right now. I wanna give it a try. I know he's doing some rewrites of it, but the examples and everything looks really nice. And one of the things I love about React Query is their documentation is, like, very comprehensive.

So it's very, very, very comprehensive. It gives you a ton of control over the cache, and it seems like it's a very smart cache for your data.

Cool. I'm gonna have to check that out for my next little project. It seems neat. The the site, SWR stuff is starting to become more tempting for me to try out as well. I would look at React Query first if I'm being entirely honest. Yeah. It's pretty cool. I'm gonna check it out.

Next one we have is I think the the rest of the episode is just things that I'm gonna say, no. I've never tried it. So I'm not gonna say, looks cool. I'll try it out.

But the next one we have is Recoil.

What is this, Scott?

Recoil is a new state library from Facebook.

It has not necessarily you know, when people say something's from Facebook, it's not like it's the same team that did React or something like that. So this is like a separate team that is solving a problem, and the problem that they were solving was that two corners of their application that were not in the same application tree needed to share some bit of state, and that was a very complex problem. Right? So their idea, ends up essentially pulling the state outside of the tree entirely, allowing you to keep track of state and have it update 2 entirely separate parts of your query tree or or your your React tree without having to do unnecessary rerenders. It's very performant in those sort of ways.

It it's nice. I I used it. I gave it a try. So I I gave it the, the good old try here. And for the most part, I found that while it was nice, it worked Wes, the API was pretty good. It was a little bit more complex than I would want for doing anything sort of basic. And to me, the use case for this in terms of, you know, application development, the the the, like, the use case that they presented in the video announcing it was sort of like you could imagine like a, like Figma or something. Right? Like, Figma has a column where 1 column has the information about, you know, a square, and then you have the square that has the information about the square and then maybe some other things that have some information about that square. And that though all of those things need to to know the information about the but the rest of the application doesn't. Right? And that to me is a very application based use case.

I would never use this in a website. I'm gonna say that straight up. I probably would not reach for recoil in the website creation business. You know, for me, I'm gonna stick to something more basic. This, to me, screams application use. So to me, I I didn't mind the API. I thought it was fine. I did think it was overkill compared to a lot of the other options on this list. So it's very good for complex splintered state.

It seems overly complex for most normal use cases.

Yeah. Interesting. I'm just looking at the the website right now. And if if you are shaking your head at, Scott just said, boxes that point to other boxes, just go to recoiljs.org, and they have a little diagram on the Node page that sorta explains

that a little bit visually. The talk too? The the video, the recoil state management for today, I thought the talk was really interesting.

Again, I I I watched the talk. I watched a couple talks. I I gave it a try. Yeah. It's pretty cool, but I I don't think I'm reaching for it, I think.

Alright. Next up is MobX.

Have you used this, Wes? Node. I haven't used this either. So I know MobX has a huge Sanity. And to prevent the mob of MobXers coming at me, I'm going to do my best not to say anything dumb about MobX.

I have not used it. There's a big community. People seem to really like it. And in fact, when recoil was announced, a lot of people were like, isn't this just MobX? But I don't I honestly don't know the, nuances of that conversation.

It's not just for React JS in you can use MobX with just about anything. There's re React versions of MobX.

It's powerful. It's like Redux powerful.

It uses so this is one thing I wasn't quite sure. Because the Docsate has observable capabilities, but I didn't I wasn't sure if it actually used observables or if it just had observable capabilities.

Maybe somebody can clarify that for us, and and we can retweet you.

Cons here is it does seem complicated. It seems complicated. It seems like there's a lot of overhead ESLint terms of understanding what's going on. Also, a ton of the, documentation as well as examples and blog posts use decorators. And I, got burned by decorators, so I'm not using them anymore. And I I I I I know you you can't you can use this without decorators, but, like, when so many of the examples are in decorators, that kind of like, I'm gonna have to translate all of the examples now to my own use case. I'm not sure. You know? Totally.

I I don't sorry. I don't know what else to say.

No. I know. Yeah. MobX seems like a good choice based on how many people are using it, but if I were to say any more than that, I would come off as being very ignorant because I just really don't know. I I've never it's too complex me to spend a ton of time into without making, like, a substantial, like, you know, stamp in the ground. It's like, I'm learning MobX today. So it's not like something you could pick apart in a day. Along with needing to do a project

in x state, I also need to do 1 in Node of these observable based state libraries because I think the reason a lot of people don't pick it up initially is because it looks nothing like the what we're used to, but there certainly is benefits to it. There's because if you take a look at how many people are using it as well as, like like, large applications, like, stuff way bigger than than I work on tend to go for these type of things. So there's clearly something to it.

Yeah. It's it's funny because, like, I'll I'll use that as, like, a barometer because, like, I don't necessarily trust myself in some of those regards. So I'll be like, I don't get Redux. It seems very hard to me, but maybe I am just done. So, therefore, let's see. There's this huge community of people using it. Perhaps I am just wrong about it. You know? And and I like to use this community side. How many people are using it? How many people say nice things about it as a barometer? Obviously, I you know, should always trust yourself, but at the end of the day, it seems like a good option for those of you who, who who find the syntax to be nice. Working with state management is tough. Bound to create lots of bugs. Lots of bugs. Right? I mean, we all work with this stuff. We all know what can happen, and that's why you're gonna need a tool like Sanity at century.io.

Sentry is one of our sponsors today, and let me tell you, they do some cool, cool stuff. Sentry is always doing cool stuff. In fact, one of my favorite things is whenever Sentry pushes out something new, I get to try it. For instance, I'm currently using their performance tools right now to track performance all over my application.

It's really good.

In fact, it's so good that I can really find out which routes have the best speed, least amount of failure rate. For instance, I have some routes on my Scott that have a 0% failure rate, which is well, all of them should be. You know? And when they don't have a 0% failure rate, that and Sentry JS gonna really pick up the pace there. They also give you a little bit of a user misery score too, which tells you when a user has waited more than an x amount of time, which I love because it gives me, like, a little progress bar to see if people are upset on various routes. And sometimes it's like, okay. This particular route was accessed by only a few people, And, sure, it took a long time for those people, but that's not indicative of the rest of the community where you can see that, a ton of users have accessed this particular route, and it's fast for them. So, it's very cool. I love these tools, and they're brand new. I think you have to turn them on by a beta flag right now. Yes. They're in beta. I definitely recommend checking them out if you have a Sentry account. If you don't, you're gonna wanna add it to Sentry.i0 and, use the coupon code Sanity treat. It's all lowercase, all Node word, and you will get access to 2 funds for free, which is more than enough time to really see everything that Sentry has to offer, and you'll really realize why it's such an industry staple at this point.

Okay. Let's keep this moving here. We don't have a ton of time, but we only have 2 more options left. And then, we're gonna give our our final thoughts on steak. This this next one, easy peasy, is called vegetarian

friendly state for React. Oh, that's fun. I wonder what makes you vegetarian, but that's good to know. Maybe they're just fans. Probably.

That's great. I'm not vegetarian, but I'm a fan of vegetarianism.

So

There you go.

So, yeah, this one, I've not used it myself, but, taking a look at it, it looks similar to Node actually no. I wouldn't say similar to Redux, but not entirely.

The way that it works is you create a store.

And in that story, you have your data types.

And in that data type, you have the actual pieces of data, which are items, and then you have, methods that are used to update it. So you can define, what your different actions are to add, remove, update, etcetera, etcetera, on your different types of data. Looks nice because it's all packed into 1, whereas it looks easy. It's called easy peasy. So it does look easy. I like these ones where, like, the updaters and the actual data live in the same place rather versus actually like Redux Wes they're all over a whole bunch of different files or or functions.

Yeah. I think ECPC was really, really built to be like, hey. We we get React Redux. We like Redux, but, like, let's reduce some of that boilerplate.

Let's reduce some of that config. Let's make it a little bit more modern. This came out right after, like, hooks came out. So I think this was, like, one of the very first, like, new style of, you know, state libraries that came out of the whole hooks revolution.

I guess you could call it a revolution, but hooks hooks addition to the application.

Next up is one that, it's funny. Wes mentioned this. I I didn't even think it to put this in here. Wes mentioned this, but this is a very legitimate option for those of you using Meteor.

Meteor has this really neat stuff called reactivedict for reactive dictionary and reactive var for reactive variable.

And, it's very simple. It works basically just like React wait. What JS it? It work like set state did Wes you basically just pass it in a key and then a value, and it just takes care of everything. And guess what? It's reactive.

And then when you use it, you just use a use tracker hook from, Meteor.

You just wrap everything in a use tracker, and you just say, hey. Give me the value from this dictionary. Alright. That's it.

So the syntax is very simple. It's basically just getting set, which is fantastic. I'm in I'm in there for that. It's, reactive without any work. You don't have to do anything to make it reactive.

The cons, however, are that you have a lock in to Meteor, which, of course, is a con because, you know, our front end Node, it shouldn't necessarily be too locked in. But, again, lock in is one of those funny things. If you're not planning on moving off a platform ever, like, do you really need to care about lock in? I don't know. I I go back and forth with this all the time. So I've been thinking about simplifying my state and maybe using something like this as a a better idea, but who knows? Final thoughts on state.

Wes, do you have final thoughts on on state? What do you think people should use? What do you use? What do you like? What what what are your thoughts here? Yeah. I I tend to go for

the simpler and sort of easier to get up and and running solutions. So that would be contacts using I'm I'm really like this easy peasy one that seems like, if I can look at an example and go, ah, okay, I I get it. Like, that makes a lot of sense to me.

Then that's those are the ones that I I like to to look at. And, of course, you can get more complicated, and they have the ability to get more complex. But if I can look at the initial, like, basic if I'm just setting a boolean to true and false, if I can just write it in a couple of lines, that's what I go for. So context, if you're doing data that's being pulled in via an API, still probably reach for context or something like Apollo as well. And that's that's where I reach for because I don't I don't work on applications that are are massive or have a team, that need to. So, I'd like to hear what you think.

Yeah. I think that maybe, I think Node that you should probably think about storing your application state separately from, like, the application data JS in, like, a, is the nav open JS, to me, like, a different set of problems than, like, is the tutorials in from the database.

So I keep that CSS separate for me, and I I don't know. That's just my thoughts on it. If if if you think differently, obviously, that's that's totally valid. I also think that for state applications, too many times, people go with the flow in terms of what other people are using. Right? They look at Redux and say, oh, everybody's using Redux. I gotta use Redux, or everybody's using this or that. There's so many options, and it's really a pro and con of React is that there is so many options, but there Yarn so many options that you can find an API for you.

There is many APIs in the sea, and you can find Node that really fits your needs and wants just based on you know, sometimes people like syntax. Sometimes people don't like syntax. Some people like, not the podcast, of course. Everybody likes podcasts. But, like, in terms of, like, robustness or or or sort of large amounts of code to do very little, some people really like that, and that's valid. And some people don't like that, and that's totally valid too. So find that API for you. You can find it out there. I'm sure it's it's it's in one of these. If it's not in one of these and if it's in another state library that just exists, tweet us out. We'll we'll give you a big old retweet there. Beautiful. I think we should we should also have somebody on the podcast at some point that explains

why you might wanna use one of these other libraries that we don't have a whole lot of information about because, we don't run into all of these problems that we that need solving, and certainly other people do. I want an RxJS

explainer episode Wes I don't have to do any work learning it myself. Alright. If somebody that's listening knows who we should have on for RxJS

episode, tweet us, and we will have them on.

Alright. That's all for today. Should we move into some sick pics? We should. Yeah. Let me get my dogs to stop barking real quick, though.

Hello? What are you doing?

Stop.

I've got a real sick pick for you right now, and it is a set of pliers that I didn't know I needed until I, I watched some, like, YouTube video.

And a lot of these these guys that are super into tools always talk about these Nipex Cobra pliers Wes, instead of the pliers being, like, straight in your hand, they sort of go to to the left or to the right. It's kinda hard. Just Google Nipex Kobra while you're listening to this. And the problem is that they are silly expensive. They're like these beautifully German made tools that are, you buy it once. You have it for your entire life. But, like, I just can't convince my wife to let me spend, I don't know, $70 on a set of pliers. So I've always been a fan of the Erwin JavaScript tools, which is weird because Erwin and Vyscript were 2 different companies in a while, but now they're just they're one. And it looks like they've knocked them off. And I saw them in Canadian Tire the other day, and I was like, 30 it Wes $30 for a set of 2. And it's really cool because they're they're a set of pliers. They're kinda like channel locks and that you can make the gripping, the radius bigger or smaller, except that they have a button that will lock them into whatever width that you want. So if you've ever used this set of channel locks, you'll know that they, like, they can slip and things like that. And also channel locks put all the pressure on, not on a tip like pliers would, but on the entire, length of the jaw. So these things are awesome and I'm never gonna use another set of pliers again because these ones are they're it just grips super well. The locking in, like, if you have to put the tool down and pick it up again, it has the same width of the jaw that you set it on before because there's a button that will allow you to to lock it in. So check it out. It's called the Erwin GrooveLock clamshell pliers.

I I don't know what that is. Just go and go to your home improvement store and and take a look at them. They're pretty nifty.

I'm gonna can you drop your

referral link in the show Node so I can get some of those? Yeah. That's a huge problem for me with Vice TypeScript specifically, you know, them changing changing widths and all that stuff. So, hey, that sounds good. I'm gonna, sip pick a a movie that's currently streaming on let's see. Where is this currently streaming? I'm using Real Good to tell. It's currently streaming on Hulu.

So I watched this on Hulu. If you have Hulu, go ahead and and watch this. Otherwise, just put it on your list to find it some other time. This is a movie called Becoming Bond. It's a documentary about the stranger than fiction, the true story of George Lazenby. Now I have always been a big James Bond fan. Since I was a little kid, I used to watch all the movies.

And, of course, George Lazenby, if you know anything about him as a person, you'll know that he became James Bond and then basically just quit after 1 movie because he essentially be he's kind of a hippie.

It's it's really, really wild life. And if you wanna if you want to really, really get a feel for how insane human lives can be, Becoming Bond is the perfect documentary because this guy's life is absolutely nuts. He was like a car mechanic, and he, you know, Wes just basically doing everything super impulsively. And he's not necessarily, like, a great guy, but he just makes these random impulsive decisions, and he lies his way all the way into becoming James Bond. It's wild. It's a very, very wild movie. And I think Courtney and I were just watching it the whole time, mouth the gate, just being like, what the heck? It's wild. He if you wanna see how far confidence can get you, that's how far confidence can get you. So a very, very cool movie.

Alright.

Shamelessly plug. I'm going to shamelessly plug all of my courses.

Bos comforward/courses Wes you can pick up beginner JavaScript or Wes six for everyone, JavaScript TypeScript thirty. They're free. They're paid. Check it out. If you wanna learn a thing or two, use the coupon code syntax for $10 off. Thanks so much. No. I'm not this is not a sponsor read. Thanks so much to myself for making these courses.

Thanks, Isel. Thanks, myself, for for sponsoring this episode. I would also like to, shamelessly plug my own things, which is going to be my latest course is modern CSS design systems, where we use CSS variables to build a design system starting at classless CSS, just really just writing your CSS just without classes first and foremost to get a nice little base in there, writing a ton of CSS variables, and how you can use CSS variables to really make some really super slick CSS stuff happen. So check it out at leveluptutorials.comforward/ pro. Sign up for the year and save some cash.

Awesome. Thanks so much for tuning in, and we'll catch you on Monday.

Peace.

Drop a review if you like this show.