Episode 4 - State Management in React with Paige Niedringhaus

Paige Niedringhaus: 0:00

So one of the things that I try to keep in mind when I start to build out a new application or a new feature or something like that is where is my data going to be coming from? So will I be using a database connection and API, a third party?

Fernando Doglio: 0:31

Yes, you are listening to another episode, 20 minute JavaScript. Where we talk about everyone's favorite programming language: the JavaScript. These episodes are hosted by opener blade and open-source session replay tool for front end developers. If you're looking for a way to understand how you use or interact with your application checkout OpenReplay. I'm Fernando, your host, a master of puppets for the next 20 minutes. Today, we have a very interesting episode for you. We're going to be talking to Paige Niedringhaus and we're going to be discussing Twitter's favorite topic, state management in react. So Paige welcome and thank you for being here.

Paige Niedringhaus: 1:05

Hi, it's nice to be on Fernando. Thanks for having me.

Fernando Doglio: 1:08

Yeah, absolutely. Uh, all right, so today we're gonna be talking about, uh, state management. On the web in general and it react in particular. So let's get started because I really, I really think this is a very controversial subject in the sense that everyone has an opinion on it. Uh, everyone has created a library for it and an article about it. So I want to know what you think about it. Uh, so, but before we get into react in particular, tell me. How do you think about state, uh, for your web application before even thinking about the implementation? What is at stake for you?

Paige Niedringhaus: 1:45

Well, for web development, state is actually web apps are state less, which is a little bit confusing, but when you start to think about it, it really is everything that is necessary to keep an application running. And typically it refers to the state of a program as it exists in the contents of memory. Um, so this includes things like global variables, static variables, objects that are allocated to the heap, to the stack network connections. It's kind of all of them. As a much larger and broader topic. And then when you think about web apps in particular, we think about, you know, when a server drops its connection, or it goes down and restarts, a user comes back to a page that they may have left or gone away or closed. Whatever was in memory is lost. So none of the information remains in the inputs or the forms are really the changes that you may, unless you're using something like a database or something else to save that state in a more permanent solution. So one of the things that I try to keep in mind when I start to build out a new application or a new feature or something like that is where is my data going to be coming from? So will I be using a database connection and API of a third party? But that's really where a lot of the state that is not ephemeral or only until you close the session is going to exist. And then also whatever changes the user makes do I need to save those in a more persistent way, whether that's something simple, like local storage in a browser, or it needs to be something more concrete, like a database again. So, you know, state in general. Whatever happens in the application while it's running and then disappears as soon as the user closes that browser tab and goes on about their day. That's the best way to think about it, I think in terms of web apps.

Fernando Doglio: 3:42

All right. Perfect. And then the question is how do you map that to the React world?

Paige Niedringhaus: 3:49

Well, it maps pretty well actually, because in react, everything that happens on the screen is held in local state variables for the most part. And we update those, we manipulate them while using the app, they change and do whatever we need them to do. But again, as soon as the user leaves the app, or even leaves that particular component where the state is being stored, um, it dissapears. So it's lost it resets when they come back to that component or re Mount page. Um, and unless we save it via a database call or in session storage or local stores, like we talked about, it just doesn't exist. So react is very, I think it, it goes very much in line with how we define state more broadly and kind of works the way we would expect it to when you're thinking about how browsers typically work.

Fernando Doglio: 4:41

Uh, throughout the, the history of React, let's call it that. Uh, there have been many ways even, uh, from the team behind React, the have been recommended to manage state. Um, that has evolved with the framework itself, um, before we get to the actually good ways of doing it, uh, what are some of the worst ways that you've seen or you've even done, uh, yourself in the past, uh, regarding state management? How will you say you don't usually do that?

Paige Niedringhaus: 5:16

Well, one of the biggest things, and I think one of the more controversial subjects is reaching for an outside state management library, like Redux or Jotai or Zustand or any one of these too soon. This is a very common mistake that I have made as well. Um, and it really, I think it's become a more or less prevalent mistake that people make now that react hooks have come out. It was more popular, probably when components class-based, um, components were the only ones that were available, but it's really. Over engineering and over-complicating state management when it doesn't really when the project doesn't really call for it. So that's probably the biggest thing that I've seen and done myself. Um, and then some of the smaller ones that can still be a real headache. Once you start to build up big applications is having too many individual pieces of state when they really should be connected via something like a use reducer function, because they actually all work together. But. People just have them as individual pieces, like isLoading and isError and just the different things like that, where they really could be a single function that used reducer handles all the pieces at once. Um, and another big one that a lot of people talk about regularly is prop drilling, which is another controversial topic about, should you prop drill at all? How many levels can you go? Um, but I know that that one is one that really gets people. Going and gets Twitter on fire. And everybody has an opinion about it.

Fernando Doglio: 6:57

Absolutely. I it's like callback hell right. I mean, how many ha how deep can you go before you call it? Uh, you call it, "bad" yeah, definitely. So would you say that, uh, prop-drilling is a big "no" at least on your book?.

Paige Niedringhaus: 7:11

I think it's not as much of a hard and fast rule as people try to make it. Um, there is definitely a place for useContext, which is the easiest way that I've found to avoid prop drilling. Um, but I think that if you're maybe going a level deep you're passing stuff from a parent to a child component, that's fine. I don't really think that adding context in for that kind of a thing is really necessary. But I think when you have. You know, grandparent grandchildren and great-grandchildren and things like that all the way down the tree, and you're going three or four or five levels deep. And none of those components in between need any of that information, then sure. Use something like useContext, just grab it from the parent, take it all the way down the tree and then bring it back if it needs to make changes to the parent again.

Fernando Doglio: 8:02

All right. Perfect. And when would you say then that, um, it makes sense to make the jump from, uh, You go from prop drilling to useContext to the next, uh, the next thing without calling it, uh, over engineering.

Paige Niedringhaus: 8:21

So going to something like an outside state management library that really comes into play when you have different pieces of an application that are not. Uh, inside the same context parent. So if you had, um, users in one part of the tree and you had a checkout system and the other part of the tree. You know, you need the user information in the checkout, but they're on the same level and don't share any of the same parents. That's when it would make sense to use something like Redux toolkit and say, Hey, here's my user information it's stored. And then in the checkout, be able to pull that user information, have everything that you need. That's really, I think when it starts to make more sense to bring in a third party library.

Fernando Doglio: 9:08

Alright. Uh, so let me see if I get it, ideally then to understand the state management solution for you, for your application, you need to have hold off on the kind of relationship you have between your components and, uh, application wide, uh, relation relationship as well. If you have completely unrelated or potentially unrelated, um, components that need to share some kind of state. You also want that to influence your decisions.

Paige Niedringhaus: 9:42

Yeah, absolutely. And you know, if you start out and you have some state in one part of the application, but not another, and it turns out that you do need it, maybe it's possible to move it up a level. So that both then would have access to it or maybe not. So that's kind of, when you have to decide, maybe we need to do a little bit of refactoring and kind of re uh, decide where we really need to put this particular piece of state so it's available, or it really does make sense to keep it in the same spot. So let's just bring in a helper tool so that we can then share it and pass it where we need to in the future.

Fernando Doglio: 10:20

Right. And going back to, to the beginning, when you said that a state is essentially something that goes away, unless you keep it, um, where, um, Let's call it the recommended ways of keeping that state, uh, not just solely so it stays there, uh, so that I can read it later, but also taking into account potential, uh, security issues, because after all, we're dealing with state on the front end, uh, we don't want to keep user data for instance, or you know, credentials or, uh, so how would you recommend deal with that?

Paige Niedringhaus: 10:59

Yeah. So it depends on what, what pieces of state you want to preserve. If it's something that is maybe less critical, like maybe some user preferences, if they like dark mode or light mode or some really basic user data that is not secure or needs to be secure, then maybe something like session storage or cookie storage would be enough for you. So you get to rely on a user's browser. You just let them cache it. And. If they came back in a different browser or they took away all their cookies or whatever, it wouldn't be a huge deal. Um, so this is easy to implement. It. Doesn't take a lot of extra work on the devs part and it's pretty straightforward. So I would recommend this for people who are new to development or who are just building an application and they're not sure how deep it's going to be. But then when you get to things that are more user specific, like maybe you have, uh, addresses or you have God forbid credit card numbers or social security, something like that, that needs to be persisted for a longer time. Then you're, you're gonna want to go with a database. Um, so that is going to require more setup because you'll need a separate database, whether it's in a cloud or it's on a local machine somewhere, uh, it'll require just more monitoring and more authentication. So you'll need to start doing something like OAuth or Auth or any of the other authorization and protective kind of, uh, login services that are available and make sure that anybody who's trying to call this database is actually authorized to do so and change the information that they want to. Um, so that is going to be. Tougher. It's just going to take longer. There's like you said, there are security concerns that you have to be aware of. You have to protect that database, whether it's encrypting just the calls to it or encrypting the entire database itself. It's just, it's a lot more to keep track of, but. That is, you know, a lot of times that is what you have to do for when, when a user makes some changes, leaves and expects them to be there the next time they come back. So it's, it's just another part of web development.

Fernando Doglio: 13:12

Yeah. Absolutely dealing with the damn users. All right. So then going into third-party libraries and, and, and kind of. Uh, the end of , uh, of the state management problem. Um, what is, if you have one, what is your favorite one? You go to library when you have to deal with this, uh, with a standard state management, let's put it that way.

Paige Niedringhaus: 13:40

I mean right out of the box, I would say don't use a third party library and only when you really run into something that it makes no other sense, add it. Um, but I I've gotten really comfortable with using reacts context API. That has been really good for me. Um, for many instances. Um, but when you do get to that point, uh, some good options to consider are Redux Kit. Which is Redux 2.0 and has simplified, a lot of the boiler plate that a lot of people complained about with using the original Redux. So it's a great thing and that they maintain her of it. Mark Erickson is great. He is very responsive on Twitter. He's written fantastic documentation for it. Um, you'll find a lot of good support for it. So Redux tool kit is a great one. There is one called a zoo stand, which is an unopinionated and increasingly popular library. That's a really good option. If you're looking for kind of the, the more bare bones, uh, type of state management, um, also Joe Tai is another one that's kind of along the same lines. And then if you're looking for something that's also supported by Facebook or Metta recoil is an option. So, you know, the react core team has maintained. Facebook Metta. And so recoil is as well. So those are going to integrate really well, but there's, there are so many options out there it's really just kind of evaluating what makes sense to how you do development and your team, and then just picking one and going for it.

Fernando Doglio: 15:15

Probably because there are options, but they're there they're all as valid as the next one. Right? I mean, just a matter of preference. All right. Just as long as you don't use it, right away.

Paige Niedringhaus: 15:27

Right. See how far you can get before you, before you go for it.

Fernando Doglio: 15:33

Understood. Understood. And I want to pick your brain about Redux, just Redux not Redux toolkit. I want to know what you think about it. If there is still a place for it. Now that we have Redux toolkit around, it's been around for a while. I mean, but there is still a lot of people. Uh, advocating for just Redux or going with Redux, because if you think, if you just Googled state management react, that's the first thing that comes up. So, um, do you think there's still a place for it or is this just old news? I don't want to be mean, but in a sense that it's outdated and it's been already been replaced by a better version of itself?.

Paige Niedringhaus: 16:17

I think that there is definitely still a place for it. It was one of the first state management libraries that I used in my, at one of my jobs. Um, and it was, it was great for its time. It became the gold standard for a reason. It replaced flux and mob-x really quickly for good, good reasons. But I think that there, that a lot of the complaints that we briefly touched on, like there's a lot of boiler plate. Sometimes it's hard to figure out what is react doing versus what is Redux doing? Things like that have probably made it less popular than some of these newer options that have come out that have tried to reduce that extra code bloat. And the trying to figure out if I pull on one string, is this other thing going to unravel over here? So I think that it's definitely still a good thing to know and to understand, especially if you come into a project that already has, Redux added to it. It's going to behoove you to know how it works, but if you were starting from scratch and decided today that you needed to add a state management library, I think that there are probably better options that are a little bit less difficult to kind of get up to speed with and start using effectivly.

Fernando Doglio: 17:33

And it makes sense, right? I mean, it's, it's been one of the first ones to, to, to make it work, like you said. So even if it wasn't perfect at the time, uh, it was the best option. And then the others came back, uh, came on top of it and, and improved and, uh, fixed the issues they found. So definitely, yeah, definitely makes sense. The progression. Perfect. Thank you. Any final recommendations around state management. Before we move on to the quick shot round that we ask all our guests on the podcast.

Paige Niedringhaus: 18:06

I would just say that, try to keep in mind that even though react is typically a pretty unidirectional data flow. So data flows down from the parent to the child, to the grandchild, et cetera. There are plenty of ways now to get around that without having to go for a third party library, there's all kinds of, you know, little helper functions that you can add in, so that it's much easier to translate those effects that a child is making back up to the parents. So, you know, just do some Googling and do some testing and see how far you can go before you start to reach for outside help, because the smaller you can keep your packages and your, and your build folders, the faster your site will be. And the happier your users users will.

Fernando Doglio: 18:53

Absolutely great recommendation. Thank you. All right. So before we reach the 20 minute mark, I'll ask you some questions that we ask all our guests. Um, so can you share the best advice you ever got?

Paige Niedringhaus: 19:07

Sure I have, I have two pieces. The first one was from my very first engineering manager and his advice was to get comfortable with being uncomfortable. So you, you really know when you're growing as an engineer or even as just an employee when you're out of. What would be considered your comfort zone? So as long as you feel like you're being stretched in directions, that you're not sure if you'll be successful in, or you don't really know how to do something. That's a really good spot to be at and just kind of embrace the feeling of discomfort. And then the other thing that I have is from an a senior engineer, uh, who kind of mentored me, which was to start writing or sharing what you've learned with the development community, whether that's giving a conference talks and meetup talks, whether it's writing consistently, whether it's blogging or making videos or whatever it is, just get out there. Share some of the problems that you've encountered and how you've overcome them, because it'll lead to really, it'll lead to you standing out amongst your peers, and it will lead to opportunities that you never even considered. You know, I've, I've gotten to be paid to write technical articles for companies I've gotten to author a course because of it. I've I even got my current job because I came and spoke on a podcast that. One of my now coworkers was hosting. So. You never know where those things are gonna go and what they could turn into. So just start putting out there what you're learning, because I'm sure it'll help somebody, which is the main thing.

Fernando Doglio: 20:42

Absolutely. Absolutely. And the top of that, um, the more you communicate, whether it's written, uh, on video or watherver the better, your own communication skills will improve. And that's also something I constantly advice.

Paige Niedringhaus: 20:57

Yeah. Soft skills are very underrated in technology jobs. And they're just as important, I think, as anything else.

Fernando Doglio: 21:06

Absolutely. Thank you for that. If you can, can you share with us the most exciting project to work?

Paige Niedringhaus: 21:13

Yeah. I mean, one of the projects that I'm working on right now is really exciting. And I work now as a staff software engineer for an IOT internet of things, startup called blues wireless. Um, so one of the things that we do as an internet of things company is we make hardware that our users can then put onto their existing projects to make it internet friendly. Um, okay. But one of the things that we're doing to assist them is once they've got the hardware and they're starting to take in sensor data and like temperature and humidity and pressure and things like that to actually go from the device on the edge, to a dashboard or a browser in the cloud that shows them charts of the data that's coming in and readings at at that time and place. Um, so we're building this application from scratch. That is kind of like a demo reference starter application that our users will then be able to take, put in their own sensor info and then see it in dashboards and extend it and do, you know, basically whatever they want with it in the future. So it's really fun, kind of learning how to make our code easy enough that other people will be able to build onto it when they want to. And also. Figure out how to make it modular enough that we can go from one data source, which is pulling in the data to switching, to using a database or switching, to use, you know, really whatever you want as your data supplier. So it's been really cool to learn how to. Make that flexible and modular and just keep in mind a lot of things that you wouldn't necessarily consider. If you were building an internal application that you would maintain, your company would only use internally. So it's been really, really fun, kind of stretching myself in those.

Fernando Doglio: 23:04

Well, you said, you say, uh, that was a good place.

Paige Niedringhaus: 23:08

Yeah. Yeah. And there have definitely been times where I'm like, I have no idea what you're telling me or how to do this. So let's pair and show me some of the code and then I can learn how to do it from there.

Fernando Doglio: 23:20

Good. That's good. All right. Perfect. Um, finally, one thing that you wish you knew before you got into coding that you learned over time.

Paige Niedringhaus: 23:31

Oh, uh, well, the biggest thing probably is that you do not need to have all the answers. Really. You need to be able to ask the right questions to figure out what the current, what the correct solution or the right answer for you is. That's the main thing is get really good at Googling. Confident that even though you don't know how to do something, you can find the way to do it. That's, that's a huge part of a developer's job that I think is not talked about enough.

Fernando Doglio: 23:59

Yeah, absolutely. And, um, funny enough, you, you're not the first guest to to mention that. That piece of wisdom. I think we all eventually realized that. Yeah, it's not about having the answers. It's just about having the number or the guy who has the answers and that usually is Google. Yeah, absolutely. All right. Uh, thank you so much. Can you please tell everyone where they can find you? Um, and you know, if you have any project, anything cool, you you're working on.

Paige Niedringhaus: 24:28

So I am on Twitter and you can find me at@PNIEDRI, because I chose a terrible Twitter handle way too early on. Um, I have a website where I publish my writing and I write about once a month on technical.. Mostly front end stuff. So you can find me at paigeniedringhaus.com/. And then one thing that I would like to shamelessly plug is that I actually authored a course on modernizing enterprise react applications for a course platform called NewLine. So we'll have a link to it, but it goes everywhere from taking an existing application. That's using class-based components to using hooks, using context. Using prettier and es-lint using react testing library for a unit tests and Cypress for end-to-end tests, and then using an ant design component library. So it really runs the gamut, but it's all of the experience that I got when I worked for home Depot and we did build applications of large scale that were long-term. So if you are new to hooks, or really just want to come up to speed with what is the latest and greatest with react? I would say that it's a really good place to start.

Fernando Doglio: 25:43

Fantastic. Yeah, definitely. We'll have a link to everything you mentioned, including your terrible, uh, Twitter handle. Some people can find you. Don't worry about that. Okay. Uh, again, thank you very much for being here for joining us and, um, talking about, um, state management with us. Paige Niedringhaus: Absolutely. It's been lot of fun. Same here. Thank you. All right. Thanks everyone. See you on the next one!.