Managing Complexity in Angular

[00:00:00]
>> So your routing table will generally describe your features. And so if you had students, courses, workshops, lessons, you pick any kind of a feature set that your routing table is generally going to define your feature set. Not always but more often than not.So a feature will generally get a route and then a route will navigate to a container component.

[00:00:35]
And then everything inside of that container component should be a presentation component. So this is standard component driven architecture, now, these next couple of slides are green for a very good reason because it's pure money. A component should only ever do two things, consume just enough data to satisfy its templates and capture user events to delegate them upwards.

[00:01:06]
This means that components should be as thin as possible and they should satisfy input using the async pipe. They should be oblivious to business logic and they should be oblivious to server communication. So I'm just laying a foundation for all the things That we're gonna talk about today.

[00:01:28]
So let me just repeat that, components should be oblivious to business logic, they should be oblivious to server communication. Because all they're doing is pulling in just enough data to satisfy their template, and if something happens from the user then they're capturing that event and they're delegating it up.

[00:01:47]
They should be oblivious to application state, a user's feature should have no idea what is happening over at the widgets, or what the state of the items are. Facades, we'll talk about these, it's an effective delegation layer between components and the rest of the app. So this is a really, really important pattern that I use to manage complexity.

[00:02:13]
Now, they're for delegation only, this is where myself Mike Ryan from Ngrx.We have been around in circles. It's really easy to abuse this pattern, but if you use it as a line of separation between your component layer and the rest of your application just to delegate and move data in, capture events, move it out, it's very, very effective.

[00:02:40]
Now the other thing, speaking of decoupling server communication and state management should be decoupled. The reason being is that what if you're using a mock backend and you want to swap that out, or you're using a production backend, or you want to switch over to graph QL, from a rest API?

[00:03:01]
Well, if you've coupled your state management in your server communication together, that's very hard to do and so remember, avoid coupling, increase cohesion. Data models should be decoupled especially inside of a monorepo with a client and API project. And we are at the tail end here and then we'll take some questions, I've covered a ton of stuff, but do not unnecessarily optimize until you have a good reason to do so.

[00:03:34]
So for instance, a component should not become a lib until it's going to be using more than one app. And so, if you have an application and you have a component that's specific to that, leave it in there. But the minute you have more than one application, and you can share that component, then you extract it out to ellipse.

[00:03:53]
Remember what I said refactor through promotion.