A Project Evolved

I started off with this project at work being the addition of a feature onto an application. I've described it before, but briefly, the initial application was a payment process with a quote ID being taken in and address and credit card forms being given to fill out. Once those are filled out, the information is passed through to an API that handles credit card processing and the receipt is given to the accounting department. The feature I have been working on would allow the user to fill out the information usually pre-populated by the quote ID. They would find their representative by calling an API that matches the representative's ID with their input, then pick their plan, give a list of referrals optionally, and then pass through to the original application. I got the functionality all down last week, and everything works really well; the only issue left was to get this information passed through to the company's database so they can save that information within the database. A new field will have to made for referrals, and the database would have to differentiate between what payments were coming from this feature and which are coming from the quote ID. This isn't really my job to do, and I actually have no idea where to even start with this, but I would be happy to learn. Every time I ask, I'm given something else to work on in the app, be it the feature I've built or the initial application itself.

It started off with re-working the state management of my feature. Instead of using a basic state management with useState, I was prompted to create a reducer to manage the UI states, and confessed this was a bit above my head. Actually, I should back up, briefly: it started with rewriting the whole app to be more than just one file, and refactoring it out into separate files for separate components. Then I learned how to refactor it to be written with TypeScript instead of JavaScript and rewrote the whole thing to be in TypeScript. Then I started working on my feature. With this reducer, any time the application advanced from one step to the next, the reducer is dispatched to call that new status of the application, and reflect the component associated with that type. This makes it truly a single page application, and is actually a really cool way of handling the state of the user interface. So, I wrote my whole feature using this way of doing things, passed it off to my neighbor, and he suggested I use context alongside the reducer to handle the state. At that point, I had pieces of the state changing with the dispatches and being passed through that reducer, but he showed how much easier life could be with using the useContext hook alongside the reducer. He was totally right, I have to admit, but it was certainly a big change adding this in. Then, we started looking outside of the application, because there were certain features of my part of the application that needed to integrate with the initial application, and there were limitations because of the initials structure of the app.

In the initial app, the UI state was being managed by context, and it certainly seemed to work fine. The problem was, when it progressed from one step to the next, it was kind of ambiguous as to what was going on. In other words, if someone else were looking at the code, they might have a hard time understanding exactly what was happening. He suggested I refactor the whole app to manage the UI state in the same way as I did in my feature. At first, I felt like this was a daunting task, but I decided it would be great practice for me and would only make me stronger in working with these advanced hooks in React. I got started on it on Friday, and immediately hit a big bump in the road. In the initial app, the context was defined one component below the main component, in other words, in the first child of the App component. This made it difficult to access this context globally, and when I tried to define the reducer in the main component, it caused all types of problems. These problems were not insurmountable, but over the weekend, I realized they were unnecessary. If I just took that child app and migrated it to be a part of the main component, moving the main context into the App component, all problems would be solved. I set to work on this in the morning today, moving all of the UI state over to this reducer. To my surprise, I was able to knock this whole process out in about 2 hours, and the app worked perfectly. It made dispatching the UI state changes so much easier, and just made a lot more sense. From there, I spent the rest of the day working on a receipt page, where the user could print off the receipt from the transaction, and was able to get this hooked into this reducer with ease. While these refactors have been challenging and sometimes seem counterproductive, they have been great learning opportunities, and going forward, it will make the application way easier to work with.

Until tomorrow!