Instructor: 0:00 I spoke to Mark Erikson, the maintainer of Redux, and he told me about a time when he was working in an application and he designed an API that used these type arguments, like the passing of types to functions, to really smooth over a lot of really difficult to write code.

Mark Erikson: 0:16 Actually, I can think of a specific example from the Angular app that I worked on a couple years ago. Very, very short background. It was like an internal project metrics and statistics database.

0:27 Projects across the company had a mandate that they had to upload stats about their project every month. Our backend would take these uploaded Excel files, extract a bunch of info, and do some post processing to spit out red, yellow, green statuses in various categories.

0:45 The app had about 30 different metrics that it knew how to extract and process, each of which required storing several different pieces of data. It had a similar logic to do post processing, but unique to each of those metrics.

1:02 The previous developer that I took over from had defined a fairly consistent pattern for doing this work, but again, it was all plain JavaScript. When I took over, it took me months to try to understand what all that code was doing, both conceptually and the data types.

1:24 There was one particular chunk of that. I really wanted to be able to define, again, a couple of those key data types that were going to flow through the system where there's going to be a report type.

1:36 Which always is going to have a certain, it's got the date, and the name, and then a contents field that is going to be unique to that report type for that metric.

1:50 I wanted to be able to make that content field generic and then declare the processing logic and just say, here's what the contents field type is going to be and have that ripple through all the processing functions so I didn't have to keep redeclaring it and just have the rest of that inferred.

2:09 Writing that processing logic and its types probably took me a week or two to try to get all the inference set up correctly. Once I did, it was beautiful.

2:21 You just go to the file, you declare the interface or the fields for the content type and say, report angle brackets, my content type, apply that to the processing structure definition. Later on, you define the handler callback and it knows all the types. It just flowed all the way right through.

2:42 That was basically internal library style code in the application code base. A mindset for writing that code was very different than going off and writing yet another component.

Instructor: 2:55 That's fascinating, because that I imagine, that reduced a lot of duplication I can imagine.

Mark: 3:01 Oh, yeah.

Instructor: 3:03 Did that feel easier to maintain going forward as well?

Mark: 3:06 Absolutely so. It gave us a lot of confidence knowing that, as we did have to start adding a new metric definition, we had a very consistent boilerplatey, but intentionally so kind of pattern.

3:22 Of course, we always usually started it by copy pasting an existing file, but you knew you just defined the content field, declared a report type, pass in the generic, declare the data, declare the processing structure, pass in that generic, and all the rest of it's going to be typed correctly.