How to structure your Angular apps like a Googler
HTML-код
- Опубликовано: 13 июл 2024
- My modern Angular course: angularstart.com/
In this video, we take a look at how to apply best practice architectural patterns from Nx in a standard Angular applications.
Get weekly content and tips exclusive to my newsletter: mobirony.ck.page/4a331b9076
Learn Angular with Ionic: ionicstart.com
Source code: github.com/joshuamorony/nx-an...
Nx tutorials: • Nx
0:00 Introduction
1:00 Key concepts
2:27 Smart components
3:51 Dumb components
4:42 Data access
5:17 Utils
5:48 Shared code
7:23 Routing
9:10 Conclusion
#ionic #angular #nx
- More tutorials: eliteionic.com
- Follow me on Twitter: / joshuamorony
Join my mailing list for more exclusive content and access to the archive of my private tips of the week: mobirony.ck.page/4a331b9076
Great video! Thanks a lot for creating it. With Angular 14 being out, it is time to update it and replace the SCAM with the Standalone Components :)
Can't wait to implement this in my project that is due tomorrow. Thanks
Audible chuckle
Hi Joshua! good video, I think it was needed, it is a very well explained basis before watching your other architecture videos. Very interesting! Thank you!
Thx for great video! I happy to discover your channel, it's gem!)
Literally went through all comments because I'm obsessed with the proper way to do stuff like this. Yeah I understand recommended practices are not set in stone.
I'm actually liking the structure as it encourages smart -> dumb hierarchy. A few tweaks I want to put out there for possible discussion is;
# Feature specific
(clients | notes)/feature: smart components, pages
(clients | notes)/ui: dumb, reusable components
(clients | notes)/shared/(services | models* | pipes | guards | interceptors)
# Global files
shared/(services | models | pipes | guards | interceptors): for files NOT NICHED to a feature and used globally, or if you can't pinpoint the niche yet and you just want peace so you can refactor later as the app grows and becomes clearer.
shared/(services | models | pipes | guards | interceptors)/(clients | notes): files NICHED to a feature that are USED ACROSS THE APP. Something like a service that fetches clients in the notes page or in some other feature.
*I sort of feel models should just always be in global shared folder and not in feature specific shared folder because the types and interfaces are likely used everywhere and it's one less thing to worry about (if this interface will be imported in another component in a different feature module)
I'm curious - if you are using a folder called shared, why not put the components under /ui under /shared as well, since /ui components are meant to be shared (reusable) anyway?
Thanks josh, will try this folder structure on my next project.
we could make it more obsivous/simple by pulling out the "shell" content - routing.moduel and module to the feature folder iteself
Hi Joshua, thanks for the great video as always! It's just my idea or this architecture works like a charm with a DDD aproach?
i always follows you, good vedio man
Hi Joshua! What about core module and all of that stuff that u need to be initialized with your application?
Thanks for your videos!
What about shared data-access. What we gonna store there. Because as i understand your "ngrx-like" stuff is places inside domain's data-access. And also, how we can use some data-access stuff from domain A in domain B? Thanks!
Hey love the videos and really like this file structure. Using the structure, how do I organise a nested route? So for instance products->id but the detail page has a nested router outlet to show different data on the page depending on the child route so, products->id->child_route_1 or products->id->child_route_2
Amazing video and project structure. How would you structure the project when it's purely standalone with no NgModules, what's your take? Thanks 🙏
Hi Josh, this is really a great video, but I do have a question about it the architecture that I haven't seen in any of your other videos wherever you talk about, how do you deal with shared features (features that depends on other features)? In the context of your video, let's say your "notes" feature can be associated with one or more clients, so somewhere in your "notes add" feature you'd have to show a list of clients from which the user can select from. How would that look like? Should there be a "client list" smart component for each feature that needs to use it? Should there be a shared service specific for loading data for this?
Will this approach have any impact on Performance or is it only for Structuring ?
Do you have a demo project with example code? I would like to see how UI works with this project or how routing works.
Amazing! Are there other structures which you could recommend? It would be great to see alternatives. Also, if you are in need of a quick video idea, you update the video to implement Angular 14 Standalone Components :)
I would also like to see this as well. Searched the channel and couldn't find a video about standalone components
I don't really get what the shell is needed for, is it just used so that the smart components within the feature folder can be lazy loaded aswell? I guess this would be done with loadComponent with the current angular version and standalone components?
Nice video! I guess that you would not use anymore the SCAM pattern for Angular 14 and above having the standalone components available but I am curious if I'm wrong or not about this guess.
Also, what's the advantage of using SCAM? I don't think you mentioned this in this video. For example, why not have a single module that would group a whole feature ? (Possible multiple smart & dumb components, services, utils, .. ). Thanks!
@JoshuaMorony Thank you for your video.
I was wondering how you handle deeper nested features in provided structure.
Suppose that you have an admin feature that contains itself many features like a CRUD user feature.
If I follow your structure, user-list, user-add, user-edit... would be modules.
So the route "admin/user/edit/1" involves 3 lazy loaded modules (admin first, user second and finally user-edit).
How do you handle such a case in terms of folder structure (and even worse when route is composed of more than 3 lazy loaded modules as in the provided example)?
I was wondering that too! The application in our company is an erp-system and we have an awful structure (if you can call that any type of structure). Now we want to use that smart-dumb-component logic, if possible even with nx and all the other features but the questions stays -> how do you rebuild a view which contain multiple features? how do the features communicate with each other?
Instead of creating a separate shell module I'd rather just have the clients/parent feature as a module with router.
having seperate module files is good, because then you can dynamically load modules and all associated imports dynamically
@@danielzaiser I don't think it makes a difference because the exported module from *-routing.module.ts is always imported in the *.module.ts
Btw, how do you manage typescript types with this folder structure?
Great video.
Question about the shared folder.
In your shared code you have a ui/search
Let's say I wanted to use this on multiple pages, but it required some kind of Service for subscription/api calls.
Where is the recommended location for that service/code? Would you create a subfolder in shared/data-access/search? Or would it just be included as a new folder like: "ui/search/data-access"?
Great question - in this case the shared search component shouldn't inject a service because it is a dumb/presentational component, so its parent smart components wherever it is used should be responsible for providing it with data from services.
Interesting, for the shell routing modules, wouldn't it be cleaner to call it 'client-routing-module' instead and maybe keep it in the root folder of that feature?
Hey Hoshua! Since I've seen this structural approach quite often, I was wondering if making the opposite approach would be more beneficial. For example, instead of having data-access, UI, features and utils in every module/feature/functionality that you want your app to have, wouldn't it be better if you'd make the data-access, UI, features, utils etc the main folders/modules and then inside of them to put everything that is related to that? Like i.e. UI to have clients, home etc inside of it.
This is kind of similar to the default approach a lot of people take where all of your components are in a 'components' folder, all services in 'services' all directives in 'directives' and so on. There is a good reason why this isn't done in an Nx context (it makes creating libraries hard) but for a typical Angular application that doesn't apply. I think the main reason not to do what you have mentioned is that it makes it hard to create distinct "features" and the related code won't be co-located. For example, if I am working on the ''clients" feature then it is not immediately visible to me what code is related to that as it is spread out amongst different generic folders.
That's certainly not to say you can't do what you are recommending though. If it works for you go for it and if it causes problems you can change the approach later.
@@JoshuaMorony I see! I'll try the approach you mentioned and see how it goes, because I used the aforementioned for most of my projects! Thanks for your explanation!
Nice stuff, but I'm curios how it will looks with standalone components :)
Can we have higher level modules? For example, the module shop, forum (yes, I have the shop with forum...), delivering, shared(but for higher modules). And in each module implement this architecture. I guess that the best choice is maybe move each high module to a separate project, but it's difficult as we have shared comoonents(more ui). Also we can write this all in one "folder" as in video, but I guess with 10-20 types we could have same problems. Also, it's normal to create a module for each component? It's wouldn't be stressful for performance?
Hi, I have two questions:
Where would you place the models? In the shared folder or directly in the feature folder?
Then, in the utils folder, are you talking about implementing simple export files of useful functions? Or a service?
Thanks!
Hey - I will generally place all of the models/interfaces in a shared/interfaces folder (which does bend the convention I mentioned somewhat) and yes I use utils files for simple ES6 exports
Thank you very much for this excellent and informative explanation. If you had to name or indicate what this pattern is inspired by, what would you say?
6:30 He says Single Component Angular Modules (SCAM).
I'm listening PewDiePie talking about Angular. So cool.
I have serveral question.
1) Where do we put the pipe, directives, guard, interceptor, etc for each feature?
2) Is it right idea to use that same client store for these 3 features (detail, list, survey).
3) what if feature client detail have few features inside it such as client-detail history, cient detail info.
Then would it be something like this.
client-detail
|- data-access
| - feature
|- - client-detail-history
| - - client-detail-info
| - ui
I'm trying to understand Nx project architecture at scale.
Hi Joshua!
How do you handle cases where most of the pages/routes share the same layout? Eg.: the app has a nav bar, a side bar, a main section and footer. All the pages should have the same layout, only the main section to be changed, depending on the route.
Hey - you might be interested in the layout feature I create in this video: ruclips.net/video/8UqbUbLmhG0/видео.html
@@JoshuaMorony Many thanks for the advice. I've ended up using elements in my template and then filling in the desired content with in the actual component.
Place a router-outlet inside the component with the layout. Then add nested routing. That's it :)
Good video, provides already good practices to start with. What I am not sure is, how well this scales on very large applications (my current issue)..?
The example provided is meant for a very simple application which is fine, buy for large ones where do we put all the dozens of child components?
I think this structure is as good as it gets for large applications - if the components are related to a particular feature then they go in the ui folder for that feature. If there is a lot, you could even break the ui folder down into sub-categories if you want. If they are shared, they go in the shared/ui folder, and again, if needed you can break the shared/ui folder down into sub-categories. Is there an alternative approach that you think provides something this structure misses?
@@JoshuaMorony it was basically that what i was thinking. It just was not obvious on the video. Thanks!
Is it intended to nest the features as well? For example if every feature is representing a path in the URL how would you create a structure for something like:
/lists/1/item/edit/2
Here's an example of organising a path in the app with multiple features: github.com/joshuamorony/refresh-app/tree/main/src/app/clients - if a particular route has more than one feature I would have a "shell" feature to orchestrate the routing for that area in the app, and then multiple features for each other path within it. The example I linked for example has a "clients" feature which also has "add", "dashboard", "survey", "detail", and more features. The "shell" feature handles the routing for all of these features so that elsewhere you can just import the single "client-shell" feature to pull in everything.
Thank you! What about guards, interceptors... And where could a login page live?
I would typically have a login page in its own feature folder, and for guards/interceptors I usually create a separate folder in shared e.g. shared/guards and shared/interceptors. I usually stay pretty strict with the data-access/utils/ui folders within individual features, but often in the shared folder I will make some exceptions where it makes sense.
Hi, Joshua great tutorial. I have a question based on efficiency. I tend to have services that I use in multiple components. Instead of injecting the services into each component, I use a "master service" that I inject all shared services into and create wrapper functions for each service then only inject that master service into each component. My question is, is it a bad idea and what are the implications of doing that.
This is a common pattern, people sometimes refer to services like that as a "god" service, I think it is fair to say that it is an anti-pattern/bad-practice though. I think it probably does have some negative effects in terms of tree shaking - since everything is imported in this one service then I think Angular is going to assume everything is being used (but I'm not really that sure on the exact mechanics of tree shaking). Mostly though it just isn't a great approach from a software architecture perspective - in general we want the pieces of our application to "know'' as little as possible, this makes everything more modular/loosely coupled and adheres more closely to the ''single responsibility" principle. If you have a single service that does everything, then it would be violating a lot of these principles.
But, if it works for you and your circumstance then maybe that's ok. Not everything needs to be perfectly designed.
IMO, one or two data service per component is fine. But if there are many services imported into a component, than component is doing more than one job.
If a data service is imported in more than one component, than smart/dump component pattern isn't used well.
Implications are that, providedIn: 'root' will lazy load the service, if it's included in lazy loaded module. But a master service will break the tree shaking
@@JoshuaMorony I figured as much that it would have a negative effect on tree shaking. Thanks for the response.
@@SamiullahKhan I use firebase in my project and my data service just wraps some of the crud services from angular fire v7. This service is used in every smart component to interact with firestore. Will injecting it in each component not result in the same thing? Also, does this apply to services such as the Form builder service or the router service or an analytics service? These are not necessarily data services hence the reason for creating a master service.
Hi Joshua, what about model, interfaces, constants, directives and pipes
I'll copy my response to someone on Reddit that had a similar question - generally I find that I will stick to those 4 folder types for features (if a model/interface was just for that feature than I would have it in the data-access folder most likely), but for shared things I might create additional folders in the 'shared' folder:
"The approach isn't so rigidly restricted to just those 4 folder types, you can expand if it makes sense. For a model I might just have it exported from the store in a data-access folder in that feature, or if it makes sense you could have a dedicated "models" folder. If it is a model that is shared throughout the app, then I would put it in the shared/models directory.
Similar approach for directives and everything else. You could just put your directives in the 'ui' folder for a particular feature if that makes sense, or maybe you want a dedicated directives folder. If the directive is shared outside of a feature then it can live in shared/directives/my-directive or if you have a lot of shared directives may you break that down into more specific grouping folders: shared/directives/some-group/my-directive.
For anything getting to the higher end of the complexity scale I would just use Nx anyway, but this general structure is used in Nx and it specifically caters for massive/enterprise apps."
@@JoshuaMorony ahh! That makes sense 👍 .. Thank you for your Efforts❤... Great Video and explanation
what would be the architectural approach, if you wanted to use this general structure, but reduce the amount of files per new feature / ui component added?
Would it be worth thinking about:
- only having a single file per component (ts)
- handle styling in a parent component
- handle testing in a parent component
- have the html done in a seperate html helper service, where you define templates for your components and use data as context
Possible benefits would be reducing overall amount of files.
I am thinking on a application scope, where you would potentially have thousand of components
So in general, ui/dumb components would never interact directly with ngrx (call to actions or selectors), this is a responsibility of the feature component. The page might be complex and made up of sub-features that might need to interact with ngrx. Should we add subrouted features? How would you handle it?
Curious about this as well. In my limited experience, I just let the 'dumb' components talk to the store whenever needed. If the store needs to know a button is pressed, the dumb component just talks directly to it instead of @outputting it to its parent smart component, who then calls the store with the same information. Will probably depend on the situation what is best
but do you still export feature components right? to cover situations like 'some modal of feature A needs to be opened in a feature B'
also, where do you put auth stuff?
Anything that is accessed outside of a particular feature goes into the shared folder. So if Feature B needs to access something from Feature A, then whatever that is in Feature A will be moved to the shared folder. If only stuff within the auth feature will access auth stuff then it can all go in the auth feature folder, but if you need other features to access one of the auth services, then that service would go in the shared/data-access folder.
This is all my opinion of course, you can do whatever suits you best!
@@JoshuaMorony Thank you very much. I actually want to try this approach. Last question, where do you put models files, pipes and directives? I assume that client.model.ts could probably stored in /clients/feature next to files that use it but what about models, pipes and directives used thruout the app?
@@John69 I typically have models/interfaces in their own dedicated folder in shared (e.g. shared/interfaces), and I will typically put pipes/directives in the ui folder of a feature (or shared ui if it is shared)
Hey Joshua, I really love your channel, your takes on angular and how you explain them. Thanks for your videos.
I am asking myself how one would structure an ngrx project "like a Googler".
Do you have a Link or Documentation where I can read about that or even a video of yours?
My idea was to add a folder "state" (with files clients.actions.ts, clients.reducer.ts, etc.) as a fifth library type. But is there a standard way to do this?
Thanks in advance!!
I don't know of a specific resource with this style and NgRx Store, but a separate state folder is fine if you want - it would also falls quite neatly into the role of a data-access folder so you could put it there as well if you want (or you could even have data-access/state) - whatever works for you!
@Joshua Morony @Marvin Frede Wouldn't state be the store service?
If I need another smart component that will be used for example in client-details component, do I put it as another feature but I do not route it? I'm trying to learn SOLID so it kinda bothers me to create one smart component that will do many things.
Yes this is what I would do, if you want a routed smart component that contains another non-routed smart component, I would have them both in the feature folder. Generally I don't find I need this, but there are certainly apps that are going to be complex enough to warrant it. Generally in terms of SOLID I don't see the smart components as breaking the single responsibility principle by doing many things, I see a smart components "single responsibility" as being orchestrating the data flow to/from all of its child components.
Thanks for reply. I didnt think about Smart component in that way but you definitely have a point. Another question popped in my head while trying to understand Nx approach. What about environment variables from app? How do you pass it to libs modules?
@@JoshuaMorony In as much as I've read practices about keeping folder structure flat, I'll probably put it in the client-detail folder especially if I know that's the only place it's used. I can easily locate it this way if the "clients/feature" folder has many more top level features or pages
If you had an API client generated by Swagger, would that go in a shared/data-access/api-client folder?
I don't use Swagger but yes that seems like a likely spot if it is going to be accessed by multiple features
Just living your channel. Every advanced angular video I ever wanted.
On question though. Why naming the folder "client-shell". Since there's only routing in there? Why not "client-routing" for example? I'm wondering if you named it like that to include another file not related to routing in it and just didn't talk about it.
This is just another convention I've brought over from Nx (not sure if this one was in their "official best practices" or not). I like to keep things consistent wherever possible, so in this situation any feature that has multiple smart/routed components will always have a "*-shell" which is basically "import this things module in the root module to set up this feature". Sometimes it might have more than just routing information, so I like "shell" to indicate this is the thing that basically contains/setups the feature. But this is just personal preference stuff.
Hi Joshua, first of all, I like your content and explanation concept.
I am still new to Angular so trying to figure out the best way to structure things in the application.
I have a question, let's say in your example you have clients and a corresponding folder for them and now I wanted to build a client select component that can be shared in many other parts of the application, and this shared component can have multiple or single select, mybe some initial filtering depending on @Input data or mybe some special directive attached to it.
First where to put that component? In a shared folder or client folder, second I would like that component to be smart, so the component itself uses client service to fetch a list of clients and to filter based on select input.
Where and how would you create this "shared" component, smart or dumb (passing list from component that using it) , where to put it in structure folder.
Tnx for the awesome videos !
There's no strict rules so ultimately you can do whatever suits - but within the context of what I am talking about in this video, I would put anything that is shared outside of a single feature in the 'shared' folder - so yes, that is where I would put your hypothetical component. You could make it dumb if you like and have the parent responsible for passing in inputs, but you could also make a shared 'feature' component too if you like, e.g. at shared/feature/some-component. A lot of the time you are just going to have these two tiers of smart and dumb components, but with enough complexity it might make sense to have more layers of smart components, e.g. smart -> smart -> dumb. I hope that helps!
@@JoshuaMorony thank you .. was kinda thinking the same, probably it would be better it is dumb and fed it with data from the parent component, but i know i will use it in like 40 places( bookings, finance documents, reports, exports ....) inside the application so providing values from it in each parent is tedious that's why I was thinking to go with smart component and have injected client service to be able to lug it anywhere without line of extra code .. and now question is about client service since it is on client folder should it be better to create new one in shared or use one from client folder ?
@@Cvijo123 Since it is being accessed by non-client features I would move it to the shared folder. If your shared folder is quite populated then it might make sense to do something like "shared/data-access/clients", but again, see what works for you!
@@JoshuaMorony I guess a suggestion to the convention can be that the global "shared/data-access" can be for general services used across the app that probably can't be pin pointed to a sector in the app while "shared/data-access/clients" can be for services used across the app that are niche to clients sector...like if you need to fetch clients in other parts of your app.
@@JoshuaMorony Hmm, so if I understand this correctly, to maintain smart -> dumb hierarchy, it'll be "shared/feature/some-component" and "shared/ui/some-component" where the latter is used in the former. The service is injected in the former and the former is reused anywhere.
In their component classes, what can be a naming convention for their selectors?
i like this structure, the only thing what´s missing is interfaces. where should they be stored if i want to use them in multiple components/services. normally i name it like my-custom-interface.model.ts. Is the shell directory the right place?
I typically have all of my models/interfaces in a single shared/interfaces (or shared/models) folder
Do you mean the global shared folder or a shared folder inside of the “clients” (as an example ) directory ?
@@DanielStoehr203 either way is fine you can scope it to a particular grouping folder if you want, but typically I just put all of my interfaces in the global shared folder
The only thing I am slightly unsure of is if you have shared code that you wouldn't want any feature module to have access too. I know in nx you can setup architecture boundaries, but if every feature can access shared, how would you share something with only a handful of features that need that capability? I have seen it called business capabilities in the past. the shared capability might be data access/utilities/components etc that define that capability, but you would only want that capability accessible by a handful of features.
One thing I've done with this structure (this was with Nx but I wasn't using module boundaries) is to further segment the "shared" folder to group things that are shared with a specific set of apps/features - so you could have "shared/whatever/data-access". I only really see these as "suggestions" anyway - there isn't anything about this structure that enforces access, if that is important then I think using Nx and module boundaries is the way to go.
With ng-14 does it make sense all the UI components to be standalone?
Yes for sure, I'm using standalone for everything now
@@JoshuaMorony For everything? Me and a colleague are considering using standalone for refactoring some stuff, but we ended up with the conclusion that we should use shandalone only for UI pieces. Isnt there a downside for everything to be standalone rather than some components being packed in a module which can then be easily imported as a bundle to use immediately?
@@SkyLordPanglot if you need to bundle some things together you can still do that just by exporting a normal array that has all of the standalone components you want to group inside of it
IME structuring for "click-folder" is not the way to go. JS files are modules (not talking about NG framework). I rather prefer to get bigger .ts files and use symbol search. Therefore, you reduce imports a lot.
The only thing that irks me about that structure is the use of the o word, “feature”. It’s too ambiguous. A single routine component is not a feature, it often represents many, many features.
I think page or screen makes more sense.
Does this "pattern" has a name?
I did this and never checked Nx before 😂
This is more of a react app structure
There's no use of Nx in this video, so I'm not sure why it's even mentioned.
It uses the library structure encouraged by Nx (feature/data-access/ui/utils) for Nx workspaces, but just as normal folders not Nx libraries (and obviously not in an Nx workspace)
you didn't provide a clickable example so we could follow your movements over directories? that's a pity.
Right, but Apple tell - think different than Google.
Hehe angular
Do you think people should not use Angular?
@@JoshuaMorony Having 6-7 files to define one component does not seem fun. I also have to say nowadays the technology used is rarely a limiting factor.
@@IvayloKorakov You can define an Angular component in one file if you want (this is what I do) or you can split it up into multiple files. Is there any other reasons you think people should stay away from Angular?
I dont like this structure 😢
Me neither pal
Gotta 2 questions about how would you use as the best way to folder your services in those scenarios:
- Feature A requires to add a new page named as "Client List" and then probably you would have your clients.service.ts (I imagine it would be under clients folder where you gonna use to get list of clients.
- However, now "in the future" just came up a new page that you need to add called payments and then you would need to access your clients-service under clients folder. What would you do in this situation? Would you move your client.service.ts under shared/services folder? or you only create payment.service.ts and would inject your client.service.ts into this new service now?
I would say don't movie the file. Use client service in your payment service instead.
@@vikaskyatannawar8417 But doing that way, we are going to have ../modules/clients/clients.service.ts imported into ../modules/payments/payments.service.ts. In theory it would be kinda messed bcuz now we have a service from clients module imported into payments module somehow isolated. Is it keep being ok?
watching this video made me realize just how "dotnet-ified" most angular apps I've seen are lmfao