Tj_Vantoll:
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
Jack_Herrington:
Hello.
Tj_Vantoll:
and Paige Niedringhaus.
Paige_Niedringhaus:
Hey everyone.
Tj_Vantoll:
And our special guest today is Pierre Hegfest. Oh man,
Jack_Herrington:
You tried,
Tj_Vantoll:
I need to
Jack_Herrington:
you,
Tj_Vantoll:
get him.
Jack_Herrington:
you,
Tj_Vantoll:
I
Jack_Herrington:
you
Tj_Vantoll:
gave it
Jack_Herrington:
know,
Tj_Vantoll:
a good go.
Jack_Herrington:
yeah.
Tj_Vantoll:
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.
Pierre_Hedkvist:
Yeah, thanks for having me. My name is Pierre Hedkvist. Yeah, it's a Swedish
Tj_Vantoll:
Hehehe
Pierre_Hedkvist:
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.
Tj_Vantoll:
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
Jack_Herrington:
Oh
Tj_Vantoll:
into
Jack_Herrington:
yeah.
Tj_Vantoll:
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,
Jack_Herrington:
Mmm.
Tj_Vantoll:
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.
Pierre_Hedkvist:
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
Jack_Herrington:
Oh yeah, I literally did this
Pierre_Hedkvist:
yeah.
Jack_Herrington:
just last week. So what was the methodology you used?
Pierre_Hedkvist:
So in our
Jack_Herrington:
So
Pierre_Hedkvist:
project.
Jack_Herrington:
what was the methodology?
Pierre_Hedkvist:
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
Paige_Niedringhaus:
interesting.
Pierre_Hedkvist:
are some things you have to think of there, like synchronizing the kind of key and value with the state and the URL.
Paige_Niedringhaus:
Mm-hmm.
Pierre_Hedkvist:
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.
Paige_Niedringhaus:
Uh huh. So
Jack_Herrington:
Nice.
Paige_Niedringhaus:
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?
Pierre_Hedkvist:
No, because the kind of our use case didn't have that many query parameters, like only a handful of those.
Paige_Niedringhaus:
Mm-hmm.
Pierre_Hedkvist:
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.
Paige_Niedringhaus:
Lots of filters.
Jack_Herrington:
Yeah, yeah, I think it's around 2k actually
Paige_Niedringhaus:
It's
Tj_Vantoll:
Yeah,
Jack_Herrington:
so
Paige_Niedringhaus:
massive.
Tj_Vantoll:
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,
Jack_Herrington:
HAHAHAHA!
Tj_Vantoll:
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.
Jack_Herrington:
Yeah,
Tj_Vantoll:
So
Jack_Herrington:
yeah.
Tj_Vantoll:
if you're above 2000 characters, maybe consider switching your approach up.
Jack_Herrington:
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
Paige_Niedringhaus:
Yeah.
Jack_Herrington:
can do that if you want to have more of a like persistent thing that has a larger set of data on it.
Paige_Niedringhaus:
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?
Pierre_Hedkvist:
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
Paige_Niedringhaus:
Mm-hmm.
Pierre_Hedkvist:
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.
Jack_Herrington:
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.
Paige_Niedringhaus:
I'm sorry.
Jack_Herrington:
How do you end up avoiding that?
Pierre_Hedkvist:
That's a great question. On top of my head, I think we just checked like if the value itself changes,
Jack_Herrington:
Okay.
Pierre_Hedkvist:
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
Jack_Herrington:
Okay.
Pierre_Hedkvist:
ran into a problem with that. sense. Because we always check that if the value changes then we update the state, but otherwise not.
Paige_Niedringhaus:
Mm-hmm.
Pierre_Hedkvist:
If that makes sense.
Jack_Herrington:
Makes sense, yeah, totally.
Tj_Vantoll:
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?
Pierre_Hedkvist:
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
Tj_Vantoll:
Gotcha.
Pierre_Hedkvist:
parameters can only be string values, so if you pass in that Boolean, you can just send
Paige_Niedringhaus:
Mm-hmm.
Pierre_Hedkvist:
like a true string or something or a false string, yeah.
Tj_Vantoll:
Yep, makes sense.
Pierre_Hedkvist:
ja sitten toinen kohdalla.
Tj_Vantoll:
Cool stuff, and we'll make sure to link to your.
Pierre_Hedkvist:
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.
Paige_Niedringhaus:
cool.
Tj_Vantoll:
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
Jack_Herrington:
Oh
Tj_Vantoll:
search
Jack_Herrington:
yeah.
Tj_Vantoll:
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.
Jack_Herrington:
you know, reDex is slowly slightly popular.
Tj_Vantoll:
Uh, yeah, that's only
Jack_Herrington:
Yeah.
Tj_Vantoll:
a couple of people using these, these
Jack_Herrington:
Right.
Tj_Vantoll:
frameworks.
Paige_Niedringhaus:
And
Jack_Herrington:
Yeah.
Paige_Niedringhaus:
react query, yeah.
Tj_Vantoll:
Yeah.
Jack_Herrington:
Oh, right. Yeah, exactly. I have to do the NPM trends. Look at the two. Let's see how those go.
Tj_Vantoll:
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.
Pierre_Hedkvist:
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
Jack_Herrington:
Oh, the
Pierre_Hedkvist:
in
Jack_Herrington:
duck
Pierre_Hedkvist:
the whole
Jack_Herrington:
pattern.
Pierre_Hedkvist:
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
Paige_Niedringhaus:
Mm-hmm.
Pierre_Hedkvist:
be updated after a few minutes or so. Yeah.
Jack_Herrington:
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.
Paige_Niedringhaus:
Mm-hmm.
Jack_Herrington:
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.
Pierre_Hedkvist:
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
Jack_Herrington:
Meh.
Pierre_Hedkvist:
data that would be displayed in like one page, we threw it into Redux and it felt, I
Paige_Niedringhaus:
Haha
Pierre_Hedkvist:
don't
Jack_Herrington:
Oh yeah,
Pierre_Hedkvist:
know,
Jack_Herrington:
the Mega
Pierre_Hedkvist:
really
Jack_Herrington:
Mega
Pierre_Hedkvist:
unnecessary.
Jack_Herrington:
Store. That's a classic.
Paige_Niedringhaus:
Yeah.
Jack_Herrington:
Oh
Pierre_Hedkvist:
Yeah, exactly. You just throw everything
Jack_Herrington:
yeah.
Pierre_Hedkvist:
into Redux and you have to write so much boilerplate code for everything and it's
Tj_Vantoll:
Hey
Pierre_Hedkvist:
at some point you're like, wow,
Jack_Herrington:
Yeah
Pierre_Hedkvist:
what am I doing with my... What am I doing with my days? Like sure you can build your clients
Tj_Vantoll:
I
Pierre_Hedkvist:
more,
Tj_Vantoll:
just...
Pierre_Hedkvist:
I guess, but the code base kind of stinks. Yeah.
Paige_Niedringhaus:
Mm-hmm.
Pierre_Hedkvist:
So the,
Jack_Herrington:
Yeah.
Pierre_Hedkvist:
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
Paige_Niedringhaus:
Mm-hmm.
Pierre_Hedkvist:
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
Paige_Niedringhaus:
Mm-hmm.
Pierre_Hedkvist:
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
Paige_Niedringhaus:
Mm-hmm.
Pierre_Hedkvist:
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
Paige_Niedringhaus:
Yeah.
Pierre_Hedkvist:
have a global state for, and then we use Redux, but for many other parts of the application we use React query instead.
Paige_Niedringhaus:
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.
Pierre_Hedkvist:
Yeah, exactly. So you can think of some kind of state needs global state management. So if a user is signed in
Paige_Niedringhaus:
Mm-hmm.
Pierre_Hedkvist:
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
Paige_Niedringhaus:
Mm-hmm.
Pierre_Hedkvist:
it makes sense in that scenario to have a global state. But for many other. things react query is might be a better option.
Tj_Vantoll:
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?
Pierre_Hedkvist:
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
Jack_Herrington:
Hahaha.
Pierre_Hedkvist:
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.
Jack_Herrington:
Well, heaven
Paige_Niedringhaus:
Yeah,
Jack_Herrington:
forbid
Paige_Niedringhaus:
I have
Jack_Herrington:
that
Paige_Niedringhaus:
to...
Jack_Herrington:
I... I'm sorry.
Paige_Niedringhaus:
Oh, go ahead, Jack.
Jack_Herrington:
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.
Paige_Niedringhaus:
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?
Jack_Herrington:
That question for me?
Paige_Niedringhaus:
Uh-huh. Heheheheh.
Jack_Herrington:
Oh, yeah. Oh, OK. Yeah, no, actually, it's totally compatible with older, older, I guess, reducers and all of that.
Paige_Niedringhaus:
Yeah.
Jack_Herrington:
You know, it will handle that.
Paige_Niedringhaus:
Cool.
Jack_Herrington:
And then for newer ones, you can make newer slices based on its its simplification of stuff. But yeah,
Paige_Niedringhaus:
Yeah, because
Jack_Herrington:
I think.
Paige_Niedringhaus:
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?
Jack_Herrington:
Yeah, I mean, we've had Mark on the show and he's a great guy and you know, it's
Paige_Niedringhaus:
Yes.
Jack_Herrington:
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.
Paige_Niedringhaus:
Mm-hmm. Yeah. Yeah, and I have
Pierre_Hedkvist:
Yeah,
Paige_Niedringhaus:
to agree
Pierre_Hedkvist:
and
Paige_Niedringhaus:
with
Pierre_Hedkvist:
I
Paige_Niedringhaus:
you,
Pierre_Hedkvist:
think.
Paige_Niedringhaus:
Pierre. The... Go ahead.
Pierre_Hedkvist:
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.
Tj_Vantoll:
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.
Pierre_Hedkvist:
Yeah, sure. So I think we did this in the span of a few months. So yeah, maybe six months or so, but
Jack_Herrington:
Hmm.
Pierre_Hedkvist:
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.
Jack_Herrington:
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?
Pierre_Hedkvist:
Yeah, so in this particular project, we didn't have either of those. We kind of manually tested everything. So,
Jack_Herrington:
Whoa, whoo,
Pierre_Hedkvist:
yeah.
Jack_Herrington:
exciting.
Paige_Niedringhaus:
Hahaha
Pierre_Hedkvist:
Yeah, so I mean, it was kind
Jack_Herrington:
Livin'
Pierre_Hedkvist:
of
Jack_Herrington:
on
Pierre_Hedkvist:
a
Jack_Herrington:
the
Pierre_Hedkvist:
smaller
Jack_Herrington:
edge.
Pierre_Hedkvist:
project. It was a smaller project in that sense.
Jack_Herrington:
Okay.
Pierre_Hedkvist:
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
Jack_Herrington:
Yeah,
Pierre_Hedkvist:
and make sure.
Jack_Herrington:
I mean, I think when I go into
Pierre_Hedkvist:
But.
Jack_Herrington:
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
Paige_Niedringhaus:
Mm-hmm.
Jack_Herrington:
like make sure that the test test for the bad results, because, you know, that's some times that folks are expecting.
Pierre_Hedkvist:
Yeah, exactly.
Tj_Vantoll:
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.
Pierre_Hedkvist:
Um, yeah, so I do, if I remember correctly, there's something called SWR, which is, um,
Paige_Niedringhaus:
Mm-hmm.
Jack_Herrington:
Yeah,
Pierre_Hedkvist:
similar
Jack_Herrington:
that's a good one.
Pierre_Hedkvist:
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.
Jack_Herrington:
How about in terms of like state management? Did you have a look at anything like zustand or recoil or any of those?
Paige_Niedringhaus:
Mm-hmm.
Pierre_Hedkvist:
At the time of doing this migration that was maybe one and a half years ago, so I don't think Soustand was quite
Jack_Herrington:
Oh,
Pierre_Hedkvist:
as
Jack_Herrington:
okay.
Pierre_Hedkvist:
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
Jack_Herrington:
Cool.
Pierre_Hedkvist:
far.
Jack_Herrington:
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.
Pierre_Hedkvist:
Awesome.
Paige_Niedringhaus:
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?
Pierre_Hedkvist:
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
Paige_Niedringhaus:
Mm-hmm.
Pierre_Hedkvist:
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.
Paige_Niedringhaus:
Yeah, I've got
Jack_Herrington:
Hehehehe
Paige_Niedringhaus:
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.
Jack_Herrington:
Yeah, that refetch interval
Pierre_Hedkvist:
Yeah,
Jack_Herrington:
is just
Pierre_Hedkvist:
I agree.
Jack_Herrington:
so easy. It's just, refetch. Okay. Cool.
Tj_Vantoll:
So Pierre,
Pierre_Hedkvist:
Yeah, exactly.
Tj_Vantoll:
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.
Pierre_Hedkvist:
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
Paige_Niedringhaus:
Hehehehe
Pierre_Hedkvist:
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.
Tj_Vantoll:
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
Jack_Herrington:
Oh yeah.
Tj_Vantoll:
have expected. So.
Paige_Niedringhaus:
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?
Jack_Herrington:
Hahaha
Pierre_Hedkvist:
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.
Tj_Vantoll:
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.
Jack_Herrington:
Yeah. Hahahaha!
Tj_Vantoll:
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.
Pierre_Hedkvist:
Yeah,
Tj_Vantoll:
Well,
Pierre_Hedkvist:
I
Tj_Vantoll:
period,
Pierre_Hedkvist:
agree.
Tj_Vantoll:
is there anything we've...
Pierre_Hedkvist:
Go ahead.
Tj_Vantoll:
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?
Pierre_Hedkvist:
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.
Tj_Vantoll:
Excellent.
Jack_Herrington:
Oh yeah.
Tj_Vantoll:
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?
Paige_Niedringhaus:
Sure, I will kick us off with a hardware pick actually.
Jack_Herrington:
Hmm
Paige_Niedringhaus:
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
Jack_Herrington:
Oh
Paige_Niedringhaus:
to
Jack_Herrington:
yeah.
Paige_Niedringhaus:
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
Jack_Herrington:
Hahaha
Paige_Niedringhaus:
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.
Tj_Vantoll:
Excellent. Cool stuff. Jack, do you want to go next?
Jack_Herrington:
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,
Tj_Vantoll:
Hehehe
Jack_Herrington:
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.
Tj_Vantoll:
Thanks for watching!
Paige_Niedringhaus:
Hahaha
Jack_Herrington:
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.
Tj_Vantoll:
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
Jack_Herrington:
Oh yeah.
Paige_Niedringhaus:
Yeah.
Tj_Vantoll:
at this point. And I've been meaning to, I read the books probably when I was their age, like years
Jack_Herrington:
Mm-hmm.
Tj_Vantoll:
and years and years ago. So
Paige_Niedringhaus:
Mm-hmm.
Tj_Vantoll:
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.
Paige_Niedringhaus:
Mm-hmm.
Tj_Vantoll:
somebody had to check it out.
Paige_Niedringhaus:
Yeah, and those movies hold up surprisingly well for when
Jack_Herrington:
Oh
Paige_Niedringhaus:
they
Jack_Herrington:
they
Paige_Niedringhaus:
were
Jack_Herrington:
do.
Paige_Niedringhaus:
made.
Jack_Herrington:
Yeah.
Tj_Vantoll:
Jack, I do need to know though, House of the Dragon, what is your review? Like
Jack_Herrington:
Woo!
Tj_Vantoll:
the like
Paige_Niedringhaus:
Thumbs
Tj_Vantoll:
15
Paige_Niedringhaus:
up!
Tj_Vantoll:
second review.
Jack_Herrington:
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
Tj_Vantoll:
Okay.
Jack_Herrington:
afterwards. And yeah, that, you know, episode 10 definitely. Wow. They.
Tj_Vantoll:
All right, I haven't seen it yet, but we'll need to watch
Jack_Herrington:
Went
Tj_Vantoll:
through
Jack_Herrington:
full
Tj_Vantoll:
that. It's
Jack_Herrington:
release god
Tj_Vantoll:
just.
Jack_Herrington:
on that one. Hey, Paige, have you seen it?
Paige_Niedringhaus:
No, I'm waiting for
Jack_Herrington:
Oh,
Paige_Niedringhaus:
it
Jack_Herrington:
wow,
Paige_Niedringhaus:
all to
Jack_Herrington:
okay.
Paige_Niedringhaus:
come out as well and then I'm just going to binge it.
Jack_Herrington:
Okay, what's all out?
Paige_Niedringhaus:
Oh, well.
Jack_Herrington:
Go, go, go. It's a
Tj_Vantoll:
Yeah.
Jack_Herrington:
whoa. It's whoa, whoa, whoa.
Tj_Vantoll:
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.
Paige_Niedringhaus:
I love puzzles, so I'll definitely be checking that out.
Tj_Vantoll:
I might pick it a second time or give everybody an update after it gets put together.
Paige_Niedringhaus:
Yes.
Tj_Vantoll:
Awesome. Pierre, do you have any picks for us?
Pierre_Hedkvist:
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.
Tj_Vantoll:
Oh, interesting.
Pierre_Hedkvist:
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
Jack_Herrington:
Cool.
Pierre_Hedkvist:
creating some mini version of Miro. like the whiteboard application where multiple users can create,
Jack_Herrington:
Hmm
Pierre_Hedkvist:
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
Jack_Herrington:
Hmm
Pierre_Hedkvist:
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.
Tj_Vantoll:
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.
Paige_Niedringhaus:
Hahaha.
Pierre_Hedkvist:
Yeah.
Tj_Vantoll:
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?
Pierre_Hedkvist:
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.
Paige_Niedringhaus:
Thanks.
Tj_Vantoll:
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.
Paige_Niedringhaus:
See you
Jack_Herrington:
All right,
Paige_Niedringhaus:
next
Jack_Herrington:
see
Paige_Niedringhaus:
week.
Jack_Herrington:
you guys next time.
Pierre_Hedkvist:
Thank you.