I think the Component and Directive suffixes were noise before, but for me, they were always hidden by the modules. I just imported the module, used the selectors and never thought about it. As I'm moving to standalone, I'm noticing the noise more in my imports -- perhaps that is what's driving this. Ultimately, I like this convention. I strayed from component suffixes if my component was a page, I'd use .page.ts for that sometimes. I don't think I'll ever drop this convention - it just makes sense even with the little noise. For sure, service, model, client, utils, and others are definitely here to stay in my codebase.
Great presentation and summary! I love my selectors and really hope the Angular team doesn't try to get rid of them with their PascalCase in our HTML. Control flow syntax to get rid of unnecessary divs and containers was a welcomed change! Not getting rid of selectors. Maybe they should lean into the selectors instead of shying away from it. I'd love to see more vanilla HTML leveraged in the Angular world.
Thank you for a good explanation. And you have a good voice, easy to listen to and understand, it seems like you have taken classes in elocution and diction.
Yeah I suppose this naming convention has always been a form of reverse Hungarian notation and with a fresh perspective do seem superfluous. Great job as always!
This is a tactical change to make, but I believe it will be beneficial in the long run. it's a good idea, so it should be very well thought of and implemented
I feel that this new naming convention is unnecessary and it makes file search in the IDE more difficult. Also, I agree with your comment that this is creating more conflicts. 😄
Changes are coming always, the question is, will developers adjust to this? Another thing, some extensions from VS Code, e.g., Material Icon Theme, I believe they use the name in the file to change the icon. If that became true, they will have to adapt. Thanks for your content Deborah. Always with great explanations.
Thank you for watching. Micro frontend isn't my area of expertise. Manfred Steyer is the expert in that area. Here is one of his videos: th-cam.com/video/FQ4noDp_AGI/w-d-xo.html He's also done e-books. You can get that here: www.angulararchitects.io/en/ebooks/micro-frontends-and-moduliths-with-angular/ All the best -
Funny how conveniently you introduced (twice) the angular forum. It's like you're expecting people not taking this one well. =D I'm fine with the change of component name and I'm having trouble to understand why this would be a helpfull change for services ( maybe I should read the article =D), at the end its like we are just switching suffixes, but I guess I don't mind.
LOL! Yes, I'm not convinced of the need for removing the suffix on a service. In almost all of my apps, the .ts is always the interface and the Service.ts is the service that manages that thing. I don't see how changing it from "Service" to "DataClient" does anything to move Angular forward.
@@deborah_kurata I agree. I like the component change, but I don't like the DataClient suffix idea. I don't mind dropping the Service suffix either, though. I kind of like the brevity and readability of that when consumed. Instead of `this.productService.update({...})`, it would be `this.product.update({...})`. I guess we could leave the Service suffix and just name the component property product when we inject it, though.
Feels like a convergence towards a more React-type of convention here - in fact a lot of the frameworks seem to be becoming more similar in that regard
I find this to be a super odd comparison. Pretty much every framework has conventions like this (react, svelte, vue, solid, preact). This seems to be the prevalent (and preferred model in the front-end space at large). Angular has been the odd one for years now. I want Angular to keep the features that separate it from the rest like dependency injection, the angular router, built-in interceptors, etc. But I'd like to see the Angular team take what other frameworks are doing well and adopt those patterns too where they make sense. I think this is a good change
I dont know if its a case of who moved my cheese but initially i dont like it. Perhaps without module files this could work. I use it to quickly know which one to auto complete and the ide uses it for its custom icon. I suspect this will cause name clashes with people that use ionic pages. The data client is not something ive ever heard used before, interested to know the reasoning behind it as it is longer. Maybe im misusing it but not all of my services are just data. I've got formatting services, and sometimes split into multiple layers with a facade class first for business logic then a data class behind that. And in some components that were getting a bit big i have made services that are not injected into root, just to clean up that component. Realistically is there naming change going to make any improvement to our learning curve? If you only care about a users first demo experience then... Maybe.... But for the next ten years or so any pro dev is now going to have to juggle both because they will certainly end up supporting some older projects.
Hey there, thanks for the video. I am not a big user of Angular. UserListComponent -> UserList. Isn't then the next step to remove the "List"? Isn't it just a "Users.ts" in the end? But this would make all components probably very short.
Thank you for watching the video! If you have a User component, and a User service, and a User file containing the interfaces all without any suffix, then you have: UserListComponent -> users.ts UserService -> users.ts User (interfaces) -> users.ts There needs to be something to differentiate the file containing the interfaces, the service, and the component/template for a particular feature.
I think its a good change dropping the component suffix, but only that, because component gives an idea of concrete object, and most assume something gonna be a component. Thats not true with dropping service suffix though. Calling “product” a service is counter intuitive and confuse. Same to directive or other suffixes
My thoughts exactly. For the components they are suggesting making it more specific, like product-list instead of just product. And for services added the "dataClient", which doesn't seem better than "service". 😊
Component Name is a good change since we will also use it as a selector name. Services that is not necessary in my opinion, UserService to UserDataClient.
Yeah, I agree. I don't like the -DataClient suffix. That seems like an odd suggestion. I like the idea of dropping the -Service suffix on new projects but for old projects that could cause a bunch of naming conflicts. In that scenario, why change it from -Service at all? Weird. I like this in new projects because of the brevity and readability, though. When I consume service methods, it would read like `this.product.fetch()` or `this.product.update({...})`. I still name all of my type files something like `product.model.ts` anyway so I won't get the conflict there.
I do like the new component selector convention. There's no need to suffix a component with "component" because we know by it's very nature that any directive with a view is a component. The file naming convention change is good too aligning with other popular modern frameworks which prioritize visibility over verbosity. I do not like the "data client" change since it is more verbose although I do understand their desire to more explicitly define what data and logic should go into a service. Many engineers even senior engineers I've worked with have struggled to understand the purpose of a data access layer and why separating the feature services from the services responsible for communicating with the backend.
the removal of suffixes in files and class names is heavily discussed in the RFC, it reduces discoverability, adds ambiguity, and breaks a lot of linters and co. The only real reason this is pushed is the jsx-fication attempt of getting selectorless. I really despise this changes (also the entire discussion of authoring format).
I can see the change to the component name if indeed they plan to use that name instead of the selector. But I'm not a fan of changing the service name. Thanks for your thoughts!
Standalone components were introduced in Angular v14. As of Angular v19 (released November 2024), standalone components are on by default. Standalone components no longer have "forRoot" and "forChild". If you still have to support NgModule-based components, then you still work with "forRoot" and "forChild". In general, if you have a single in one component, you use "forRoot" to define your routes. If other "child" components also have a , you use forChild to define those routes. Is there something more specific you have a question about?
LOL. Their job is to continually improve Angular and keep it up to date with current trends. Their current goals include "reducing boilerplate code" and this is one way they hope to achieve that. Even though I don't agree with this particular naming suggestion (at least not fully), I don't think they've been wasting their time.
Hello Deborah, Thank you for providing this wonderful and valuable content. Could you create a simple project to bring this information together using the latest version of Angular? The content on TH-cam is very limited and also outdated
@deborah_kurata Thank you for your response. What I mean is long videos that focus on building a simple, realistic system that integrates all these concepts, along with implementing full CRUD operations using an API, so we can learn how to connect everything in large, real-world projects.
I have mixed feelings about this new naming convention. While I can understand some of it's motivation, I find this new convention will introduce more variability in the file names than what we have now. We will lose consistency accross different projects name structure, making the switch to new projects harder than what we have now. At glance, anybody can tell that a ".component.ts" file contains a component or that a ".service.ts" contains some kind of injectable service. When I see user-list.ts or user-data-client.ts it is less clear what one can find inside such file, and I note that this isn't even a rule but more of an example so the naming will vary from one project to another... I also find the argument about the selector to be a bit of a stretch, because nothing would prevent a CartListComponent to have a CartList selector set automatically, the compiler would only need to get rid of the "Component" part in the name...
Thank you Deborah, your videos are as always a pleasure to discover and follow along. Concerning Angular team : do they take us for sheeps ? thinking that every time they change their minds, we will follow stupidly without thinking, they would like to give themselves the right to think for us! We can and know how to think by ourselves, let's prove it to them. I reject these suggestions, no interest. Then tomorrow what will be next, "oh finally using signals effects is not a good thing", what else? They showed us that they can be wrong, which is normal, so following them is not the systematic way to go, and i hope people will prove them that we are the final judge. Do these guys think they can rule the world ?
Thank you for the kind words about my videos. 😊 Please consider commenting also on the RFC. (But know that they are developers like us, so please be kind but clear on your concerns. Also, many developers frequently *ask* the team for guidance on best practices, so this isn't meant to be autocratic.)
Angular should just fork itself and create a new framework name for itself. It's unrecognizable and certainly not in the direction majority of the users want.
disagree, i still think having those suffix is better, how on earth would you know its a component straight away without opening that file and check whats in there? The angular team definitely have too much time on these useless stuff.
@@deborah_kurata checking the way the RFC is commented and voted on (by emojis) it seems to go the way elections tend to go these days, picking the bigger evil. :(
This is such a terrible idea. Getting rid of suffix conventions in order to have everyone make their own suffix conventions. Way to kill off any chance of newbies to understand the code base. I like the idea of class name selectors, but a few more characters will not destroy this. And if you absolutely need it, by convention the tag parser could just omit a Component suffix automatically, without forcing you to ruin class and file names.
The future change you mentioned to use classnames instead of selectors is a change I very much look forward to
Me too!
I think the Component and Directive suffixes were noise before, but for me, they were always hidden by the modules. I just imported the module, used the selectors and never thought about it. As I'm moving to standalone, I'm noticing the noise more in my imports -- perhaps that is what's driving this. Ultimately, I like this convention. I strayed from component suffixes if my component was a page, I'd use .page.ts for that sometimes. I don't think I'll ever drop this convention - it just makes sense even with the little noise. For sure, service, model, client, utils, and others are definitely here to stay in my codebase.
Great presentation and summary! I love my selectors and really hope the Angular team doesn't try to get rid of them with their PascalCase in our HTML. Control flow syntax to get rid of unnecessary divs and containers was a welcomed change! Not getting rid of selectors. Maybe they should lean into the selectors instead of shying away from it. I'd love to see more vanilla HTML leveraged in the Angular world.
Thank you! And be sure to add your comments to the RFC!
Thank you for a good explanation. And you have a good voice, easy to listen to and understand, it seems like you have taken classes in elocution and diction.
That is very kind of you to say. Thank you!
Yeah I suppose this naming convention has always been a form of reverse Hungarian notation and with a fresh perspective do seem superfluous. Great job as always!
Thanks!
This is a tactical change to make, but I believe it will be beneficial in the long run. it's a good idea, so it should be very well thought of and implemented
Yes, it would be interesting to know more about why the names of services need to change. What the tactical reasoning is.
Let's maintain UserService or the service prefix but I'm okay with the component prefix removal.
Please share that suggestion on the RFC. 😊
I feel that this new naming convention is unnecessary and it makes file search in the IDE more difficult. Also, I agree with your comment that this is creating more conflicts. 😄
yeah no kidding. especially on a enterprise app with several micro front ends
"Make your voice heard". I like it. Thank you Deborah ☺
😊 thank you
I agree the service suffix provided a better meaning rather than current convention.
Why don't we change the name of the framework from Angular to React?
I thought the same.
Changes are coming always, the question is, will developers adjust to this? Another thing, some extensions from VS Code, e.g., Material Icon Theme, I believe they use the name in the file to change the icon. If that became true, they will have to adapt.
Thanks for your content Deborah. Always with great explanations.
Yep. Thank you!
thanks Deborah, will you focus on microfrontend soon? Uses alot of what you already published.
Thank you for watching.
Micro frontend isn't my area of expertise.
Manfred Steyer is the expert in that area. Here is one of his videos: th-cam.com/video/FQ4noDp_AGI/w-d-xo.html
He's also done e-books. You can get that here: www.angulararchitects.io/en/ebooks/micro-frontends-and-moduliths-with-angular/
All the best -
as long as I can control the ESLint rule that determines whether or not I can use `UserService` as a class name, then Angular may stay.... 🤔
Funny how conveniently you introduced (twice) the angular forum. It's like you're expecting people not taking this one well. =D
I'm fine with the change of component name and I'm having trouble to understand why this would be a helpfull change for services ( maybe I should read the article =D), at the end its like we are just switching suffixes, but I guess I don't mind.
LOL!
Yes, I'm not convinced of the need for removing the suffix on a service. In almost all of my apps, the .ts is always the interface and the Service.ts is the service that manages that thing. I don't see how changing it from "Service" to "DataClient" does anything to move Angular forward.
@@deborah_kurata I agree. I like the component change, but I don't like the DataClient suffix idea. I don't mind dropping the Service suffix either, though. I kind of like the brevity and readability of that when consumed. Instead of `this.productService.update({...})`, it would be `this.product.update({...})`. I guess we could leave the Service suffix and just name the component property product when we inject it, though.
Feels like a convergence towards a more React-type of convention here - in fact a lot of the frameworks seem to be becoming more similar in that regard
It seems that the Angular team is interested in improving Angular wherever possible, taking the best from other frameworks.
@@deborah_kurata but jsx style this isn't an improvement
Great observation
I find this to be a super odd comparison. Pretty much every framework has conventions like this (react, svelte, vue, solid, preact). This seems to be the prevalent (and preferred model in the front-end space at large). Angular has been the odd one for years now. I want Angular to keep the features that separate it from the rest like dependency injection, the angular router, built-in interceptors, etc. But I'd like to see the Angular team take what other frameworks are doing well and adopt those patterns too where they make sense. I think this is a good change
I dont know if its a case of who moved my cheese but initially i dont like it.
Perhaps without module files this could work. I use it to quickly know which one to auto complete and the ide uses it for its custom icon.
I suspect this will cause name clashes with people that use ionic pages.
The data client is not something ive ever heard used before, interested to know the reasoning behind it as it is longer.
Maybe im misusing it but not all of my services are just data. I've got formatting services, and sometimes split into multiple layers with a facade class first for business logic then a data class behind that. And in some components that were getting a bit big i have made services that are not injected into root, just to clean up that component.
Realistically is there naming change going to make any improvement to our learning curve?
If you only care about a users first demo experience then... Maybe.... But for the next ten years or so any pro dev is now going to have to juggle both because they will certainly end up supporting some older projects.
Agreed!
Hey there, thanks for the video. I am not a big user of Angular.
UserListComponent -> UserList. Isn't then the next step to remove the "List"? Isn't it just a "Users.ts" in the end? But this would make all components probably very short.
Thank you for watching the video!
If you have a User component, and a User service, and a User file containing the interfaces all without any suffix, then you have:
UserListComponent -> users.ts
UserService -> users.ts
User (interfaces) -> users.ts
There needs to be something to differentiate the file containing the interfaces, the service, and the component/template for a particular feature.
I think its a good change dropping the component suffix, but only that, because component gives an idea of concrete object, and most assume something gonna be a component.
Thats not true with dropping service suffix though. Calling “product” a service is counter intuitive and confuse. Same to directive or other suffixes
Agreed! 😊
how we would import component, directive and service with same name in one file?)
My thoughts exactly. For the components they are suggesting making it more specific, like product-list instead of just product. And for services added the "dataClient", which doesn't seem better than "service". 😊
Component Name is a good change since we will also use it as a selector name. Services that is not necessary in my opinion, UserService to UserDataClient.
Yeah, I agree. I don't like the -DataClient suffix. That seems like an odd suggestion. I like the idea of dropping the -Service suffix on new projects but for old projects that could cause a bunch of naming conflicts. In that scenario, why change it from -Service at all? Weird. I like this in new projects because of the brevity and readability, though. When I consume service methods, it would read like `this.product.fetch()` or `this.product.update({...})`. I still name all of my type files something like `product.model.ts` anyway so I won't get the conflict there.
I do like the new component selector convention. There's no need to suffix a component with "component" because we know by it's very nature that any directive with a view is a component. The file naming convention change is good too aligning with other popular modern frameworks which prioritize visibility over verbosity. I do not like the "data client" change since it is more verbose although I do understand their desire to more explicitly define what data and logic should go into a service. Many engineers even senior engineers I've worked with have struggled to understand the purpose of a data access layer and why separating the feature services from the services responsible for communicating with the backend.
the removal of suffixes in files and class names is heavily discussed in the RFC, it reduces discoverability, adds ambiguity, and breaks a lot of linters and co.
The only real reason this is pushed is the jsx-fication attempt of getting selectorless.
I really despise this changes (also the entire discussion of authoring format).
I can see the change to the component name if indeed they plan to use that name instead of the selector.
But I'm not a fan of changing the service name.
Thanks for your thoughts!
100% agree with you!
Hello. please explain the pattern forRoot and forCHild
Standalone components were introduced in Angular v14. As of Angular v19 (released November 2024), standalone components are on by default.
Standalone components no longer have "forRoot" and "forChild".
If you still have to support NgModule-based components, then you still work with "forRoot" and "forChild". In general, if you have a single in one component, you use "forRoot" to define your routes. If other "child" components also have a , you use forChild to define those routes.
Is there something more specific you have a question about?
@@deborah_kurata Thank you. no, there are no specific questions, the mechanism of how these patterns work was interesting
I like this new change, once again, it feels more like React or VUE
I'm sure the team is getting a lot of negative feedback, so leaving a more positive response to the github issue would be nice for them. 😊
UserService -> UserDataClient looks more verbose
Agreed!
Using *DataClient not making any sense if we using services for state management using Rxjs
But more meaningful, but then again I haven't looked at the naming examples of other services that aren't data clients.
Please keep Service as a suffix
Agreed. But it's not my decision to make. 😊 Please make your voice heard on the github issue. Then the Angular team will see it. Thanks!
It seems like the angular team has a lot of free time
LOL.
Their job is to continually improve Angular and keep it up to date with current trends. Their current goals include "reducing boilerplate code" and this is one way they hope to achieve that. Even though I don't agree with this particular naming suggestion (at least not fully), I don't think they've been wasting their time.
Hello Deborah,
Thank you for providing this wonderful and valuable content.
Could you create a simple project to bring this information together using the latest version of Angular?
The content on TH-cam is very limited and also outdated
Thank you for the kind words.
Are you referring to some type of "build along" video, or just a sample project in github?
@deborah_kurata
Thank you for your response.
What I mean is long videos that focus on building a simple, realistic system that integrates all these concepts, along with implementing full CRUD operations using an API, so we can learn how to connect everything in large, real-world projects.
I have mixed feelings about this new naming convention. While I can understand some of it's motivation, I find this new convention will introduce more variability in the file names than what we have now. We will lose consistency accross different projects name structure, making the switch to new projects harder than what we have now. At glance, anybody can tell that a ".component.ts" file contains a component or that a ".service.ts" contains some kind of injectable service. When I see user-list.ts or user-data-client.ts it is less clear what one can find inside such file, and I note that this isn't even a rule but more of an example so the naming will vary from one project to another...
I also find the argument about the selector to be a bit of a stretch, because nothing would prevent a CartListComponent to have a CartList selector set automatically, the compiler would only need to get rid of the "Component" part in the name...
Yes! Consider suggesting that in the RFC if you have a moment.
Thank you Deborah, your videos are as always a pleasure to discover and follow along.
Concerning Angular team : do they take us for sheeps ? thinking that every time they change their minds, we will follow stupidly without thinking, they would like to give themselves the right to think for us! We can and know how to think by ourselves, let's prove it to them. I reject these suggestions, no interest. Then tomorrow what will be next, "oh finally using signals effects is not a good thing", what else? They showed us that they can be wrong, which is normal, so following them is not the systematic way to go, and i hope people will prove them that we are the final judge. Do these guys think they can rule the world ?
Thank you for the kind words about my videos. 😊
Please consider commenting also on the RFC. (But know that they are developers like us, so please be kind but clear on your concerns. Also, many developers frequently *ask* the team for guidance on best practices, so this isn't meant to be autocratic.)
❌Component should remove since angular 2 😂
Angular should just fork itself and create a new framework name for itself. It's unrecognizable and certainly not in the direction majority of the users want.
What do you see as the main changes that are making it unrecognizable? Primarily these conventions? Or other changes?
disagree, i still think having those suffix is better, how on earth would you know its a component straight away without opening that file and check whats in there? The angular team definitely have too much time on these useless stuff.
Be sure to share your thoughts on the RFC.
@@deborah_kurata checking the way the RFC is commented and voted on (by emojis) it seems to go the way elections tend to go these days, picking the bigger evil. :(
Who will follow this recommandation ? Not me for sure.
Be sure to share your thoughts on the RFC.
This is such a terrible idea. Getting rid of suffix conventions in order to have everyone make their own suffix conventions. Way to kill off any chance of newbies to understand the code base.
I like the idea of class name selectors, but a few more characters will not destroy this. And if you absolutely need it, by convention the tag parser could just omit a Component suffix automatically, without forcing you to ruin class and file names.
Agreed. Please post your comment also to the github issue so that the Angular team sees it. Thanks!
I don't know why they want to make it like React.
spec files ? you don't use Cypress ?