Two comments:

• suffixes: suffixes are often important when tweaking the lint rules. There are lint rules we generally want to apply but for specific types of files they make no sense. Being able to exclude rules for certain kinds of files would be difficult to do without the suffixes.

• best practices: they may not belong in this document but it is incredibly helpful as someone trying to steer people in the right direction if I can appeal to the Angular authority for these things instead of trying to convince my team mates that this is just the right thing to do as established by the larger community of seasoned programmers. Even if they are just general best practices, it helps counter "At my old job we..." or even worse, "we never had to do it that way in X framework."

And I'm speaking as a programmer who has been involved in 3 different companies since Angular released. This has no reflection on my current place of employment :)

• suffixes: suffixes are often important when tweaking the lint rules. There are lint rules we generally want to apply but for specific types of files they make no sense. Being able to exclude rules for certain kinds of files would be difficult to do without the suffixes.

That is internal company policy due to bad tooling Their no issues with doing that to solve your issues. However as ClickUp uses libraries in NX can this not be resolved with tagging and dont populate the libraries

I don't see how, no.

And sorry, I didn't mean to reply on your thread :(

I don't see how, no.

And sorry, I didn't mean to reply on your thread :(

What don't you see how

am i the only one who prefers ctor injection? 🤨 especially in larger components, it just feels cleaner, because i just need to look at the ctor and immediately see all dependencies.

I really prefer ctor DI compared to service locator. Makes testing easier when you don't test the HTML

The main reason in my opinion is angular team drop decorators, and constructor based injection is that because experimental decorators just don't going to be standard, they are really deprecated in Typescript and will be removed someday. The only angular and nestjs use it right now (maybe some libs too), but in upcoming typescript 5.8 they introduce flag for simple type striping for run via nodejs without transpilation, and that feature already NOT support constructor parameters, enums, namespaces, and of course experimental decorstors. also when you don't have experimental decorators, Typescript warn you that when you pass param to constructor with type, that should be type import, but not for Angular. Angular need that valued import due to angular compiler and DI. Also not all bundlers properly can handle experimental decorators. Also class based property and constructor logic changed when code transpiled to es classes, that also introduce some problems.

Yes, I think their original architecture based on experimental decorators coming to end, that why they will add RFC in 2025 for removing latest Component decorator.

You can accept it or not, but when I dive deeper into ecosystem and details I really stop hating that decision of angular team to move out from decorators and class constructor based injection

You can accept it or not, but when I dive deeper into ecosystem and details I really stop hating that decision of angular team to move out from decorators and class constructor based injection

One possible future by-product of removing decorations is the possibility of functional components instead of class based. And higher-order components

The main reason in my opinion is angular team drop decorators, and constructor based injection is that because experimental decorators just don't going to be standard, they are really deprecated in Typescript and will be removed someday. The only angular and nestjs use it right now (maybe some libs too), but in upcoming typescript 5.8 they introduce flag for simple type striping for run via nodejs without transpilation, and that feature already NOT support constructor parameters, enums, namespaces, and of course experimental decorstors. also when you don't have experimental decorators, Typescript warn you that when you pass param to constructor with type, that should be type import, but not for Angular. Angular need that valued import due to angular compiler and DI. Also not all bundlers properly can handle experimental decorators. Also class based property and constructor logic changed when code transpiled to es classes, that also introduce some problems.

Yes, I think their original architecture based on experimental decorators coming to end, that why they will add RFC in 2025 for removing latest Component decorator.

You can accept it or not, but when I dive deeper into ecosystem and details I really stop hating that decision of angular team to move out from decorators and class constructor based injection

I am not aware that decorators are deprecated in TypeScript. Version 5 introduced changes to how decorators are implemented, to comply better with how decorators are forming within the ECMAScript TC39 proposal, but as far as I am aware, DECORATORS THEMSELVES are not going anywhere. It may be that an older approach to decorators will eventually be deprecated, but it will be a long time before they are removed...too darn much code relies on them right now. It is not just nest and angular. Other libraries use them, some codebases implement their own decorators, I use a number of libraries, say TypeORM, that also use decorators.

It would be massively breaking if TypeScript removed decorators, including experimental (how they worked pre 5.0) any time soon. Decorators have their place. They allow something called AoP, or Aspect Oriented Programming, where aspects that are cross cutting can be easily applied to other code simply by attaching an attribute, a decorator, to other code. A great example of this is attaching standardizxed forms of logging, metrics, etc. to code, without having to manually write the logging and metrics in every single peice of code. Just add a decorator. This can work with functional components just as much as with classes. Decorators are not class specific. I see no reason to claim that decorators or going away...that would be a devastating blow to typescript code.

Further, last I heard, decorators were already an ECMAScript Stage 3 proposal, which is just one step away from becoming an actual feature. I see no evidence that decorators for JS itself are not going to happen, or are going away.

"Best Practices" page would be awesome.

Maybe seperating out the current best practices and style guide should happen first then introduce the radical new changes (radical in that the are significant departure from what we are used to doing).

There's definitely room to improve guidance around which lifecycle API to use when, but I don't think the style guide is the place to do it. One of the goals of this revision is to focus (mostly) on style concerns rather than best practices. That is, concerns that don't have any technical bearing on the way your application runs, and instead relate to some style or taste preference.

Hi @jelbourn style guide is recommending [class.x] instead of ngClass , so is it not same as best practice ?
like prefer computed or linked signal / afterNextRender over ngOnInit, similarly prefer input signal & output fn over @Input & @Output decorators.

On a side note, outside of this specific discussion, I think ngOnInit should have an alternative method name, in line with the others, for use within the injection context.

Now that we're at it, afterNextRender and afterRender are the most confusingly named functions ever. Nobody, and I mean nobody, know the difference (and that's a potentially very grave mistake to make).

Absolutely not relevant in this RFC but I'll continue to beat this horse: rename them afterNextRender => afterFirstRender, and afterRender => afterEachRender

I'll see myself out now.

I completely agree. The terminology is hard to distinguish. I can never remember which is which. Your ideas are good. Adding "first" and "each" is clear and simple.

Yeah, known issue #54825 (comment)

In particular, it specifically recommends avoiding directives like components, services, etc.

But, without folder structure it will be a mess. Especially if the app is more than 5 pages big.

Sometimes it even feels that those folders might need some extra nesting to organize all those components/services.

Having all of them in one folder would be an endless flat list that's hard to navigate through. 🤔

With features/pages it's a bit simpler. But shared components/directives/services feel like a separate world that needs this division.

At one point there was guidance in the style guide about creating a new subfolder if there were more than 7 files there (or something to that extent). But I have a project that, even with feature folders, still contains folders with way more than 7 files, and I'm hesitant to go down the path of something like having folders for parent components, child components, etc.. I've seen the way that deep nesting can go crazy.

It's always good to have that "official" guidance, if it exists. :)

I think the folder "per feature" guide line helps here more than generic folders called components ...

The question you should ask yourself if you tend to get to many feature folders is, if you can group features in an "aggregation" folder.

Already running through it in my head. Anything more than 2 or 3 folders deep turns into a mess. Saw a codebase once where there were components nested 7 folders in, and if you didn't know where they were or what you were looking for, it could be a problem.

I am not a fan of "type-based" folder structures. It lacks cohesion which is a very critical aspect of good software design.

I have followed a folder structure where closely related or closely coupled facilities...module, components, services, effects, states, selectors, etc. are grouped together. Sometimes there is a bit of light weight nested structure, but as a personal preference I like to avoid deeply nested folder structures (its a complexity thing, much like deeply nested code! :P) I don't go fully flat, but, not deeply nested either.

I think there is good discussion to be had around what the most cohesive organization might be for angular apps. I also use NX, so my organization extends to having apps (which are usually very light weight) and libs (which is where the real meat is). Libs, being a top level sort of thing, are often organized by type initially, but then again...cohesion and relatedness takes over deeper into the tree.

I am not sure that organizing things by the "type of code" is really a BEST practice. When you take a step back, organization by type leads to related things becoming thoroughly DISPERSED through a codebase. IMHHO, that would actually be an anti-pattern, and not a best practice. It increases the effort of finding related code, coupled code, and cohesion just goes out the window.

Type is not a hard thing to deal with. You could have 5-10 different types of code files in a single directory...ides these days can either add different icons for each type, or color code each type differently, etc. Organizing by type through explicit file system structure is unnecessary.

Further discussion?

Im affraid off loosing the hints (icons) of my ide that tell me what kind of file it is.
Now i see diffrent icons on diffent types (componnet, service,...) is there a change to keep this hints?

@web-dave a guide is just a guide, you can safely ignore recommendations you don't like.

I'm a trainer and mentor, so in my role as such, I would love to stick to the style guide. but also would love to have good DX.

I'm very curious to know how you devs are opening a new file in vscode when there are no suffixes, it seems to me much more challenging from a cognitive point of view.
For example, if I'm looking for a file implying a user:

In a dialog:

Some letters for the general concept ("user") + the type ("dialog") are sufficent.
I'm genuinely interested in your process if you have a better way to go!

@Frankitch I think this can be tackled by directory structure, with a types dir, a component dir etc. in your various domain-directories. This means you can search with a component<componentname> query in vscode.

I believe based on your screenshot your already do some of that , as you can search for your interfaces via modeluser to find a smaller selection of user-files that includes libs/shared/user/models/src/lib/user-filter.interface.ts

That is not to say I prefer losing the suffix, but that this is the solution I've found for myself having faced this kind of problem in react codebases.

@zygarios the bigger picture for a upcoming RFC make perfect sense to remove it (even though RFC not out) based on what angular team said publiclly it be something like

#58412 (reply in thread)

if you look prefex makes no sense on things now when its only in the template

This guidance isn't actually new— even the current style guide recommends this.

Our experience is that this approach of directories based on the type of thing is not the most scalable approach. As an application grows, this kind of directory gets bigger and harder to reason about, full of code that doesn't relate to each other. The recommendation prioritizes proximity of related code.

@zygarios the bigger picture for a upcoming RFC make perfect sense to remove it (even though RFC not out) based on what angular team said publiclly it be something like

#58412 (reply in thread)

if you look prefex makes no sense on things now when its only in the template

This is the second time I've see this comment and I am questioning if this (upcoming) RFC and the current one, should be discussed at the same time. While I partially agree with the "noisiness" of the suffixes I see a value in them for auto-completion in IDEs (here). But due to the repeated mentioning of a much hotter topic (Authoring Format) I get a "bad" feeling

That's true, it's hard to comment on the RFC when we're still waiting for another related RFC.

I understand and acknowledge that these are reasonable arguments. Adding some kind of auxiliary option like ng add lint/prettier would be valuable and quite a good compromise. I leave this for further consideration, and thanks for the response.

Adding Prettier and ESLint is something that has come up a few times in the past. My general thought is that I'd rather avoid introducing that complexity into a new project. Even a prompt can be a significant barrier to someone who doesn't understand what formatting means and how to answer such a question. We are also often hesitant to include additional dependencies which could at any time stop being maintained and have been burned by this in the past (TSLint in particular). I think we're also relatively unopinionated on how to format your TypeScript code (see the change removing general guidance) and don't really want to be the arbiters of best practices in that area.

I think a more stable integration would be something like ng add prettier / ng add eslint which installs the Prettier/ESLint package and integrates it with Angular (for some definition of "integrates"). I'm not super clear what that would actually do from an Angular perspective, given that linting integration is more of an IDE / CI problem, but there's potential opportunities there which would make these tools easy to adopt without necessarily putting that baggage on developers who might not want them.

This is a very valid concern, so much so that we still use tslint.

I don't think eslint should be standard when you have OXC and is it biome which is what I used on other frameworks

@Jordan-Hall I think when Oxlint will be completed by feature parity, that will be new default.

OXC is an amazing project, but @Jordan-Hall @pumano I think you are forgetting that angular-eslint works by wrapping @angular/compiler to parse Angular flavoured HTML into an AST.

I am highly doubtful that the OXC folks have the time (or inclination) to write an equivalent rust based parser for Angular flavoured HTML which will need to keep parity with Angular's framework changes over time.

They also currently do not allow the parser to be pluggable, so there is no chance of providing one from the community

Yeah, we're very much at the start of trying to do this more. A few cherrypicked examples from recent work:

• Advice on choosing component selectors
• Advice on when it's okay to use DOM APIs
• Avoid trackBy identity

We're slowly working out way through the documentation to make big improvements (router guide is in progress!), but the goal is to continue baking in these best practices as we go.

+10,000 to OP's post here. Having a strong opinion is indeed a good thing and should be encouraged more. The benefits of OnPush are clear and obvious once folks implement them across their components. There are numerous other best practices that fall into this camp.

Just a heads-up on this matter. Since Angular templates are no longer "pure HTML" due to the new control-flow syntax, Prettier relies on the .component.html suffix to identify Angular templates. The filename is the way Prettier distinguishes between

I could swear Prettier works well for us and we NEVER EVER name our template files *.component.html

Is this still true with the new control flow syntax?

Yep, I can swear it too!

Is this still true with the new control flow syntax?

Yep. Works beautifully.

Thanks for pointing this out- we'll make sure to coordinate with the prettier maintainers.

@jelbourn can you please update the FAQ with the answer to this question
I have also made some internal eslint rules that only applies for component files (but the ts ones) and I'd like to know what should be the alternative going forward, how can eslint/prettier/... identify which file is a component or not

Well, it depends on the rules... but maybe decorators can be useful (I guess angular-eslint is using decorators for some rules).

• https://github.com/angular-eslint/angular-eslint/blob/main/packages/eslint-plugin/src/rules/component-class-suffix.ts#L51
• https://github.com/angular-eslint/angular-eslint/blob/main/packages/utils/src/eslint-plugin/selectors.ts

@mauriziocescon but this means the rule will increase in its complexity by too much
so instead of being applied only to *.component.ts files, it will apply to all *.ts then inside each I need to check if it has @Component if not then ignore, if it has then start the current check
which means the time it needs will be x10 times of the time it needs now

Any new APIs around declaring host bindings would be out of scope for now (though we are in fact thinking about this for the longer term).

So, given the two APIs we have today, the recommendation is still for host for all of the reasons mentioned in the RFC. For more complicated scenarios, the recommendation would definitely be to use a computed or a class method.

What stops you from doing

@Component({
    host: {
        '[attr.whatever]': '/* complex logic here */',
        '(keydown)': '/* complex logic here */'
    }
})

?

Better even: use a computed(() => /*complex logic here*/) for your attribute binding. The function will be called a lot. You don't want it to hog your ui thread when the result doesn't change.

As far as I understand the documentation, complex logic is not an option. The docs say the value is a "statement", which would preclude things like control flow logic and the like.

FWIW I've done this and it works:

@Component({
  host: {
   '(keydown)': 'doSomething()',
  }
})
class DoesSomething {
  doSomething(): void {
    // something
  }
}

FWIW I've done this and it works:

@Component({
  host: {
   '(keydown)': 'doSomething()',
  }
})
class DoesSomething {
  doSomething(): void {
    // something
  }
}

Hmm..... First thing that comes to my mind here, is, the definition in the host property, is disjoint from the implementation. Yes, you can hop to the implementation...assuming your IDE actually recognizes the string expression bound to the (keydown) binding as actual code. If not, you gotta find the implementation (which could be some distance away, especially if your preference is SFC)..

In that case, I think I'd probably prefer the @HostBinding/@HostListener approach as then the two parts are not disjoint from each other. Or, if the Angular team gives the option to us, I'd prefer the kind of functional approach I played with above first and foremost. ;) But, I think that disjoint things are more of an anti-pattern. Even if they "work", one of the benefits of a decorator approach is the binding and the handler are right there together (i.e. cohesive).

As far as I understand the documentation, complex logic is not an option.

Can you link to the relevant documentation that states this? Because it is incorrect in the sense that: it is an expression and can be as complex as any expression in a template. It all works: '[attr.whatever]': 'expressionAsComplexAsYouWant',

First thing that comes to my mind here, is, the definition in the host property, is disjoint from the implementation

As it should be! What @HostBinding does is saying: use the result of the declared member read as a host binding expression. In this sense it is more limiting as compared to what you can express in host.

Also, the narrative around "disjoint" makes me thing that you might be assuming a mental model which is different from out intention. We think about host bindings as template fragments. In this sense every expression in a template is "disjoint".

Long story short: it is clear to me from this conversation that having 2 way of doing the same thing is a real problem and we should navigate towards one solution.

I made everyone in my team watch this talk: https://www.youtube.com/watch?v=OvGOO7Ha1oA
Maybe you can incorporate some of his advice into the style guide.

Ah, my intent was the existing components guide captured this (as more of a best practice than a style choice):
https://angular.dev/guide/components/host-elements#the-hostbinding-and-hostlistener-decorators

That said, it's fair that we should consider including this in the actual style guide. The point about highlighting that you can/should use the host element is also worth considering.

I have to strongly disagree on this.

While it might add an extra div layer in the DOM, it is also much more readable.
I really don't want styling in BOTH the component and in my template.
Having an extra div doesn't hurt as much as having styles separate places for the same component.

Just my opinion.

Looking at the VS Code docs, it seems you wouldn't be able to customize icons without something in the file name

Icons can be associated to folders, folder names, files, file extensions, file names and language IDs.

So that would be lost unless there's perhaps some other mechanism

Maybe a new authoring format will help keep those icons with a .ng file extension for example... 😎 But that's out of the scope for now hehe

Looking at the VS Code docs, it seems you wouldn't be able to customize icons without something in the file name

Icons can be associated to folders, folder names, files, file extensions, file names and language IDs.

So that would be lost unless there's perhaps some other mechanism

I myself prefer to have tool facilities than removing suffixes for a "stylistic" reasons which will reduce DX (vscode icons, probably vscode plugins, eslint with special rules, ...).

Will it be configurable with a flag ? (This will help those who prefer the suffixes to not waste time renaming the newly created files with the CLI if the recommandation is integrated in the CLI)

I think the file extensions, like .component.ts, .module.ts, etc. should remain. Not everyone uses VSCode (I use WebStorm myself, I know many people who use other IDEs), and losing the extensions would mean losing custom icons for every angular file type. A global .ng extension wouldn't be nearly as useful as having readily identifiable and recognizable custom icons for every different kind of angular file type. Just as with syntax highlighting, the different icons greatly assist in finding the right files when browsing through a file tree.

I want to double down on the "not everyone uses VSCode" statement found in several comments. I use Neovim and it too will have these same file extension concerns.

One thing I want to point out as well is that a user.html file could be Angular agnostic. You have to analyze the file contents to know if it's an Angular template, and even then if you don't use any Angular-specific syntax in that file then the contents won't be helpful either. user.component.html however solves that problem, and gives editors and plugins of all kinds a hint.

I guess this is basically outlined in this comment too.

A thought on this just popped into my head.... I wonder if an option could be added to providedIn called nearest? I don't know if or how that might work, would probably require a bit of build magic to make it happen. The idea would be that instead of providing in root, it would be provided in the nearest module...within the file tree. Either same directory (and I guess, if there is more than one, provide it in all of them!), or nearest up the directory tree. That might support a simpler approach to standalones that still use modules to a degree (I like using modules to organize and encapsulate myself.)

Anyway...just a thought...

Isn't route providers recommended? It will scope the service to that route and can't be injected from outside (still a singleton) and can enforce accidentally referencing out of scope.
The only caveat is losing the lazy initialization.

@Harpush - I'm not sure providing at the route level is recommended (at least I've never heard that), although that is a step closer to being "intentional," which I side with. And good point about the lazy instantiation. I recently was providing some services at the route level, assuming they'd be destroyed and recreated (so their state would reset) when leaving that route and coming back, but I was wrong -- it stays alive (just like if it were provided at the root).

@Zooce That is true. I also once encountered this behavior, and since I understood that it doesn’t get destroyed when leaving the route, I stopped seeing the point of using providers in routing.

@Harpush I wasn't aware route providers were recommended... I'd have to think on that one more. It disjoints dependencies from the components as well. We had that, with modules, but at least with modules, you know all the configuration for everything in the module was wired through the module. With SAC, I wonder what disjointing the dependencies from the component would do to understandability and maintainability...