Fully Functional

When I finished work on Friday, I was in the midst of working on a massive reducer. This reducer was the strongest typed reducer I had ever written. For this screen, my types file is almost 600 lines long, and is fully extensive. Every different action is typed, the context is typed, the types are tied to an enum, and there are literally no strings or values that could be misdirected. There is no way anyone could come in and mess this thing up. I was concerned when I came back today, I wouldn't be able to figure out where I was or what I was doing. It took about a half hour to get oriented again, but once I did, it was all good. I had the reducer completely written, but it wasn't fully hooked up yet. I had a lot of instances of state to watch what view was being shown, so I had to unwind all of that and hook in the dispatches where appropriate. To get everything I had already created on Friday hooked up, it took a couple hours. Once I did, though, everything was working great. There was still a lot of work to do left, though, to have the reducer doing all of the work.

After I finished up with what I had already started on Friday, I needed to get it hooked up so when data was edited in the forms, it would show up in the hard coded view. As it was, all of the data in the hard-coded view was, well, hard coded. Because of the reducer and the use of React-Hook-Forms, this was a cinch. I had a great mental model going, and everything was looking great. On this page, there are several different tabs to deal with. One of the tabs is just simple details about the lead, like their name, phone number, email, and other such items. Other tabs involve arrays of objects representing things like notes on the lead, appointments with the lead, reminders, and activities. I had the information getting saved to context for these sections, but I hadn't created the flat lists to deal with these yet. I had a pretty good example of a flat list in the other screen I had created holding the list of leads, so I did what I could to copy over what I needed for each of these tabbed screens. When I finished it off, I was getting a big error on my renderItems prop and a non-descript message from TypeScript about it. After staring at my screen and hitting refresh about 20 times, I finally realized I had forgotten to put in a return statement. It was kind of ridiculous, but these things happen, I guess.

I was able to add a few more actions on to the reducer to edit and delete these objects from the array, and everything was looking great. At this point, my cohort let me know he had been working on the API to bring in the actual data for this screen. This was great news and even better timing. I was just wrapping up my reducer work, and I knew it wouldn't be too hard to set this up. I got my fetch request working for the API and had the data, so now all I had to do was hook this data up to the appropriate fields on the state of the reducer. I thought this was going to be an easy task, but the object coming back from the API was incredibly complex. I was struggling with it, but I finally got everything into the initial state, so I gave it a refresh on the local server, and nothing showed up. After more staring at my computer, hoping something would magically change, I realized the error. I had saved the data object to an instance of state and the screen was rendering before that data was showing up on the screen. So, I realized what I needed to do was create a new action type to bring in the data. This would only be called once when the fetch initially happened and would replace the initial state. I didn't have enough time to hook this up by the end of the day, but I'll be able to get it done first thing in the morning.

Until tomorrow!