Optimization

I'm still waiting on my cohort to bring me up to speed on the React Native project, so I wasn't able to start working on that, yet. I really want to get going on this project, but I can't start until he gets me going on it. He's doing a lot of the architecting now to set us up for success, and for the most part, it seems necessary. He seems to get drawn into going down some rabbit holes from time to time, and they often pay off, but they also add a lot of time to projects that could be done a lot quicker. I've found when I'm left to myself on a project, I can bust it out pretty quickly. If he's involved, the project's duration gets multiplied. However, I wouldn't say that's necessarily a bad thing; he brings a lot to the table and thinks about things in a different way. I'm still a novice compared to him and he just knows a lot of things that I don't. I'm getting better by the day, though, and I'm bringing more to the table myself on a daily basis. When I first got to this job, if you had asked me to construct some of the things I've done in the last 2 months, I would have been completely at a loss. I'm learning a lot about React Native in my spare time, too, and I'm anxious to apply that new knowledge. Things are fairly similar in React and React Native, but there are a lot of intricacies to React Native that up the learning curve pretty significantly. It's not something you can just pick up if you know React; you have to learn all the stuff that comes with React Native.

As I wait, I refactor. I've completed everything I can do with the next version of the payments application, and all there is left is just to make the code better, or try to, at least. Sometimes it seems like the more you work with the code, the more possibility there is of making it worse. If it works already, why would you mess with it. We've had many working versions of this application, and over the versions we've shipped, there have been a lot of refactors to either optimize the code, make it more readable, or re-structure it. The biggest one that we have now shipped, which actually shipped today, was changing over to React-Hook-Form from managing state on our own with our forms. Before we started using React-Hook-Form, our application would re-render every time a key was entered into an input. This meant that, throughout the lifecycle of the many steps of our application, the form would get re-rendered nearly 100 times. It was ridiculous and, as our application grows in size, not very optimal at all. When I first started working on this project, there really wasn't much to it. There was a step to add a billing address, a step to add credit card information, and a step to review the information. That was pretty much it. So, at that size of the application, this many re-renders was pretty acceptable, though not great. Now, there are 9 steps to take to get from the beginning of the form to the end, and three different routes you can take to get there. We had to fix this issue, and React-Hook-Form did a great job of doing this.

When I started the second version of the application, it was kind of a completely separate path to take. The existing application could only be accessed if the customer had a quote ID, and my part was for the representative to access directly. It was a 6-part section, and I created a reducer to handle these steps specifically. This reducer, though, wasn't accessible from the root component of the application, and while it really doesn't cause any issues, it posed some limitations. If the user wanted to go back once they reached the billing address step, it was impossible unless they wanted to go to the very beginning. I've been considering fixing this for a while, and I figured while I wait, this would be a good time. I took this reducer and added it to the main reducer in the root component, creating a much larger, but comprehensive reducer. This was part one of my big refactor. The second part was moving all of the data from being managed by useState being passed to useContext, I wanted to take this data and put it in its own reducer. There are actually 2 main sections of data, so I created a reducer for each of these, thus separating out the data a little bit. That way, if some state is needed in a step, not all of it has to be exposed; only the state that is needed. In this case, the use of useReducer over useState seems negligible, but I know it is a widely used pattern and very similar to how Redux would handle something like this. It really didn't change the code all that much, just a difference in the syntax. Overall, I think the changes I made to the state management today will help us in the long run tremendously.

Until tomorrow!