docs: replace style guide with 2025 revision #60809
Conversation
jelbourn
added
target: major
|
Deployed adev-preview for 8fa50de to: https://ng-dev-previews-fw--pr-angular-angular-60809-adev-prev-uvdhn94r.web.app Note: As new commits are pushed to this pull request, this link is updated after the preview is rebuilt. |
| Logic in a service can more easily be isolated in a unit test, while the calling logic in the component can be easily mocked. | ||
| See the Components guide for details | ||
| on [naming input properties](https://angular.dev/guide/components/inputs#choosing-input-names) | ||
| and [naming output properties](https://angular.dev/guide/components/outputs#choosing-event-names). |
There was a problem hiding this comment.
| and [naming output properties](https://angular.dev/guide/components/outputs#choosing-event-names). | |
| and [naming output properties](/guide/components/outputs#choosing-event-names). |
Can we make all the adev links relative, this way they'll look as inner-links + they will keep you on the right subdomain (next or any future version the reader is on)
There was a problem hiding this comment.
Good catch, I forget to change the URLs after exporting from Google Docs (fixed)
|
Suggestion: mention the |
See RFC angular#58412 for background.
jelbourn
force-pushed
the
revised-style-guide
branch
from
f93a57f to
8fa50de
Compare
| * `inject` is generally more readable, especially when a class injects many dependencies. | ||
| * It's more syntactically straightforward to add comments to injected dependencies | ||
| * `inject` offers better type inference. | ||
| * When targeting ES2022+ with `[useDefineForClassFields](https://www.typescriptlang.org/tsconfig/#useDefineForClassFields)`, you can avoid separating field declaration and initialization when fields read on injected dependencies. |
There was a problem hiding this comment.
| * When targeting ES2022+ with `[useDefineForClassFields](https://www.typescriptlang.org/tsconfig/#useDefineForClassFields)`, you can avoid separating field declaration and initialization when fields read on injected dependencies. | |
| * When targeting ES2022+ with [`useDefineForClassFields`](https://www.typescriptlang.org/tsconfig/#useDefineForClassFields), you can avoid separating field declaration and initialization when fields read on injected dependencies. |
Fixes the output formatting
|
|
||
| #### Style 05-16 | ||
| Components and directives should group Angular-specific properties together, typically near the top | ||
| of the class declaration. This includes inputs, outputs, queries, and injected dependencies. Define |
There was a problem hiding this comment.
Since this isn't in alphabetical order, is the preferred order inputs, outputs, queries, injected dependencies, or is it unimportant? Perhaps we should state it either way?
| <docs-code header="app/heroes/shared/hero-button/hero-highlight.directive.ts" path="adev/src/content/examples/styleguide/src/05-13/app/heroes/shared/hero-highlight.directive.ts"/> | ||
| <docs-code header="app/app.component.html" path="adev/src/content/examples/styleguide/src/05-13/app/app.component.html"/> | ||
| </docs-code-multifile> | ||
| Prefer using the `inject` function over injecting constructor parameters. The `inject` function works the same was as constructor parameter injection, but offers several style advantages: |
There was a problem hiding this comment.
| Prefer using the `inject` function over injecting constructor parameters. The `inject` function works the same was as constructor parameter injection, but offers several style advantages: | |
| Prefer using the `inject` function over injecting constructor parameters. The `inject` function works the same way as constructor parameter injection, but offers several style advantages: |
|
|
||
| **Avoid** putting application logic in `main.ts`. | ||
| Instead, consider placing it in a component or service. | ||
| Separate words within a file name with hyphens (`-`). For example, a component named `UserProfile` |
There was a problem hiding this comment.
As one of the motivations is to use more meaningful naming, I'd recommend promoting it by suffixing a component by the UI part it's related to, such as UserProfileHeader, UserProfilePage, UserProfileForm and so on.
UserProfile will more likely be used in this component as the main data type and would lead to conflicts.
See RFC #58412 for background.