Lessons in State Management

In the last week or two, I've gone the distance in exploring different options for state management. I've specifically been working on one screen that has a lot of state and actions tied to that state. In the payments application we created when I first started at the job, we just had one central location for our context and reducer and that was it. Pretty much all of the data and screen changes flowed through there. A while back, I took the screen change state out of that reducer and created a separate reducer for it, thus separating our concerns a bit. For this application, this state management strategy works well, as there is information that is collected through forms on each screen and must flow through until the end. We had some get requests at the beginning of the flow to bring in the representative's information and then the lead's information, and at the end, we had one post request to send the information off to the backend. That's all it took. While building this application, I thought it was pretty complicated. When I look back on it now, it looks like child's play. I have more state management in this one screen than I had in that entire application. I've gone through several different strategies for managing the state, but I think I've finally landed on something that works.

I thought I had finished up the reducer for this screen earlier in the week. It had grown to over 50 different actions and things were getting a little maniacal. When I discussed it with my cohort, we talked a little bit about the best way to handle UI changes with the state. The way I had it, if anything changed on the screen, the entire screen re-rendered. It's not an incredibly heavy application, but it's growing to epic proportions. As it grows, we need to consider performance more than we have in anything else. We started using React-Hook-Form back in the payments application, and this really helps with performance. In the regular way of managing forms, the application is re-rendered every time a key is entered into an input. With React-Hook-Form, it only re-renders one time when the form is submitted, and that's it. As the name implies, these forms are using React's hooks and custom hooks to do a lot of the heavy lifting and make it the most performant option. It blows Formik and Redux-Forms out of the water. Anyways, I took all of the UI changes and put them into individual useStates at the root of where they were needed, not at the root of the screen. This led to some pretty deep prop drilling, so I added an instance of context to each of these root components. I don't know for sure, but this seems like the best way to handle things. There are a lot of opinions about state management, and performance is really the truest metric. I think this pattern works well.

For the last 2 or 3 weeks, I've been working on a microservices course with React and NodeJS by Stephen Grider. This course was 54 hours long, and was really extensive. We covered a lot of ground and a lot of topics, but I certainly don't think I mastered any of them. I will say, I got more practice with Express than I ever have, along with Mongoose and MongoDB. I feel decently proficient in these areas now. As far as Docker and Kubernetes go, I can only say I'm familiar with them and understand how they work now. If someone starts talking about one of these subjects, I may be able to contribute to the conversation, but I don't think I could build something on my own with them. Also, while I like the root idea of what these technologies do, I don't love the way you have to do them. There ends up being a lot of setup and configuration that comes along with these tools, and it's really not that fun. Troubleshooting issues is a bit of a nightmare, too, at least at my level of understanding. When I went to look up an issue, it was like I was reading a foreign language. I did have some issues, too. I messed up one of my listeners for a microservice, was able to fix it, but the Mongo database never seemed to recover. I spent a solid 3 days trying to figure out a solution for this, but never did. I'm happy I took the course, but I'm even more glad to put it behind me.

Until tomorrow!