Reducer Solution

[00:00:00]
>> And so the challenge is to create a reducer function that accepts state and action parameter and a switch statement that evaluates the action type. And then based on that load, read, create, update, delete. And then it calls an appropriate method yet to be finished, that takes state and an action.payload and then just returns state.

[00:00:25]
So, I'm going to hop into the code. And I went ahead and I finished this for the clients. And I want to just illustrate something here. I'm gonna copy this and I'm just gonna open a new file. And so this is in here. And I've taken everything that I've done for clients.

[00:00:58]
And now I'm going to what I'm looking at is, I need to basically pick this up. And I need to essentially create the equivalent for projects. And so typically what I'll do is I'm just going to I almost hit the escape button, that would have been bad. I'm just going to go through and I'm going to do a case sensitive find and replace.

[00:01:34]
And now I'm certain somebody's saying, well you shouldn't be doing that or When you should not be doing that rather, is that is because you're actually doing a straight duplication of the code. And the differences is that it's important to make the distinction between duplication and convention. And so a lot of times we look at things and we say like that's the exact same thing over and over, and if it's doing the exact same thing, so it's one thing to do the exact same thing.

[00:02:22]
It's another thing to do it, do the thing exactly the same. And so it's the difference between doing the same thing and doing the thing exactly the same. So I think we're good here and the should be good to go. Now over the course of me talking about this convention versus repetition.

[00:02:46]
Is that I've managed to just pick this up, change the one piece that was different between the two. And I'm going to put it back in. Now, again, what is the one thing that I changed? Well, it's the domain model. So the domain model is changing, but the actions in which we're performing are typically the same.

[00:03:12]
So for instance, if you make a rest call, and you're saying give me all of the projects or all of the clients. The mechanism to do that is going to be exactly the same. Because it's consistent that whatever library you're using, if it's axios, or it's HTTP client, it really any REST client is going to say, this is how we talk to a REST client.

[00:03:37]
And it's typically not going to be any surprises. And so the takeaway here as it applies to enterprise programming. Enterprise applications is that identify the things that are conventionally equivalent and automate that stuff, optimize that. Find the things that are not conventionally equivalent. So what are the things that typically changes from application to application?

[00:04:05]
Well, the UI changes. And a lot of times the business logic changes, you should spend 95% of your time in an application focusing on those two pieces. So with that said, I'm just going to pick this up, and I'm going to come down here. And I'm going to complete a challenge in one fell because I have a reference and I can follow so I'm gonna save this.

[00:04:44]
And I'm not gonna save this. Don't save, but I will save this. So we had two questions. One, is what are which is the best architecture folder structure that I've found? For me, I really, really, really, really, really times 10 to the power of 10. I like how nx organizes their file structure.

[00:05:13]
And so that is in it's actually baked into this and so this is. Not only even though we're doing Angular nx supports react, next a bunch of stuff is that I'd like to separate my applications into an Apps folder, and then all of the shared functionality into libs.

[00:05:37]
So that is a very basic folder structure, but it allows you to have very thin applications with very thin components. And then all of your business logic is pushed away into ribs that you can share. And so, as the saying goes is that you want thin clients that models the idea is to move your complexity away from the point of consumption.

[00:06:02]
Further away, so that you can start to share it, or treat that complexity, really turn that into functionality, that then becomes a platform, in which you're able to serve, additional applications and modules, etc. That was, felt like it was onto something there. The next question is, are we going to deal with code duplication, in our projects?

[00:06:26]
And the answer is not directly. But in a way we already have is that the way to avoid code duplication is to not have hidden state. Now have nested logic and do not violate the single responsibility principle. Now with that said, there are tools to check for copy paste detection to get CBD or whatever but I think that got hijacked by something else.

[00:07:00]
Copy Paste si p d and so there are some tools to see if there's is code duplication. And so I would say, you know, if that's a problem, then you can run some kind of static analysis on your code. But I think by having a proper architecture and avoiding the axis of evil, that it really minimizes on that potential to do so.

[00:07:27]
The next question is, after the iterators, could you recap how each part is related to reducer pattern? After the iterators, I will be happy to do that.