Angular 13 Fundamentals Angular CLI Structure and Q&A
Transcript from the "Angular CLI Structure and Q&A" Lesson
>> So questions, how do I know what is happening within, under the hood of the English COI. What is it doing? So it will, for instance, tell you if you're generating something that, you've generated these files are installing these tendencies. So there is a verbose flag. And, the reason why I love doing these workshops, Is because I get to try things on the fly.
[00:00:29] So the question is, or rather the request is, could I give a quick overview for best practices on file structure? And so let me start with a little asterix, a preemptive caveat that there are a lot of things where it's not black or white. It's not cut and dry.
[00:01:00] And so, I want to be careful or at least if I put forth an opinion, I want to at least indicate that this is my opinion and I have met individuals that they are so absolutely militant and religious about these ideas about, this is how you code. And they are one, I just wonder why they programmed because it doesn't seem they're having very much fun which really defeats for me the greatest joy programming is that I enjoy it.
[00:01:38] But that they're so hung up on these little things, I don't know, tabs versus spaces, semi colon versus not. That we missed the fact or the I think the underlying drive, or impetus of programming is that we program to create things that people love. And, we make decisions that accelerate our ability to do that and to keep doing that.
[00:01:54] And there are things that fall within the realm of purely preferential like stylistically. This is what makes sense to me. And in some cases, in my case, I can't explain why. So, with that said, some of this is my opinion. And so take it as such that, I believe in functional cohesion in the sense of when you organize your file structure.
[00:02:41] And I believe the angular style guide says as much that organize, at least within your component layer by feature. And so if I'm creating a courses feature with my components that I'm going to put that in a courses folder, and then if I have a Courses list Component that's a child of that.
[00:03:05] I'm going to put that as a child into that particular subfolder. The reason being is because functionally these components logically belong together. But if I have something that needs to be shared across multiple components, then I promote that to a slightly higher abstraction. So something that needs to be shared between two separate features.
[00:03:39] That, let's say a courses service but, two different features need to consume that, a home component and a courses component. That needs to be promoted to a slightly higher abstraction or a common abstraction, which is why I would put that in a common folder. From there, I would then organize that by type.
[00:04:01] So all of the code that's responsible for communicating to the server would go into a services folder. And now the reason why I would put an interface into a common folder, is because I could assign that type or consume something of that type in multiple components within the application.
[00:04:25] So if I knew for a fact that this course type for instance is only ever going to exist within these three templates, I would consider putting it in there. But because I know that I may want to display courses on in the home component. What I don't want to do or I want to avoid is being or forcing a subcomponent to have knowledge about its siblings.
[00:04:56] And so you never want to reach across and have knowledge about any sibling players within the application. So for instance, I don't want the home component to know anything about the courses component. As a result, anything that is shared between them I have to extract to a higher level.
[00:05:17] And so you want to delineate things in a way to where it has just enough knowledge to do the thing that is designed to do and nothing else to have knowledge of something that you shouldn't. What that does is that creates a situation where things are cobbled together, which really, really will end poorly.
[00:05:39] I think that if using things like nested or hidden state nested logic and breaking the single responsibility principle to me, this is the axis of evil and there's a much larger conversation you'd have there. But what these represent and the majority of what I see in code is a result of the simple violations which is a product of coupling.
[00:06:07] So I think if violating the single responsibility principle having hidden state and nested logic In your code, if that's the axis of evil, coupling is the antichrist of code. And so you wanna organize your code in a file structure that eliminates or reduces coupling while promoting cohesion or logical grouping.
[00:06:32] So, this is why I would put interfaces in a common folder, such as common models, you could call it whatever you want. I've seen a call core. So some of the naming conventions is not as important but the asking yourself, is it possible that this thing and this thing right next to it adjacent to it could use it?
[00:06:54] If so, then promoted and refactor that through promotion. Now, we're in bonus time here is that if I were building a large scale, like enterprise style application, that I would actually use norwall NX dev tools to do that. Which allows me to have multiple applications, separate core functionality into libraries or libs that I can then share.
[00:07:26] And so it gives me a higher degree of I think cohesion and in organization and annex for Angular is it just essentially sits on top of the Angular CLI. The reason why I don't talk about it in a Fundamentals course is because my experience is that that's just an extra layer of complexity that is just creates additional confusion.
[00:07:53] So I recommend checking out NX. That is kind of the rule of thumb is that organized by features, if something is common or shared across features, promote it, and then I typically will organize by type. So the question is should services hold the majority of application level state?
[00:08:14] I'm a huge fan of NGO RX, which is fundamentally services. It's broken up into a few different pieces. So I think your application state should live outside of your component layer entirely. So whether you use a service with a subject or I recommend using a proper state management library.
[00:08:42] I'm a big fan of NCR RX. But if I'm doing react I'm using Redux on there's Akita, there's a number of different things is that ultimately your state management, your Application statement if it will end up in some sort of a service that is consumed. And then your command and query cycle is then made available to your components.
[00:09:06] So the answer is yes with it with kind of an Asterix is that that is determined by whatever state management tool you happen to be using. I recommend NGO Rx, but the one thing I will say is that make sure you delineate or differentiate between presentation state and application state.
[00:09:29] Because I've seen people who are aggressive about state management or they'll put any form of state into their state management library. So for instance, use this button enabled or disabled, or when I fill out this form, it's immediately being processed by the state management library. I don't recommend that because what you're doing is you're inappropriately promoting presentation state into application state.
[00:09:56] Whereas, if I'm filling out a form I only care about what's going into that form when I submit the form. Or I indicate hey, I want to save this object. So this is when I think this is maybe what you were getting out with the question. Most state i.e all application state should be segmented into a state management layer.
[00:10:21] But, presentation state should be encapsulated within the component itself.