Software engineer Pierre Hedkvist joins the React Round Up panelists to share some spicy (controversial) coding decisions he's made and then written about. The first hot topic is using React state to store filter setting in query parameters with the help of a custom Hook, and the second is migrating an app to rely more heavily on React Query instead of Redux.

If you've been considering doing something similar, give this episode a listen to hear Pierre's strategies and advice for anyone looking to get started.

Hey everybody and welcome to another episode of React Roundup. I am your host today, TJ Vantolle, and with me on the panel I have Jack Harrington

 

Hello.

 

and Paige Niedringhaus.

 

Hey everyone.

 

And our special guest today is Pierre Hegfest. Oh man,

 

You tried,

 

I need to

 

you,

 

get him.

 

you,

 

I

 

you

 

gave it

 

know,

 

a good go.

 

yeah.

 

So Pierre, welcome to the show. Maybe you can also pronounce your name for us and tell us a little bit about yourself and who you are and such.

 

Yeah, thanks for having me. My name is Pierre Hedkvist. Yeah, it's a Swedish

 

Hehehe

 

last name. So it's a bit hard to pronounce maybe. But yeah, I've been a developer for, yeah, like four years or so, working as a consultant for various types of clients. And yeah, but I've been like a web developer for the past 10 years. Yeah. And yeah, I just enjoy creating websites and working with clients and coming up with cool solutions. Yeah, so that's a short introduction.

 

Awesome. Well, so we reached out because you've got a couple of interesting blog posts that I know we want to talk about. You've got a kind of spicy one on migrating from Redux to React Query that I know we want to dig

 

Oh

 

into

 

yeah.

 

here in a minute. But why don't we start? You have a recent article that I think is kind of interesting about storing state in the URL,

 

Mmm.

 

which is kind of a fascinating idea. So maybe we could start with that one. And could you just give like the high level overview for our listeners? Like What sort of brought this problem about? Why would you want to store a statement URL? Maybe you could just sort of explain how all of that works.

 

Yeah, sure. So typically in websites, you might have like different forms or like filters that you want to filter some content. And the idea is if you have a complicated like filtering system, you want to make sure that the user can send maybe like a link from. a certain page to a colleague who can then open the same kind of web page and see sort of the same or like and get the same kind of filter settings. So that's

 

Oh yeah, I literally did this

 

yeah.

 

just last week. So what was the methodology you used?

 

So in our

 

So

 

project.

 

what was the methodology?

 

We made a React hook, basically, that will synchronize between the URL, like the query parameters that's in the URL, with a state. So it's essentially what we created was a custom hook that functions similarly to a useState hook, but then it also synchronized the state with the URL. And yeah, so there

 

interesting.

 

are some things you have to think of there, like synchronizing the kind of key and value with the state and the URL.

 

Mm-hmm.

 

Yeah, so like no users can like just put in an arbitrary value and that will mess up your application. So you have to do some like input sanitation and things like that as well.

 

Uh huh. So

 

Nice.

 

when you were working on this, did you ever encounter the URL limit? Because I know that that is something that if you put too, I don't remember what the number is, but if you put too many things into a URL query or parameter, it is just too long for the browser to handle. So did you have to did you hit that limit at any time or have to work around it?

 

No, because the kind of our use case didn't have that many query parameters, like only a handful of those.

 

Mm-hmm.

 

So in our case, we never reached that kind of limit. But I do think that limit is quite high anyway. But yeah, definitely that's a good idea to think of if you have like a really big, like huge filter settings. Yeah.

 

Lots of filters.

 

Yeah, yeah, I think it's around 2k actually

 

It's

 

Yeah,

 

so

 

massive.

 

I was, I just Googled it and I was looking around and it takes you to this Stack Overflow post that's 14 years old. It's probably,

 

HAHAHAHA!

 

it's probably probably in the billions of page views, but it yeah, it basically says like 2000 some characters is the like unofficial limit that basically everything supports and then it gets into like. crazy town of browser behavior, because it's not like a standardized thing.

 

Yeah,

 

So

 

yeah.

 

if you're above 2000 characters, maybe consider switching your approach up.

 

Right, either that or like make a GUID, use some API, and then store off the state on a server with that GUID, and then bring that back in. You

 

Yeah.

 

can do that if you want to have more of a like persistent thing that has a larger set of data on it.

 

Mm-hmm. So Jack, maybe, or sorry, not Jack, but Pierre, maybe you could elaborate a little bit on how you made sure that the use state hook that you created was always in sync with the query params. Was there some sort of a use effect that it was using to watch the query parameters, or was there some other way that you were making sure that it stayed in sync at all times?

 

Yeah, great question. So we used useEffect to make sure that when the query parameters change, the state value changes. So this can happen when a user, you know, like goes back in history. So they go back

 

Mm-hmm.

 

in history, then your query parameters might change, and then you need to sync your state in the UI. And the same thing can happen when they go forward in the browser history. The query parameters might also change. So you definitely need to sync both from when the query parameters change because of the browser or when the user changes some kind of filter. Yeah.

 

That can be a tricky problem because you got that like observer loop there, because if you if you got the state and you got the your hook, which is observing the URL is both setting and also responding to your changes, you can get into a nasty little loop there if you don't watch out. I've certainly done that myself.

 

I'm sorry.

 

How do you end up avoiding that?

 

That's a great question. On top of my head, I think we just checked like if the value itself changes,

 

Okay.

 

then we update the state. So I mean if the value stays the same, even though you go back in history, we don't update it, right? Yeah, but I don't think we

 

Okay.

 

ran into a problem with that. sense. Because we always check that if the value changes then we update the state, but otherwise not.

 

Mm-hmm.

 

If that makes sense.

 

Makes sense, yeah, totally.

 

Pierre, any other notes or thoughts on that related to changing the URL that we haven't hit on that you wanted to talk about before we move on?

 

Sure. So what we did was we also had like two functions that you provide to this special hook that we created. And one of them is a serialize function. So this will take that state that we send into the hook. And it will serialize it so it fits in the URL. So imagine sending in a Boolean value. to the URL parameters. How would you go about doing that? So the serialize function can take whatever state you have, like a Boolean, and then you can tell the hook how that should be represented, the value, how the value should be represented in the URL. So because the URL

 

Gotcha.

 

parameters can only be string values, so if you pass in that Boolean, you can just send

 

Mm-hmm.

 

like a true string or something or a false string, yeah.

 

Yep, makes sense.

 

ja sitten toinen kohdalla.

 

Cool stuff, and we'll make sure to link to your.

 

Yeah, just the other way around when you have the de-serialize function, then you tell you, you get the, you do the other way around where you, you check what kind of values in the string and then turn it to the appropriate value in the state, so to speak.

 

cool.

 

Awesome. We will make sure to link that up. Like you said, I think this pattern is pretty common around just e-commerce, any sort of site where you need to filter or

 

Oh

 

search

 

yeah.

 

for things. I see it all the time. So we'll make sure to include that in the notes if our listeners want to check that out. The other article that I know we want to talk about is moving from Redux to React Query, which is, I think, kind of interesting and probably really pertinent for... I don't know for like us, if nothing else, but probably some people listening to this as well. So.

 

you know, reDex is slowly slightly popular.

 

Uh, yeah, that's only

 

Yeah.

 

a couple of people using these, these

 

Right.

 

frameworks.

 

And

 

Yeah.

 

react query, yeah.

 

Yeah.

 

Oh, right. Yeah, exactly. I have to do the NPM trends. Look at the two. Let's see how those go.

 

Yeah. So, Pierre, maybe you could start by just giving us an overview of why you decided to make the switch, how you went about it. Maybe you just start by giving us the high level bit and then we can dive into a little bit of the details.

 

Yeah, sure. So I think the reason why we started looking at React Query was because a colleague in my company had like a presentation about React Query when it sort of first came out, like maybe two years ago or something. And we thought this was really nice and neat how React Query does a lot of things for you that you have to do manually yourself with. Redux. And in my project that I was working on at the time, we had like a really messy Redux implementation using a strange pattern called Redux ducks. Yeah, it was really messy

 

Oh, the

 

in

 

duck

 

the whole

 

pattern.

 

Redux. Yeah, it was super messy. And it didn't really fit our application that well. We had like dashboard application that would change or get updated in real time. So we would have, you know, we would want to display kind of values that would sort of update in the background continuously. And I think React query is a great way of achieving that kind of real time effect. Not necessarily like super real time, like if you've used WebSockets, that's like more. real time, but we wanted to keep the client in up to date. So when you kind of change between views, the state gets updated. And even if you stay on the same page, the state should

 

Mm-hmm.

 

be updated after a few minutes or so. Yeah.

 

Well, you can put all kinds of stuff in React query, but I mean, React query is primarily for doing like queries and mutations, which is just part of what you do in a Redux store, I guess.

 

Mm-hmm.

 

The question is, like, what did you do with the rest of the state? Did you just use basic React hooks for that? Or what's the, tell us about that migration strategy.

 

Yeah, so essentially the pattern that we had was we kind of threw everything into Redux. Like even like when you would fetch some simple

 

Meh.

 

data that would be displayed in like one page, we threw it into Redux and it felt, I

 

Haha

 

don't

 

Oh yeah,

 

know,

 

the Mega

 

really

 

Mega

 

unnecessary.

 

Store. That's a classic.

 

Yeah.

 

Oh

 

Yeah, exactly. You just throw everything

 

yeah.

 

into Redux and you have to write so much boilerplate code for everything and it's

 

Hey

 

at some point you're like, wow,

 

Yeah

 

what am I doing with my... What am I doing with my days? Like sure you can build your clients

 

I

 

more,

 

just...

 

I guess, but the code base kind of stinks. Yeah.

 

Mm-hmm.

 

So the,

 

Yeah.

 

I think React, yeah, so the strategy was we kind of took the simplest page that would just fetch data for that particular page. And instead of

 

Mm-hmm.

 

putting that into the Redux store, we used React query. So we would try to find the most simple place where we can just remove the Redux implementation and then just put React query. And then slowly but

 

Mm-hmm.

 

surely take the kind of more difficult parts of the application where, let's say you had some state that was being used in several pages, then you would need to kind of, it would require more changes to have the React query as well. And

 

Mm-hmm.

 

so yeah, just step by step and trying to figure out when we needed a global state versus something a bit more simple. So we still

 

Yeah.

 

have a global state for, and then we use Redux, but for many other parts of the application we use React query instead.

 

Okay, so you just realized or you kind of made the decision that we don't actually need to store this stuff in our Redux store going forward. We'll just take it out, make the API call for this particular data whenever we need it and kind of try and minimize the use of Redux.

 

Yeah, exactly. So you can think of some kind of state needs global state management. So if a user is signed in

 

Mm-hmm.

 

or not, that kind of state needs to be accessible throughout the application. Perhaps you want to display a username in various places throughout the application. So

 

Mm-hmm.

 

it makes sense in that scenario to have a global state. But for many other. things react query is might be a better option.

 

So now that you are using React query, are there any features of React query you were able to start using right away? Or was that part of the reason to migrate is to get just to do some things that weren't really possible with Redux?

 

I would say you can probably do everything that you can do with React query, you can do with Redux, but you might have to do it yourself. And it's like a trade off between how much time and effort you wanna put into that, versus taking something that's already been implemented and yeah, get on with building other things. So, but some things that

 

Hahaha.

 

we really liked with React query is, that you can put some settings into the query. So you can invalidate certain data after maybe even just a few seconds. So, and then you can like continuously pull data and refresh, let's say you have a dashboard application and you want to kind of show like data that's quite fresh. Then you can adjust the in validation setting. So it fetches data, let's say, once every 30 seconds or something like that. So even if you sit as a user and just look at a dashboard, you don't navigate away. You just sit there and look at your dashboard. Then we can, in the background, make sure that the data gets updated in the client. So that made a lot of sense for us. Yeah.

 

Well, heaven

 

Yeah,

 

forbid

 

I have

 

that

 

to...

 

I... I'm sorry.

 

Oh, go ahead, Jack.

 

Well, I haven't forbid that I come to the aid of Redux, but I will say that the Redux toolkit that's come out has significantly reduced the amount of boilerplate. So there's that. And then also there is a query built into Redux toolkit now, which is roughly the analog of react queries. So for those folks who are now screaming at their cell phones like, you guys Redux does all this stuff. Yeah, absolutely. If you want to stick with Redux, please use the Redux toolkit. It is phenomenal, honestly, it's great.

 

So question for you, is that something that you can either migrate to or integrate with an existing Redux application? Or is it is it kind of like you have to migrate everything into this new Redux toolkit framework or library?

 

That question for me?

 

Uh-huh. Heheheheh.

 

Oh, yeah. Oh, OK. Yeah, no, actually, it's totally compatible with older, older, I guess, reducers and all of that.

 

Yeah.

 

You know, it will handle that.

 

Cool.

 

And then for newer ones, you can make newer slices based on its its simplification of stuff. But yeah,

 

Yeah, because

 

I think.

 

it's great when everybody says, oh, this new library or this new framework can do it. But it's like if I've already got the existing one, can it work with what I have or do I have to just, you know, throw it away and start over?

 

Yeah, I mean, we've had Mark on the show and he's a great guy and you know, it's

 

Yes.

 

the yeah, it's a it's a phenomenal library. It's hard to disagree with that, but it has a past of like the mega stores and people are like, oh, oh, god.

 

Mm-hmm. Yeah. Yeah, and I have

 

Yeah,

 

to agree

 

and

 

with

 

I

 

you,

 

think.

 

Pierre. The... Go ahead.

 

Yeah, I would also say like, I think it also depends on the application and the code base that you're working with. Like some have implemented Redux very well and they've used kind of good tools around Redux that makes it super nice to work with. So I'm not anti-Redux by any means, but just happened that I was in this project where the implementation of Redux was just super messy. And yeah, we thought React query would be a good fit for that project. But I've seen now that there's the Redux ecosystem has like improved over time. So I agree with what you're saying.

 

Do you have any other tips on the migration path? Did it go super smoothly? Did you have like an attack pattern for how, I don't know how big the app you worked on is, but I know those sorts of migrations for even medium sized apps can be rough, I guess is one way of saying it. So I'm curious how that went and if you have any tips for that process.

 

Yeah, sure. So I think we did this in the span of a few months. So yeah, maybe six months or so, but

 

Hmm.

 

it was kind of a small project. It was only me and another developer. So like, so we tried to combine like feature development with refactoring some, some of this state management stuff. And so, so I think the strategy part is just try to find the most simple kind case in your application where it would be the easiest to change. And then like, just evaluate, is this good for us? And like, do we, is this beneficial for us or not? And then if you do think it's a good thing to continue with this, then just, yeah, just keep trying with those simple cases and take the sort of bigger change, like changes. like when you've gotten some experience. Yeah, so that's my strategy that we had in that project. And it worked quite well for us because after a few months of doing this, we realized how to structure the application such that it works well for our use case.

 

What was your testing strategy? I mean, did you have a robust kind of unit test or end to end test suite that at least you'd know if you mess something up?

 

Yeah, so in this particular project, we didn't have either of those. We kind of manually tested everything. So,

 

Whoa, whoo,

 

yeah.

 

exciting.

 

Hahaha

 

Yeah, so I mean, it was kind

 

Livin'

 

of

 

on

 

a

 

the

 

smaller

 

edge.

 

project. It was a smaller project in that sense.

 

Okay.

 

Like now we do have some end-to-end testing in that project. But, yeah, we did not have a... like unit testing suite or something like that. But yeah, definitely that's a good idea to have like React testing library or something like that. So you just test everything before and after

 

Yeah,

 

and make sure.

 

I mean, I think when I go into

 

But.

 

refactoring, like job number one is to like, make sure that you have all of the test set up so that like if you break something, you at least know, like you can even

 

Mm-hmm.

 

like make sure that the test test for the bad results, because, you know, that's some times that folks are expecting.

 

Yeah, exactly.

 

Piers, is there anything else related to the migration that we haven't touched on? Anything else you learned from doing it? I guess another question I have too is did you consider any of the other 57 options that are out there for state management in React? I'd be curious even some of your reasons for not picking some of the other alternatives that are out there as well.

 

Um, yeah, so I do, if I remember correctly, there's something called SWR, which is, um,

 

Mm-hmm.

 

Yeah,

 

similar

 

that's a good one.

 

sort of, um, library. It's like, I don't know, I would say it's almost the same as React query. Um, so I think at the time it felt like React query was the more robust version of the two, it had more features. And so I think those were our two options. Um, but we thought Reactware made more sense for us. Yeah.

 

How about in terms of like state management? Did you have a look at anything like zustand or recoil or any of those?

 

Mm-hmm.

 

At the time of doing this migration that was maybe one and a half years ago, so I don't think Soustand was quite

 

Oh,

 

as

 

okay.

 

popular as it is today. So yeah, we kept with Redux in that project. Yeah, but it seems like Soustand has gotten a lot of traction right now. So, but it's nothing I've worked with so

 

Cool.

 

far.

 

Yeah, it's definitely on the ascendancy for sure. Yeah, for those playing the home game that it is kind of like a redux, but less boilerplate-y and, you know, if Pierre you mentioned like storing just like who the user is or things like that. You know, that's the kind of thing that Z-U-S-T-A-N-D is very good at.

 

Awesome.

 

So if you were going into a new project today or taking one on peer, what would your recommendations be for somebody who maybe was just getting set up? Would you still say that they should start with Redux? Would you just start with React query? Would you not use any of that and just go straight for the React framework? What are your recommendations after having dealt with both all and some?

 

Yeah, great question. So I think it's all about the application and what your needs are. So I mean, if you're just starting on like a hobby project, like maybe it's easier to just use the use state hooks that React provides. But if you're, let's say you're building like a full blown application with, you know, user state where you kind of have to access the user state on multiple pages, then you need to have a global state. manager or at least it makes it easier. And you can use kind of a context state, I guess, or Redux or Soustand. But I'd say for me, I think React query is an excellent choice for keeping your state fresh on

 

Mm-hmm.

 

different pages. So when you kind of. Like browse between pages. It will make sure that the data is always sort of the latest data. And it will kind of handle a lot of things for you. So you get things for free, which is super nice. So if a user kind of sits on a particular page for, or I don't know, several hours, they will still see kind of up-to-date data to some extent. They will not see several days old of data or something, if that makes sense.

 

Yeah, I've got

 

Hehehehe

 

to say the, the polling that React query provides has been such a good thing for some projects that I've been working on lately where it is we've got like a dashboard page, but there's new data coming in from the back end regularly and being able to update that without having loading spinners or asking the user to refresh the page and just seeing the values update is. awesome and not having to use like some kind of a Pub Sub model or SAS service or something like that is great. I really, that's one of my favorite things I think about React query right now.

 

Yeah, that refetch interval

 

Yeah,

 

is just

 

I agree.

 

so easy. It's just, refetch. Okay. Cool.

 

So Pierre,

 

Yeah, exactly.

 

another thing we like to get into the show, another thing we like to talk about on the show sometimes is content creation, because we have a lot of listeners who are considering getting into creating their own stuff, putting it out there. So I'm also curious what inspired you to write these up and put these out there, these posts.

 

Yeah, sure. I think writing is a great way of formalizing what you've learned. So if you've learned a new tool or if you've come across some kind of problem that you had to solve in some particular way, then writing an article around it kind of helps you just like showcase what you've learned and what steps you took to solve whatever problem you had at the time. And I think that's quite enjoyable. And yeah, it's a great way to showcase your skills in general. And just posting your articles on, I don't know, Reddit or Hacker News, seeing that someone kind of enjoyed reading your article is, I mean, that's really nice. Yeah. And

 

Hehehehe

 

in general, when you're like applying for jobs or something, it's quite good to have a few posts that kind of showcases that you've thought deeply about certain topics. So I think you just have to start somewhere. And even if you like your first few blog articles aren't that good, then you will. Yeah, you will get better over time and just enjoy the process, I guess. Yeah. and try to improve your writing. And that's something I've had to do quite a lot. Just try to improve my writing skills since English is my second language. But yeah, it's super fun. I highly recommend it.

 

Yeah, we are definitely big fans of that. Longtime listeners know that we are, we are big proponents of doing the same. It's amazing how things like that can open doors for you that you wouldn't

 

Oh yeah.

 

have expected. So.

 

Mm-hmm. Do you have any advice that you would give to people who are just getting into writing potentially about how to pick topics? And it may be like how to narrow down topics, because talking about a migration is, you know, could be a very long or multi-piece article. So how do you kind of decide how big or how large the scope of of your articles are going to be, or what advice do you have for keeping that to not be a novel?

 

Hahaha

 

Yeah, I mean, I think you have to like try and put yourself in the reader's position and like, do I want to read about all the details of everything that was kind of being done in this migration process? Or do you want to see kind of the high level steps that you took and maybe you want to read about like why this migration was important in this? context and these things. So, I mean, for sure you can have like a few blog posts about this process, or you can just have a shorter article about it. And I think it's either or it makes sense. I don't think there's like one true answer for this. Yeah.

 

Yeah, it's a hard one to have general knowledge or general advice for, because it matters so much in the context. Cause I know when I'm looking for information online, I'm usually in one of two modes, the one is if I'm having a very specific problem, like I'm getting this air and I need to know what to do.

 

Yeah. Hahahaha!

 

I want the shortest article humanly possible. Like this is, I think that's what makes like stack overflow so good. Right. Cause you just get. You're just you really do just want the one sentence answer or the one thing to run to fix your problem. Which is fine. But that's something to keep in mind when you're writing. If you're writing like a solution to a problem, you want to start by just like giving the answer and then like any background or stuff sort of after that. But for articles like yours with migrating, well, that's the sort of article that you you would look into if you're considering like a really big time investment for. your company or your organization or whatever. So in that case, like that detail is kind of what you want, right? You want somebody who's went through that because you're potentially about it to invest months worth of time into something. So getting a detailed, nuanced account of how it went is probably what you're looking for if the person's reading that. So those are like the two extremes, right? In the tech world. And depending on the topic, you might be somewhere in between there.

 

Yeah,

 

Well,

 

I

 

period,

 

agree.

 

is there anything we've...

 

Go ahead.

 

Is there anything we we've missed? Any other articles of yours that you want to discuss? Anything else that you wanted to talk with us today?

 

I think that's enough for now. I think it was interesting to talk about these two topics with you. And yeah, hope you enjoyed it.

 

Excellent.

 

Oh yeah.

 

Well, we will definitely link those up in our show notes. So, uh, see people can check those out, but why don't we move into our picks and page. Do you want to kick us off today?

 

Sure, I will kick us off with a hardware pick actually.

 

Hmm

 

So for those of you who are newer listeners, I work, TJ and I actually both work for a company that does Internet of Things hardware. And one of the things that we get to do as part of our job is build different projects that show off how you can use our hardware. And some of them are more involved where you need to actually do some soldering, some are less involved where you can just... you know, put things into a breadboard or quick connector them together. Um, but this past week, and Jack is more familiar with this because he follows me on Twitter, I learned

 

Oh

 

to

 

yeah.

 

do some new soldering with, um, soldering two wires together, which was a new one for me. I'd mostly been soldering, you know, pins to breadboards and things like that. Um, so there was, uh, an awesome YouTube channel, which I basically learned how to do everything from stripping the wires, twisting them together, soldering them, and then even adding a heat shrink wrap to the soldered piece afterwards to protect the newly soldered joint. And it's called Chris Fixes on YouTube. And it was in one video I learned to do all of this and it was, you know, 15 minutes long. It was very well laid out. He had really great close-ups on the soldering itself, showed you how to do it with a soldering gun, showed you how to do it with just the soldering iron that you hold. So it was everything that I needed in one and I really appreciated that and will definitely be looking back to his channel in the future when I come across new soldering things that I need to do and have not learned yet how to do. Um, so I'm going to recommend his channel as a great place. If you need to get started with hardware or you just want to, you know, fix something that's loose in your car or your house

 

Hahaha

 

or whatever. Um, cause he, he definitely does a really great job of giving you all the information and showing you exactly how it works.

 

Excellent. Cool stuff. Jack, do you want to go next?

 

Sure. Well, my sister-in-law has been in town with us for like the last five weeks and we got done watching The Lord of the Rings and also House of the Dragon. And,

 

Hehehe

 

you know, we needed an amuse-bouche, an aperitif to like a palate cleanser. And we ended up rewatching all of the Lord, the original Lord of the Rings. And that was just so wonderful and such a Big shift, I would say, from the tone of certainly House of the Dragon.

 

Thanks for watching!

 

Hahaha

 

But yeah, it was great, you know, and those are actually really, really great films. And, you know, they'll give you the give you all the feels.

 

I feel like my kids are about to turn 12 and I feel like they're at the age where they could take on the books and or the movies

 

Oh yeah.

 

Yeah.

 

at this point. And I've been meaning to, I read the books probably when I was their age, like years

 

Mm-hmm.

 

and years and years ago. So

 

Mm-hmm.

 

I feel like I need to make another. I like with book series like that, I like to wait long enough that I've lost all the details. Like I remember the overarching plot, but like all the details are gone. So it kind of really is reading it for the first time.

 

Mm-hmm.

 

somebody had to check it out.

 

Yeah, and those movies hold up surprisingly well for when

 

Oh

 

they

 

they

 

were

 

do.

 

made.

 

Yeah.

 

Jack, I do need to know though, House of the Dragon, what is your review? Like

 

Woo!

 

the like

 

Thumbs

 

15

 

up!

 

second review.

 

Big thumbs up. But wow. I mean, I really feel like they've got in the writers room. They have like every episode, they're going to have the thing that's never been on TV before that everybody's going to talk about

 

Okay.

 

afterwards. And yeah, that, you know, episode 10 definitely. Wow. They.

 

All right, I haven't seen it yet, but we'll need to watch

 

Went

 

through

 

full

 

that. It's

 

release god

 

just.

 

on that one. Hey, Paige, have you seen it?

 

No, I'm waiting for

 

Oh,

 

it

 

wow,

 

all to

 

okay.

 

come out as well and then I'm just going to binge it.

 

Okay, what's all out?

 

Oh, well.

 

Go, go, go. It's a

 

Yeah.

 

whoa. It's whoa, whoa, whoa.

 

All right. My pick on a lighter note is the Magic Puzzle Company. So my wife is a big jigsaw puzzle person, and this was recommended to me by one of Paige and mine coworkers. And it's a fun little concept because it's just a puzzle in a sense, but they have like little Easter eggs in the puzzle. And they also have a surprise ending, which I'll put in air quotes. The puzzle comes with this like secrecy seal that says don't open this until you're done with the puzzle. And so something about that concept, I think is just really cool. And we haven't, my wife's the puzzle person, so she's, she's going to put this together, but I'm going to be curious about checking that out. So if you're into that sort of stuff, uh, you might want to look into it. It's just the magic puzzle company and they have, they have a bunch of them. So I don't even know which one I got, but all of them have the same, same basic feel and concept.

 

I love puzzles, so I'll definitely be checking that out.

 

I might pick it a second time or give everybody an update after it gets put together.

 

Yes.

 

Awesome. Pierre, do you have any picks for us?

 

Yeah, I might not have that super fun fix, but more on the developer side, something that's been interesting for me over the past few years is kind of how to create like multiplayer experiences on the web. So.

 

Oh, interesting.

 

Yeah, so there's a few companies that are trying to make it easier for developers to create these multiplayer experiences. So I would give a shout out to LiveBlocks. It's a company that makes it easy for you to create a kind of multiplayer experience on your web app. So you can think of

 

Cool.

 

creating some mini version of Miro. like the whiteboard application where multiple users can create,

 

Hmm

 

yeah, just post-it notes and whatnot. But you can also add that to your application and then have multiple cursors showing up on your page and people can work together. So I think that's an interesting topic of mine. And there's also some open-sourced version of this, which is called YJS. which I would

 

Hmm

 

recommend if you ever want to create a collaborative or add a collaborative text editor into your application, or if you want to kind of sync more kind of complicated data between multiple users in real time.

 

Excellent. It looks like it's the letter Y too, because I started by searching WHY, but that's not it. So it's letter YJS. So if you're actively Googling this like me, that's what you're going to want to search for. But very cool. These types of apps are always are really, really fun. And they're all, if you don't use a tool, they're an absolute nightmare. So.

 

Hahaha.

 

Yeah.

 

Well, thanks, Peter. This has been awesome talking with you today. Last question for you, if people want to follow you and such, what is the best way to do that?

 

Yeah, you can follow me on Twitter at peerheadquist. And then, yeah, I'm on other social media, but you can also find me on my website, peerheadquist.com.

 

Thanks.

 

Excellent. All right, well, I think that is all we have today. So thanks everybody for joining us. And this has been another episode of React Roundup.

 

See you

 

All right,

 

next

 

see

 

week.

 

you guys next time.

 

Thank you.