Hey everyone, we're back foranother update on this style guide.

From vote responses on the RFC response, social media, and people just telling us (outside of this RFC), we've received feedback that people strongly prefernot introducing the.ng to files that import from@angular/core. Based on this, we're scrapping any plans to recommend the.ng suffix for TypeScript or HTML files in the style guide. This means that the style guide will express no opinion on identifier or file name suffixes. By default, the Angular CLI won't generate suffixes, but theng generate schematics retain configuration options to specify them.

Additionally, we'readding one new recommendation:Prefer theinject functionover constructor parameter injection

We're adding this new recommendation in light of the introduction ofclass fields in ECMAScript 2022. Previously, class fields were purely a TypeScript feature that were compiled into property assignments in the class's constructor. Native class fields, however, have different semantics than this earlier behavior— class field initializers runbefore the class's constructor. This particularly impacts how you can use class fields with injected dependencies. To demonstrate, here's an example using constructor parameter injection:

@Component({/* ... */})exportclassUserProfile{privateuser=this.userData.getCurrent();constructor(privateuserData:UserData){}}

This example works just fine when TypeScript emits ECMAScript versions less than ES2022. In these versions, the compiled JavaScript looks like this:

// Emitting ES2017exportclassUserProfile{constructor(userData){// The field initializer is inlined into the constructorthis.userData=userData;this.user=this.userData.getCurrent();}}

However, in ES2022 with theuseDefineForClassFields option, the output looks like this:

// Emitting ES2022exportclassUserProfile{userData;user=this.userData.getCurrent();// Error! userData is not yet initialized!constructor(userData){this.userData=userData;}}

This output throws an error because the field initializer runsbefore the constructor and tries to use the injected dependency before it's available. To work around this with constructor injection, you would write your code like this:

@Component({/* ... */})exportclassUserProfile{// Field declaration is separated from initialization.privateuser:User;constructor(privateuserData:UserData){this.user=userData.getCurrent();}}

Many developers find the separation of field declaration and initialization to be undesirable. Fortunately, theinject function neatly sidesteps this problem:

@Component({/* ... */})exportclassUserProfile{privateuserData=inject(UserData);privateuser=userData.getCurrent();}

Theinject function works the same way as constructor parameter injection (in fact, constructor injection callsinject under the hood). This is purely a style recommendation— constructor parameter injection remains fully supported.

All the other proposed changes in the original RFC will proceed as planned.

Thanks for being invested in code style!