RFC: An updated style guide for the year 2024

[jelbourn]

Introduction

Angular's current style guide was originally written in 2016, just as v2.0.0 released. A lot has
changed in the intervening eight years.

This RFC proposes a significant overhaul of Angular's style guide
with a handful of primary goals:

• Make the style guide shorter. The current style guide is 52 (!) pages when printed.
• Simplify guidance that was overly cumbersome or boilerplate-y
• Remove most guidance that doesn't meaningfully relate to Angular (but sometimes we just can't
  help ourselves)
• Focus the style guide more on style choices rather than general Angular best practices
• Modernize guidance to reflect new features and APIs in the framework
• Update prior recommendations based on our observations of Angular development in the real world

As always, keep our code of conduct in mind. We know that a proposal of this scope affects the way the community writes Angular code, and that people have invested their time and energy learning these practices in the past. We appreciate your commitment and investment in this project and ask to keep comments respectful. Remember, we are all just folks doing our best with limited resources.

📜 Full draft of the revised style guide

What kind of feedback are we looking for?

We're happy to take any and all feedback on this update. However, we're primarily interested in
the following:

• Are there any major omissions from this guide that it should cover?
• Are there any community-owned tools (similar to angular-eslint) with whom we should coordinate
  these changes?
• Are there any mistakes or inconsistencies with this updated guide?

Notable changes

Remove general code health guidance that's not meaningfully related to Angular

The current style guide includes a significant amount of advice relating to general coding best
practices. Examples include:

• "Consider limiting files to 400 lines of code."
• "Do define small functions. Consider limiting to no more than 75 lines."
• "Do be DRY (Don't Repeat Yourself). Avoid being so DRY that you sacrifice readability."
• ...and many more.

While these are reasonable best practices, they're not really specific to Angular. There's a massive
corpus of books, articles, and videos dedicated to general coding best practices; we believe that
the Angular style guide will be more useful focused on framework-specific practices without trying
to curate a subset of these more general practices.

The revised guide still includes some general advice, mostly where such advice brushes close to a
particular aspect of writing Angular code.

Move Angular best practices to appropriate documentation instead of the style guide

We want the style guide to focus on coding style. Much of the content in the existing style
guide instead relates to Angular best practices. For the most part, this best practice advice has
moved (or will move) to the appropriate documentation page.

For example, guidance on choosing component selectors has moved to
the documentation page for component selector.

Stop recommending suffixing most file names and class names with the type of construct

The current style guide recommends suffixing file names and class names with the type of Angular
construct. For example:

• user-profile.component.ts and UserProfileComponent
• campaign-data.service.ts and CampaignDataService

Over time, we've observed that this naming convention can make the framework feel cumbersome and
boilerplate-y, especially for new developers unaccustomed to this practice.

For class naming, we believe it's better for a class name to reflect the class's behavior and
responsibilities, not how it's used. The term "service", in particular, does not add any
meaningful information to explain what a class does. Thus, this naming convention can sometimes lead
to less helpful names for classes. For example, a name like UserDataClient tells you much more
about what a class does than UserService. As a result of our observations, we're reversing
this guidance.

There are two exceptions to this change: Pipes and NgModules.

• NgModules are almost entirely a configuration construct. As such, they generally do not have any real behaviors or responsibilities. Given this, it makes sense to keep class names like " ProfileModule". However, rather than using a dot in the file name, "module" would be treated as part of the identifier name, e.g. "profile-module.ts".
• A pipe's behavior is intrinsic to it being a pipe (transforming a value). Given this, it makes
  sense to keep class names like "DatePipe". As with NgModule, the file name would
  become date-pipe.ts.

Remove (almost) all guidance related to NgModule

A large portion of the current style guide pertains to NgModule— when to use them, how to organize
them, etc. The Angular team now recommends using standalone components and providedIn: 'root'
over NgModule, so this guidance can be removed from future versions of the style guide. All of the
historic NgModule guidance will remain accessible on the archived versions
of angular.dev.

Remove suggestion to put templates in a separate file

The current style guide recommends extracting component templates to a template file if they exceed
three lines. Since this was written, the popularity of both JSX-based template styles and
single-file component formats has exploded. Because of this change in the broader ecosystem, we no
longer see it as necessary to strictly recommend moving templates to a separate file.

This change does not mean that inline templates will be recommended- the change is that separate
files and inline templates are both acceptable. You can still have an opinion for your projects, but
the Angular team no longer takes a stance here.

Stop recommending @HostBinding and @HostListener

The current style guide recommends @HostBinding and @HostListener over the host property in
the @Component and @Directive decorator. The updated style guide reverses this advice.

Astute readers may have already noticed this updated guidance in the rewritten Components guide
on angular.dev and discussion on this topic in the signal-based components RFC.

There are a number of reasons for this change:

• The new signal-based APIs for authoring components and directives all use functions rather than
  decorators, making @HostBinding and @HostListener somewhat misaligned with this more modern
  API style.
• The host object matches the syntax used in the template, leading to a more consistent
  experience.
• For complex components, the host property is easier to quickly scan. CSS classes alone are
  much easier to reason about when they're all defined in one place, and seeing ARIA attributes
  all together helps sanity check that the right attributes are applied.
• HostListener doesn't support expressions, which encourages developers to create unnecessary
  one-line methods.
• HostBinding doesn't allow for static values (e.g. role and tabindex), leading to unnecessary
  dynamic bindings.

One downside to the host object is that Angular does not yet do any type-checking on expressions
in host bindings. The team is acutely aware of this gap and plans to add type checking for host
in the not-too-distant future.

Stop recommending the "on" prefix for event handlers

The current style guide recommends prefixing event handler names with "on", such as onClick
or onKeydown. The updated advice is to name methods for what they do rather than when they're
called.

Frequently asked questions

Why change the style guide at all?

**Angular has evolved a lot! ** Since the style guide was written, we've moved from NgModule to
standalone components, introduced signals, new control flow syntax, and so much more.

**We've seen eight years worth of Angular codebases! ** The current style guide was written when
Angular was still quite new. As we've seen so much Angular code written over the years, we've had
time to rethink some of the practices recommended in the guide.

The web ecosystem has changed a lot! Developers had certain notions and preferences around web
development in 2016 that have shifted over time. For example, the popularity of the single file
component authoring style in frameworks like Vue and Svelte have demonstrated that opinions have
shifted about separating code and templates into separate files.

But I like the old way!

That's okay! Ultimately the style guide is just a set of recommendations- the framework will still
work fine if you decide to stick with the original conventions. Historic versions of the style guide
will remain available in the archived versions of angular.dev. But we think
the updates proposed here constitute a better set of recommendations for new code going forward.

Will community tools (like angular-eslint) support the new recommendations?

We plan to coordinate with community supported tool owners so that they can be updated alongside
the revised style guide becoming official.

Will this new style guide land in version 19?

No— these changes aren't ready for v19, so they'll land in a later version.

Why doesn't the guide recommend signals?

While signals are maturing rapidly, some APIs remain in developer preview and some parts of the
ecosystem (forms, router) have yet to receive a signals makeover. We'll do continue to update the
guide as signals continue to mature.

Will you update the code generated by ng new?

Yes- we consider updating the code generated by ng new to be a requirement for publishing updates
to the style guide.

Will you provide schematics to refactor code to follow the new guidance?

We plan to offer optional refactoring schematics to update code to the new guidelines where it's
feasible. These schematics would be opt-in and not automatically run as part of ng update.

[Foxandxss]

Thank you. That is long due. When we created the style guide in 2016, we only had angular.js ideas in mind and an idea of what Angular would be. We were right in certain things, we were wrong in other things. In any case, that was 8 years ago and I think everything changed (for the better)

[dbush-clickup]

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 :)

[Jordan-Hall]

• 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

[dbush-clickup]

I don't see how, no.

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

[Jordan-Hall]

I don't see how, no.

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

What don't you see how

[Jordan-Hall]

Thank you; this is long overdue. The suffix is pointless and actually means that if you want to import it only once and append the component to the class name, the compiler will have to remove the suffix, which isn't ideal.

@jelbourn any thoughts on DI, i think with update to guild Angular needs to take a position on using DI or the new inject service locator

[patricsteiner]

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.

[Jordan-Hall]

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

[pumano]

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

[spock123]

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

[jrista]

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.

[Yberion]

Move Angular best practices to appropriate documentation instead of the style guide

It would be nice to have a place that group all Angular best practices, with anchor, same as the current guide.

[tayambamwanza]

"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).

[LcsGa]

It might be cool to explain what hook you will need depending on what you are trying to do.

The thing I see the most are people using ngOnInit when they could do the exact same thing in a constructor or simply on a class field.

The same goes for afterNextRender / afterRender over ngAftreViewInit and more specifically: what hooks people should avoid until most of them gets deprecated once signals are stable (ngOnChanges, etc.)

[jelbourn]

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.

[imaksp]

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.

[spock123]

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.

[zygarios]

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.

[mauriziocescon]

Yeah, known issue #54825 (comment)

[gultyayev]

I think it would be helpful to cover following topics:

1. Structuring the application. How to better structure the application, how many folders and where should be created. E.g. folders like components, models, services, pages etc. To create some guidance for the overall structure that is helpful for any SPA.
2. Structuring services and API calls. E.g., how to better organize things. Whether, we should create "Api" services and other "business" service would use those. Or, each service could "copy-paste" request paths. How to better organize DTO models in the repository.

Not sure it's 100% Angular-related, but I think it would be valuable to have such guidance.

[gultyayev]

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.

[mylifeandcode]

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. :)

[chaosmonster]

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.

[mylifeandcode]

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.

[jrista]

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?

[jnizet]

Regarding suffixes in class names, I understand the rationale for reusable components that are part of a component library such as Angular Material for example: Card, Datepicker, Menu etc. are sufficient and unambiguous.

On the other hand, for application components whose main role is to display data, if we follow the advice in the new style guide, we'll end up with components such as User, Profile or Product. And I find those problematic, because it's hard to tell if it's a component used to display a user, a profile or a product, or if it's the TypeScript interface defining the user, profile or product to display.

I'm afraid that to comply to the style guide, we end up with TypeScript interfaces named as UserData or UserModel, ProfileData or ProductData. Which is worse, because the application code uses these interfaces all over the place, whereas the component class is almost never used (except in imports, unit tests and view queries).

So I'd find it helpful to keep the Component suffix, at least for these kinds of components. But then the questions would be: should we favor consistency and use the Component suffix everywhere, or should we only keep it when disambiguation is necessary? And what will the CLI generate by default, since at the moment it automatically adds the Component suffix?

[Zooce]

I know this isn't an established pattern in Angular, but in our very large application, we use a concept I amateurishly named a "Companion Service" where we split the non-UI data processing out of components and into a service with the same name as the component, and provide it from the component. For example, you could have HeaderComponent and HeaderService. The service doesn't necessarily have to fetch data from APIs, but perhaps it aggregates data from other services so the component can focus on presenting that data and dealing with user interactions on it.

Removing the suffix in the class names would throw an unnecessary wrench into the mix. I suppose this very specific, uncommon pattern could still be done with something like Header and HeaderCompanion, but then again, you can't really tell by the name which one is the component and which one is the service unless you fully understood the pattern.

In general (and I've seen this mentioned already) the suffix, especially on services, is quite a nice indicator in the code that you're dealing with an Angular service versus something else.

[web-dave]

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?

[e-oz]

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

[web-dave]

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.

[Frankitch]

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!

[zygarios]

I don't fully understand the recommendation to avoid services, components, directives, etc., folders. In my opinion, these are often quite useful. I feel the guide lacks a more extensive example that demonstrates a complete application structure. One that includes multiple directives, pipes, services, components, etc., because right now, I better understand what to avoid rather than what is recommended when it comes to organizing folders within src.

[Jordan-Hall]

@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

[jelbourn]

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.

[chaosmonster]

@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

[zygarios]

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

[Martinspire]

I feel that this style guide is now less of a guide and more of a standards. And I could even see a guide that goes on top of this for more recommendations. But if the goal is to match all projects, I think it would be helpful for any style guides for specifics. A style guide for a CRUD application, or one for public websites, one that is an SPA or one that is a major application with many modules and many teams. Because these are different use cases that would seek guidance on how the Angular team recommends they work at. Modules are mostly removed but their separation is still valid.

Also, I wouldn't mind a more strict recommended project setup where you go into detail what would be recommended for spacing, what goes on a new line and what doesn't, where you place comma's and stuff like that. We already have various ESLint plugins and even Angular ones that I think are good for people to use, but what would be the recommendation for making code look the same. Because ultimately I think the goal of these style guides is to get code in a similar style so that anybody can work on an Angular project. Which to me is the main reason to use Angular: because its applications all look similar enough. Right now I have a lot of rules and settings to make sure linters automatically format most of the code and recommend certain changes to make code seem similar. Having a style guide from Angular that brings code to a higher level, would seem like a good idea to me. Even though some folks will be annoyed by a few of the recommendations, the thought of a code standard that is preferred by the team, would greatly benefit the ecosystem.

Similarly it doesn't say anything about TSConfig (or its setup) or what you should do with the angular.json configuration. And I feel it should also go into more detail on the testing part. Both unit testing and E2E/integration testing.

[zygarios]

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.

[wartab]

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.

[Jordan-Hall]

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

[pumano]

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

[JamesHenry]

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

[tomer953]

Move Angular best practices to appropriate documentation instead of the style guide

While Angular is well-known for being an opinionated framework, I observe a significant lack of documentation regarding best practices. Personally, I follow the Angular team on social media, and while it's clear to some developers that certain practices are preferred, these are not officially documented.

For example, in a discussion at work, I had to convince my colleagues that OnPush is always preferable in modern Angular. Some argued that this preference isn't stated anywhere in official documentation and Angular itself does not come with OnPush as the default strategy.
it would be much easier if there were official recommendations on such topics.

Additional examples of areas where official recommendations would be beneficial include:

• Using signals and avoiding manual change detection.
• Avoiding function calls in templates.
• The "you might don't need an effect" recommendation and its rationale.

Providing clear, official guidance on these and similar topics would greatly benefit the community by reducing ambiguity and helping teams adopt best practices more consistently.

[jelbourn]

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.

[richieforeman]

+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.

[tomer953]

Stop recommending suffixing most file names and class names with the type of construct

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

parser: "angular"
and.
parser: "html"

[LcsGa]

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!

[spock123]

Is this still true with the new control flow syntax?

Yep. Works beautifully.

[robertIsaac]

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

[mauriziocescon]

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

[robertIsaac]

@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

[jrista]

Stop recommending @HostBinding and @HostListener

Sometimes, a simple expression is not enough. Will there be a recommendation when the logic required is more complex than teh basic expression parser for the @Component directive's host property is insufficient?

Extending from that...any chance we might get a function to create host bindings when they need to be more complex? Just, really really rough, off the top of my head, maybe:

@Component({ ... })
export class AdvancedWidget {
   #complexBinding1 = hostBinding(value => /* complex logic here? */, 'atter.whatever');
   #keydownHandler = hostListener(($event: Event) => /* complex logic here? */, 'keydown');
}

This would be in-line with the new functional input/output/signals stuff, and support whatever level of complexity is necessary with full support for TypeScript's featureset? I feel this would be a better approach, than say...expanding the angular parser for the host property to support more of typescript. If I need to do something complex, I'd rather have it be real code, functional in nature, and fully vetted by the typescript compiler...and not "strings" if I could avoid it. ;)

[jelbourn]

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.

[jrista]

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 th