Angular versions
-
@for (version of versions; track $index) {
- - @@ -70,7 +70,7 @@
- - @@ -40,7 +40,7 @@
- - @@ -70,7 +70,7 @@
Angular versions
} - @if ((to.number - from.number > 150) && from.number > 240) { + @if (to.number - from.number > 150 && from.number > 240) {Warning: @@ -86,7 +86,7 @@
Application complexity
Other dependencies
Package Manager
@if ( - beforeRecommendations.length > 0 || duringRecommendations.length > 0 || afterRecommendations.length > 0 + beforeRecommendations.length > 0 || + duringRecommendations.length > 0 || + afterRecommendations.length > 0 ) {
-
@@ -191,7 +193,7 @@ {{title()}}
+{{ title() }}
Before you update
- @for (r of beforeRecommendations; track $index) { + @for (r of beforeRecommendations; track $index) {
- {{getComplexityLevelName(r.level)}}
+ {{ getComplexityLevelName(r.level) }}
Update to the new version
- {{getComplexityLevelName(r.level)}}
+ {{ getComplexityLevelName(r.level) }}
After you update
- {{getComplexityLevelName(r.level)}}
+ {{ getComplexityLevelName(r.level) }}
diff --git a/adev-ja/src/app/features/update/update.component.html b/adev-ja/src/app/features/update/update.component.html
index 1d7b1257a8..1aa79160aa 100644
--- a/adev-ja/src/app/features/update/update.component.html
+++ b/adev-ja/src/app/features/update/update.component.html
@@ -19,7 +19,7 @@ Angularバージョン
-
@for (version of versions; track $index) {
Angularバージョン
-
@for (version of versions; track $index) {
Angularバージョン
} - @if ((to.number - from.number > 150) && from.number > 240) { + @if (to.number - from.number > 150 && from.number > 240) {警告: @@ -86,7 +86,7 @@
アプリケーションの複雑さ
その他の依存関係
パッケージマネージャー
@if ( - beforeRecommendations.length > 0 || duringRecommendations.length > 0 || afterRecommendations.length > 0 + beforeRecommendations.length > 0 || + duringRecommendations.length > 0 || + afterRecommendations.length > 0 ) {
-
@@ -191,7 +193,7 @@ {{title()}}
+{{ title() }}
アップデート前
- @for (r of beforeRecommendations; track $index) { + @for (r of beforeRecommendations; track $index) {
- {{getComplexityLevelName(r.level)}}
+ {{ getComplexityLevelName(r.level) }}
新しいバージョンにアップデートする
- {{getComplexityLevelName(r.level)}}
+ {{ getComplexityLevelName(r.level) }}
アップデート後
- {{getComplexityLevelName(r.level)}}
+ {{ getComplexityLevelName(r.level) }}
diff --git a/adev-ja/src/app/routing/sub-navigation-data.en.ts b/adev-ja/src/app/routing/sub-navigation-data.en.ts
index a5f0cdd05a..2ebf4da2c0 100644
--- a/adev-ja/src/app/routing/sub-navigation-data.en.ts
+++ b/adev-ja/src/app/routing/sub-navigation-data.en.ts
@@ -475,6 +475,11 @@ const DOCS_SUB_NAVIGATION_DATA: NavigationItem[] = [
path: 'guide/forms/signals/comparison',
contentPath: 'guide/forms/signals/comparison',
},
+ {
+ label: 'Migrating from Legacy Forms',
+ path: 'guide/forms/signals/migration',
+ contentPath: 'guide/forms/signals/migration',
+ },
],
},
{
@@ -618,11 +623,6 @@ const DOCS_SUB_NAVIGATION_DATA: NavigationItem[] = [
path: 'guide/testing/utility-apis',
contentPath: 'guide/testing/utility-apis',
},
- {
- label: 'Zone.js Testing Utilities',
- path: 'guide/testing/zone-js-testing-utilities',
- contentPath: 'guide/testing/zone-js-testing-utilities',
- },
{
label: 'Component harnesses overview',
path: 'guide/testing/component-harnesses-overview',
@@ -653,6 +653,11 @@ const DOCS_SUB_NAVIGATION_DATA: NavigationItem[] = [
path: 'guide/testing/karma',
contentPath: 'guide/testing/karma',
},
+ {
+ label: 'Zone.js Testing Utilities',
+ path: 'guide/testing/zone-js-testing-utilities',
+ contentPath: 'guide/testing/zone-js-testing-utilities',
+ },
],
},
{
diff --git a/adev-ja/src/app/routing/sub-navigation-data.ts b/adev-ja/src/app/routing/sub-navigation-data.ts
index a08ba4d01c..f45ec5202f 100644
--- a/adev-ja/src/app/routing/sub-navigation-data.ts
+++ b/adev-ja/src/app/routing/sub-navigation-data.ts
@@ -475,6 +475,11 @@ const DOCS_SUB_NAVIGATION_DATA: NavigationItem[] = [
path: 'guide/forms/signals/comparison',
contentPath: 'guide/forms/signals/comparison',
},
+ {
+ label: 'Migrating from Legacy Forms',
+ path: 'guide/forms/signals/migration',
+ contentPath: 'guide/forms/signals/migration',
+ },
],
},
{
@@ -618,11 +623,6 @@ const DOCS_SUB_NAVIGATION_DATA: NavigationItem[] = [
path: 'guide/testing/utility-apis',
contentPath: 'guide/testing/utility-apis',
},
- {
- label: 'Zone.jsテストユーティリティ',
- path: 'guide/testing/zone-js-testing-utilities',
- contentPath: 'guide/testing/zone-js-testing-utilities',
- },
{
label: 'コンポーネントハーネスの概要',
path: 'guide/testing/component-harnesses-overview',
@@ -653,6 +653,11 @@ const DOCS_SUB_NAVIGATION_DATA: NavigationItem[] = [
path: 'guide/testing/karma',
contentPath: 'guide/testing/karma',
},
+ {
+ label: 'Zone.jsテストユーティリティ',
+ path: 'guide/testing/zone-js-testing-utilities',
+ contentPath: 'guide/testing/zone-js-testing-utilities',
+ },
],
},
{
diff --git a/adev-ja/src/content/ai/design-patterns.en.md b/adev-ja/src/content/ai/design-patterns.en.md
index cdcd7530d3..d40582e24c 100644
--- a/adev-ja/src/content/ai/design-patterns.en.md
+++ b/adev-ja/src/content/ai/design-patterns.en.md
@@ -27,11 +27,14 @@ storyResource = resource({
loader: ({params}): Promise`-E` | `string` | Enable an [experimental tool](#experimental-tools). Separate multiple options by spaces, e.g. `-E tool_a tool_b`. | | +| Option | Type | Description | Default | +| :---------------------------- | :-------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------ | +| `--read-only` | `boolean` | Only register tools that do not make changes to the project. Your editor or coding agent may still perform edits. | `false` | +| `--local-only` | `boolean` | Only register tools that do not require an internet connection. Your editor or coding agent may still send data over the network. | `false` | +| `--experimental-tool`
`-E` | `string` | Enable an [experimental tool](#experimental-tools). Separate multiple options by spaces, e.g. `-E tool_a tool_b`. You can also enable tool groups like `devserver` to enable all related tools at once, e.g. `-E devserver`. | | For example, to run the server in read-only mode in VS Code, you would update your `mcp.json` like this: diff --git a/adev-ja/src/content/ai/mcp-server-setup.md b/adev-ja/src/content/ai/mcp-server-setup.md index 0730e6c368..ec20c1d2e1 100644 --- a/adev-ja/src/content/ai/mcp-server-setup.md +++ b/adev-ja/src/content/ai/mcp-server-setup.md @@ -22,10 +22,10 @@ Angular CLI MCPサーバーは、開発ワークフローを支援するいく | 名前 | 説明 | `local-only` | `read-only` | | :------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------: | :---------: | | `build` | `ng build`を使用して、1回限りの非監視ビルドを実行します。 | ✅ | ❌ | -| `modernize` | コード移行を実行し、最新のベストプラクティスと構文に合わせてAngularコードをモダナイズする方法についてさらなる指示を提供します。[詳細を見る](https://angular.dev/reference/migrations) | ✅ | ❌ | -| `start_devserver` | ワークスペースの変更を監視する開発サーバーを非同期に起動します。`ng serve`の実行に似ています。これは非同期であるため、即座に戻ります。結果として得られるサーバーを管理するには、`stop_devserver`および`wait_for_devserver_build`ツールを使用します。 | ✅ | ✅ | -| `stop_devserver` | `start_devserver`によって起動された開発サーバーを停止します。 | ✅ | ✅ | -| `wait_for_devserver_build` | `start_devserver`によって起動された実行中の開発サーバーにおける最新のビルドの出力ログを返します。ビルドが現在進行中の場合、まずそのビルドが完了するのを待ってからログを返します。 | ✅ | ✅ | +| `modernize` | コード移行を実行し、最新のベストプラクティスと構文に合わせてAngularコードをモダナイズする方法についてさらなる指示を提供します。[詳細を見る](/reference/migrations) | ✅ | ❌ | +| `devserver.start` | ワークスペースの変更を監視する開発サーバーを非同期に起動します。`ng serve`の実行に似ています。これは非同期であるため、即座に戻ります。結果として得られるサーバーを管理するには、`devserver.stop`および`devserver.wait_for_build`ツールを使用します。 | ✅ | ✅ | +| `devserver.stop` | `devserver.start`によって起動された開発サーバーを停止します。 | ✅ | ✅ | +| `devserver.wait_for_build` | `devserver.start`によって起動された実行中の開発サーバーにおける最新のビルドの出力ログを返します。ビルドが現在進行中の場合、まずそのビルドが完了するのを待ってからログを返します。 | ✅ | ✅ | ## 開始方法 {#get-started} @@ -133,11 +133,11 @@ MCPサーバーの設定に関する最新の手順については、JetBrains `mcp`コマンドは、IDEのMCP設定で引数として渡される以下のオプションで設定できます： -| オプション | 型 | 説明 | デフォルト | -| :---------------------------- | :-------- | :----------------------------------------------------------------------------------------------------------------------------------------------- | :--------- | -| `--read-only` | `boolean` | プロジェクトに変更を加えないツールのみを登録します。エディタまたはコーディングエージェントは引き続き編集を実行する場合があります。 | `false` | -| `--local-only` | `boolean` | インターネット接続を必要としないツールのみを登録します。エディタまたはコーディングエージェントは引き続きネットワーク経由でデータを送信する場合があります。 | `false` | -| `--experimental-tool`
`-E` | `string` | [実験的ツール](#experimental-tools)を有効にします。複数のオプションをスペースで区切ります。例: `-E tool_a tool_b`。 | | +| オプション | 型 | 説明 | デフォルト | +| :---------------------------- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------- | +| `--read-only` | `boolean` | プロジェクトに変更を加えないツールのみを登録します。エディタまたはコーディングエージェントは引き続き編集を実行する場合があります。 | `false` | +| `--local-only` | `boolean` | インターネット接続を必要としないツールのみを登録します。エディタまたはコーディングエージェントは引き続きネットワーク経由でデータを送信する場合があります。 | `false` | +| `--experimental-tool`
`-E` | `string` | [実験的ツール](#experimental-tools)を有効にします。複数のオプションをスペースで区切ります。例: `-E tool_a tool_b`。`devserver`のようなツールグループを有効にして、関連するすべてのツールを一度に有効にすることもできます。例: `-E devserver`。 | | たとえば、VS Codeにおいて読み取り専用モードでサーバーを実行する場合は、`mcp.json`を次のように更新します： diff --git a/adev-ja/src/content/best-practices/error-handling.en.md b/adev-ja/src/content/best-practices/error-handling.en.md index c4cd17a7f6..d9cb07d367 100644 --- a/adev-ja/src/content/best-practices/error-handling.en.md +++ b/adev-ja/src/content/best-practices/error-handling.en.md @@ -37,10 +37,9 @@ export class GlobalErrorHandler implements ErrorHandler { description: `Screen: ${url} | ${errorMessage}`, }); - console.error(GlobalErrorHandler.name, { error }); + console.error(GlobalErrorHandler.name, {error}); } } - ``` ### `TestBed` rethrows errors by default diff --git a/adev-ja/src/content/best-practices/error-handling.md b/adev-ja/src/content/best-practices/error-handling.md index a8588f63fb..94e84906f9 100644 --- a/adev-ja/src/content/best-practices/error-handling.md +++ b/adev-ja/src/content/best-practices/error-handling.md @@ -37,10 +37,9 @@ export class GlobalErrorHandler implements ErrorHandler { description: `Screen: ${url} | ${errorMessage}`, }); - console.error(GlobalErrorHandler.name, { error }); + console.error(GlobalErrorHandler.name, {error}); } } - ``` ### `TestBed`はデフォルトでエラーを再スローします {#testbed-rethrows-errors-by-default} diff --git a/adev-ja/src/content/best-practices/runtime-performance/profiling-with-chrome-devtools.md b/adev-ja/src/content/best-practices/runtime-performance/profiling-with-chrome-devtools.md index c78d6c28ef..67a98b65e0 100644 --- a/adev-ja/src/content/best-practices/runtime-performance/profiling-with-chrome-devtools.md +++ b/adev-ja/src/content/best-practices/runtime-performance/profiling-with-chrome-devtools.md @@ -34,9 +34,9 @@ Angular profiling works exclusively in development mode. Here is an example of how you can enable the integration in the application bootstrap to capture all possible events: ```ts -import { enableProfiling } from '@angular/core'; -import { bootstrapApplication } from '@angular/platform-browser'; -import { MyApp } from './my-app'; +import {enableProfiling} from '@angular/core'; +import {bootstrapApplication} from '@angular/platform-browser'; +import {MyApp} from './my-app'; // Turn on profiling *before* bootstrapping your application // in order to capture all of the code run on start-up. diff --git a/adev-ja/src/content/best-practices/runtime-performance/skipping-subtrees.en.md b/adev-ja/src/content/best-practices/runtime-performance/skipping-subtrees.en.md index 05160e1ce5..02304d483b 100644 --- a/adev-ja/src/content/best-practices/runtime-performance/skipping-subtrees.en.md +++ b/adev-ja/src/content/best-practices/runtime-performance/skipping-subtrees.en.md @@ -16,7 +16,7 @@ OnPush change detection instructs Angular to run change detection for a componen You can set the change detection strategy of a component to `OnPush` in the `@Component` decorator: ```ts -import { ChangeDetectionStrategy, Component } from '@angular/core'; +import {ChangeDetectionStrategy, Component} from '@angular/core'; @Component({ changeDetection: ChangeDetectionStrategy.OnPush, diff --git a/adev-ja/src/content/best-practices/runtime-performance/skipping-subtrees.md b/adev-ja/src/content/best-practices/runtime-performance/skipping-subtrees.md index 2be97dc837..77167acbed 100644 --- a/adev-ja/src/content/best-practices/runtime-performance/skipping-subtrees.md +++ b/adev-ja/src/content/best-practices/runtime-performance/skipping-subtrees.md @@ -16,7 +16,7 @@ OnPush変更検知は、Angularにコンポーネントのサブツリーの変 コンポーネントの変更検知戦略を`@Component`デコレーターで`OnPush`に設定できます。 ```ts -import { ChangeDetectionStrategy, Component } from '@angular/core'; +import {ChangeDetectionStrategy, Component} from '@angular/core'; @Component({ changeDetection: ChangeDetectionStrategy.OnPush, diff --git a/adev-ja/src/content/best-practices/style-guide.en.md b/adev-ja/src/content/best-practices/style-guide.en.md index 9277e92d47..6b32e76466 100644 --- a/adev-ja/src/content/best-practices/style-guide.en.md +++ b/adev-ja/src/content/best-practices/style-guide.en.md @@ -196,7 +196,9 @@ properties initialized by `input`, `model`, `output`, and queries. The readonly ensures that the value set by Angular is not overwritten. ```ts -@Component({/* ... */}) +@Component({ + /* ... */ +}) export class UserProfile { readonly userId = input(); readonly userSaved = output(); @@ -208,7 +210,9 @@ For components and directives that use the decorator-based `@Input`, `@Output`, advice applies to output properties and queries, but not input properties. ```ts -@Component({/* ... */}) +@Component({ + /* ... */ +}) export class UserProfile { @Output() readonly userSaved = new EventEmitter
-
-
-
-
+
```
```html {avoid}
+
+
+
+
+
+
-();
@ViewChildren(PaymentMethod) readonly paymentMethods?: QueryList;
@@ -221,15 +225,19 @@ export class UserProfile {
```html {prefer}
+
+
```
Both `class` and `style` bindings use a more straightforward syntax that aligns closely with
@@ -267,8 +275,9 @@ single well-named handler. In these cases, it's fine to fall back to a name like
then delegate to more specific behaviors based on the event details:
```ts
-
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
class RichText {
handleKeydown(event: KeyboardEvent) {
if (event.ctrlKey) {
@@ -277,7 +286,7 @@ class RichText {
} else if (event.key === 'I') {
this.activateItalic();
}
-// ...
+ // ...
}
}
}
@@ -313,10 +322,13 @@ your class, import and `implement` these interfaces to ensure that the methods a
```ts
import {Component, OnInit} from '@angular/core';
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
export class UserProfile implements OnInit {
-
// The `OnInit` interface ensures this method is named correctly.
- ngOnInit() { /* ... */ }
+ ngOnInit() {
+ /* ... */
+ }
}
```
diff --git a/adev-ja/src/content/best-practices/style-guide.md b/adev-ja/src/content/best-practices/style-guide.md
index 1f4ddb18c6..fc541f67c0 100644
--- a/adev-ja/src/content/best-practices/style-guide.md
+++ b/adev-ja/src/content/best-practices/style-guide.md
@@ -196,7 +196,9 @@ Angularによって初期化されるコンポーネントとディレクティ
readonlyアクセス修飾子は、Angularによって設定された値が上書きされないことを保証します。
```ts
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
export class UserProfile {
readonly userId = input();
readonly userSaved = output();
@@ -208,7 +210,9 @@ export class UserProfile {
このアドバイスは出力プロパティとクエリに適用されますが、入力プロパティには適用されません。
```ts
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
export class UserProfile {
@Output() readonly userSaved = new EventEmitter
-
-
-
-
+
```
```html {avoid}
+
+
+
+
+
+
- = listenToPointerMoves();
+ pointerMoves$: Observable = listenToPointerMoves();
- // Whenever `pointerMoves$` emits, the `pointerMove` event fires.
- pointerMove = outputFromObservable(this.pointerMoves$);
+ // Whenever `pointerMoves$` emits, the `pointerMove` event fires.
+ pointerMove = outputFromObservable(this.pointerMoves$);
}
```
diff --git a/adev-ja/src/content/ecosystem/rxjs-interop/signals-interop.md b/adev-ja/src/content/ecosystem/rxjs-interop/signals-interop.md
index 2ab060e0cd..ee763e37af 100644
--- a/adev-ja/src/content/ecosystem/rxjs-interop/signals-interop.md
+++ b/adev-ja/src/content/ecosystem/rxjs-interop/signals-interop.md
@@ -62,20 +62,20 @@ Some observables may emit values that are **equals** even though they differ by
When two emitted values are considered equal, the resulting signal **does not update**. This prevents redundant computations, DOM updates, or effects from re-running unnecessarily.
```ts
-import { Component } from '@angular/core';
-import { toSignal } from '@angular/core/rxjs-interop';
-import { interval, map } from 'rxjs';
+import {Component} from '@angular/core';
+import {toSignal} from '@angular/core/rxjs-interop';
+import {interval, map} from 'rxjs';
@Component(/* ... */)
export class EqualExample {
temperature$ = interval(1000).pipe(
- map(() => ({ temperature: Math.floor(Math.random() * 3) + 20 }) ) // 20, 21, or 22 randomly
+ map(() => ({temperature: Math.floor(Math.random() * 3) + 20})), // 20, 21, or 22 randomly
);
// Only update if the temperature changes
temperature = toSignal(this.temperature$, {
- initialValue: { temperature : 20 },
- equal: (prev, curr) => prev.temperature === curr.temperature
+ initialValue: {temperature: 20},
+ equal: (prev, curr) => prev.temperature === curr.temperature,
});
}
```
@@ -91,17 +91,15 @@ If an Observable used in `toSignal` completes, the signal continues to return th
Use the `toObservable` utility to create an `Observable` which tracks the value of a signal. The signal's value is monitored with an `effect` which emits the value to the Observable when it changes.
```ts
-import { Component, signal } from '@angular/core';
-import { toObservable } from '@angular/core/rxjs-interop';
+import {Component, signal} from '@angular/core';
+import {toObservable} from '@angular/core/rxjs-interop';
@Component(/* ... */)
export class SearchResults {
query: Signal = inject(QueryService).query;
query$ = toObservable(this.query);
- results$ = this.query$.pipe(
- switchMap(query => this.http.get('/search?q=' + query ))
- );
+ results$ = this.query$.pipe(switchMap((query) => this.http.get('/search?q=' + query)));
}
```
@@ -119,7 +117,7 @@ Unlike Observables, signals never provide a synchronous notification of changes.
```ts
const obs$ = toObservable(mySignal);
-obs$.subscribe(value => console.log(value));
+obs$.subscribe((value) => console.log(value));
mySignal.set(1);
mySignal.set(2);
@@ -146,7 +144,7 @@ export class UserProfile {
protected userId = input();
private userResource = rxResource({
- params: () => ({ userId: this.userId() }),
+ params: () => ({userId: this.userId()}),
// The `stream` property expects a factory function that returns
// a data stream as an RxJS Observable.
diff --git a/adev-ja/src/content/ecosystem/rxjs-interop/take-until-destroyed.md b/adev-ja/src/content/ecosystem/rxjs-interop/take-until-destroyed.md
index 19e8a4294b..fc94b13d50 100644
--- a/adev-ja/src/content/ecosystem/rxjs-interop/take-until-destroyed.md
+++ b/adev-ja/src/content/ecosystem/rxjs-interop/take-until-destroyed.md
@@ -18,7 +18,7 @@ export class UserProfile {
// This subscription the 'notifications' Observable is automatically
// unsubscribed when the 'UserProfile' component is destroyed.
const messages: Observable = this.dispatcher.notifications;
- messages.pipe(takeUntilDestroyed()).subscribe(message => {
+ messages.pipe(takeUntilDestroyed()).subscribe((message) => {
this.popup.show(message);
});
}
@@ -38,7 +38,7 @@ export class UserProfile {
// Always pass a `DestroyRef` if you call `takeUntilDestroyed` outside
// of an injection context.
const messages: Observable = this.dispatcher.notifications;
- messages.pipe(takeUntilDestroyed(this.destroyRef)).subscribe(message => {
+ messages.pipe(takeUntilDestroyed(this.destroyRef)).subscribe((message) => {
this.popup.show(message);
});
}
diff --git a/adev-ja/src/content/ecosystem/service-workers/app-shell.md b/adev-ja/src/content/ecosystem/service-workers/app-shell.md
index 31e86a0a83..7a7d9afc4c 100644
--- a/adev-ja/src/content/ecosystem/service-workers/app-shell.md
+++ b/adev-ja/src/content/ecosystem/service-workers/app-shell.md
@@ -26,7 +26,7 @@ For more information about this command, see [App shell command](cli/generate/ap
The command updates the application code and adds extra files to the project structure.
-
+```text
src
├── app
│ ├── app.config.server.ts # server application configuration
@@ -36,7 +36,7 @@ src
│ ├── app-shell.component.spec.ts
│ └── app-shell.component.ts
└── main.server.ts # main server application bootstrapping
-
+```
diff --git a/adev-ja/src/content/ecosystem/service-workers/config.md b/adev-ja/src/content/ecosystem/service-workers/config.md
index 8f1333947f..9a6500f887 100644
--- a/adev-ja/src/content/ecosystem/service-workers/config.md
+++ b/adev-ja/src/content/ecosystem/service-workers/config.md
@@ -354,14 +354,12 @@ The URL query is ignored when matching.
If the field is omitted, it defaults to:
```ts
-
[
-'/**', // Include all URLs.
-'!/**/*.*', // Exclude URLs to files (containing a file extension in the last segment).
-'!/**/*__*', // Exclude URLs containing `__` in the last segment.
-'!/**/*__*/**', // Exclude URLs containing `__` in any other segment.
-]
-
+ '/**', // Include all URLs.
+ '!/**/*.*', // Exclude URLs to files (containing a file extension in the last segment).
+ '!/**/*__*', // Exclude URLs containing `__` in the last segment.
+ '!/**/*__*/**', // Exclude URLs containing `__` in any other segment.
+];
```
### `navigationRequestStrategy`
@@ -369,7 +367,6 @@ If the field is omitted, it defaults to:
This optional property enables you to configure how the service worker handles navigation requests:
```json
-
{
"navigationRequestStrategy": "freshness"
}
diff --git a/adev-ja/src/content/ecosystem/service-workers/custom-service-worker-scripts.md b/adev-ja/src/content/ecosystem/service-workers/custom-service-worker-scripts.md
index d5fdcaa6dd..2a5dbaeac9 100644
--- a/adev-ja/src/content/ecosystem/service-workers/custom-service-worker-scripts.md
+++ b/adev-ja/src/content/ecosystem/service-workers/custom-service-worker-scripts.md
@@ -73,8 +73,8 @@ importScripts('./ngsw-worker.js');
3. Configure the service worker registration to use your custom script:
```ts
-import { ApplicationConfig, isDevMode } from '@angular/core';
-import { provideServiceWorker } from '@angular/service-worker';
+import {ApplicationConfig, isDevMode} from '@angular/core';
+import {provideServiceWorker} from '@angular/service-worker';
export const appConfig: ApplicationConfig = {
providers: [
diff --git a/adev-ja/src/content/ecosystem/service-workers/getting-started.md b/adev-ja/src/content/ecosystem/service-workers/getting-started.md
index 268a3a1870..a99bb75ca7 100644
--- a/adev-ja/src/content/ecosystem/service-workers/getting-started.md
+++ b/adev-ja/src/content/ecosystem/service-workers/getting-started.md
@@ -166,9 +166,8 @@ Angular service workers support comprehensive configuration options through the
The `enabled` option controls whether the service worker will be registered and related services will attempt to communicate with it.
```ts
-
-import { ApplicationConfig, isDevMode } from '@angular/core';
-import { provideServiceWorker } from '@angular/service-worker';
+import {ApplicationConfig, isDevMode} from '@angular/core';
+import {provideServiceWorker} from '@angular/service-worker';
export const appConfig: ApplicationConfig = {
providers: [
@@ -177,7 +176,6 @@ export const appConfig: ApplicationConfig = {
}),
],
};
-
```
### Cache control with updateViaCache
@@ -185,7 +183,6 @@ export const appConfig: ApplicationConfig = {
The `updateViaCache` option controls how the browser consults the HTTP cache during service worker updates. This provides fine-grained control over when the browser fetches updated service worker scripts and imported modules.
```ts
-
export const appConfig: ApplicationConfig = {
providers: [
provideServiceWorker('ngsw-worker.js', {
@@ -194,7 +191,6 @@ export const appConfig: ApplicationConfig = {
}),
],
};
-
```
The `updateViaCache` option accepts the following values:
@@ -208,7 +204,6 @@ The `updateViaCache` option accepts the following values:
The `type` option enables specifying the script type when registering service workers, providing support for ES module features in your service worker scripts.
```ts
-
export const appConfig: ApplicationConfig = {
providers: [
provideServiceWorker('ngsw-worker.js', {
@@ -217,7 +212,6 @@ export const appConfig: ApplicationConfig = {
}),
],
};
-
```
The `type` option accepts the following values:
@@ -230,7 +224,6 @@ The `type` option accepts the following values:
The `scope` option defines the service worker's registration scope, determining what range of URLs it can control.
```ts
-
export const appConfig: ApplicationConfig = {
providers: [
provideServiceWorker('ngsw-worker.js', {
@@ -239,7 +232,6 @@ export const appConfig: ApplicationConfig = {
}),
],
};
-
```
- Controls which URLs the service worker can intercept and manage
@@ -251,7 +243,6 @@ export const appConfig: ApplicationConfig = {
The `registrationStrategy` option defines when the service worker will be registered with the browser, providing control over the timing of registration.
```ts
-
export const appConfig: ApplicationConfig = {
providers: [
provideServiceWorker('ngsw-worker.js', {
@@ -260,7 +251,6 @@ export const appConfig: ApplicationConfig = {
}),
],
};
-
```
Available registration strategies:
@@ -270,7 +260,6 @@ Available registration strategies:
- **`'registerWithDelay:timeout'`** - Register with a delay of the specified timeout in milliseconds
```ts
-
// Register immediately
export const immediateConfig: ApplicationConfig = {
providers: [
@@ -290,13 +279,12 @@ export const delayedConfig: ApplicationConfig = {
}),
],
};
-
```
You can also provide an Observable factory function for custom registration timing:
```ts
-import { timer } from 'rxjs';
+import {timer} from 'rxjs';
export const customConfig: ApplicationConfig = {
providers: [
@@ -306,7 +294,6 @@ export const customConfig: ApplicationConfig = {
}),
],
};
-
```
## More on Angular service workers
diff --git a/adev-ja/src/content/ecosystem/web-workers.md b/adev-ja/src/content/ecosystem/web-workers.md
index 9ebd9fcdcd..74ba773639 100644
--- a/adev-ja/src/content/ecosystem/web-workers.md
+++ b/adev-ja/src/content/ecosystem/web-workers.md
@@ -26,29 +26,26 @@ The command performs the following actions.
1. Adds the following scaffold code to `src/app/app.worker.ts` to receive messages.
```ts {header:"src/app/app.worker.ts"}
-
- addEventListener('message', ({ data }) => {
- const response = `worker response to ${data}`;
- postMessage(response);
- });
-
+ addEventListener('message', ({data}) => {
+ const response = `worker response to ${data}`;
+ postMessage(response);
+ });
```
1. Adds the following scaffold code to `src/app/app.component.ts` to use the worker.
```ts {header:"src/app/app.component.ts"}
-
- if (typeof Worker !== 'undefined') {
- // Create a new
- const worker = new Worker(new URL('./app.worker', import.meta.url));
- worker.onmessage = ({ data }) => {
- console.log(`page got message: ${data}`);
- };
- worker.postMessage('hello');
- } else {
- // Web workers are not supported in this environment.
- // You should add a fallback so that your program still executes correctly.
- }
+ if (typeof Worker !== 'undefined') {
+ // Create a new
+ const worker = new Worker(new URL('./app.worker', import.meta.url));
+ worker.onmessage = ({data}) => {
+ console.log(`page got message: ${data}`);
+ };
+ worker.postMessage('hello');
+ } else {
+ // Web workers are not supported in this environment.
+ // You should add a fallback so that your program still executes correctly.
+ }
```
After you create this initial scaffold, you must refactor your code to use the web worker by sending messages to and from the worker.
diff --git a/adev-ja/src/content/guide/animations/css.md b/adev-ja/src/content/guide/animations/css.md
index 5776ba5192..a88a32ef70 100644
--- a/adev-ja/src/content/guide/animations/css.md
+++ b/adev-ja/src/content/guide/animations/css.md
@@ -159,7 +159,9 @@ You can apply multiple animations to an element at once using the `animation` sh
```css
.target-element {
- animation: rotate 3s, fade-in 2s;
+ animation:
+ rotate 3s,
+ fade-in 2s;
}
```
diff --git a/adev-ja/src/content/guide/animations/enter-and-leave.en.md b/adev-ja/src/content/guide/animations/enter-and-leave.en.md
index 8ab48087de..2a994183a9 100644
--- a/adev-ja/src/content/guide/animations/enter-and-leave.en.md
+++ b/adev-ja/src/content/guide/animations/enter-and-leave.en.md
@@ -86,7 +86,7 @@ TestBed provides built-in support for enabling or disabling animations in your t
If you want to test that the animations are animating in a browser test, for example an end-to-end test, you can configure TestBed to enable animations by specifying `animationsEnabled: true` in your test configuration.
```typescript
- TestBed.configureTestingModule({animationsEnabled: true});
+TestBed.configureTestingModule({animationsEnabled: true});
```
This will configure animations in your test environment to behave normally.
diff --git a/adev-ja/src/content/guide/animations/enter-and-leave.md b/adev-ja/src/content/guide/animations/enter-and-leave.md
index fd08e4f892..243f06d667 100644
--- a/adev-ja/src/content/guide/animations/enter-and-leave.md
+++ b/adev-ja/src/content/guide/animations/enter-and-leave.md
@@ -86,7 +86,7 @@ TestBedは、テスト環境でアニメーションを有効または無効に
ブラウザテスト、例えばエンドツーエンドテストでアニメーションが動作していることをテストしたい場合は、テスト設定で`animationsEnabled: true`を指定することで、TestBedをアニメーションを有効にするように設定できます。
```typescript
- TestBed.configureTestingModule({animationsEnabled: true});
+TestBed.configureTestingModule({animationsEnabled: true});
```
これにより、テスト環境でのアニメーションが通常通りに動作するように設定されます。
diff --git a/adev-ja/src/content/guide/animations/migration.md b/adev-ja/src/content/guide/animations/migration.md
index aa91dfa00d..7872a9b507 100644
--- a/adev-ja/src/content/guide/animations/migration.md
+++ b/adev-ja/src/content/guide/animations/migration.md
@@ -245,7 +245,9 @@ The animations package has a `group()` function to play multiple animations at t
```css
.target-element {
- animation: rotate 3s, fade-in 2s;
+ animation:
+ rotate 3s,
+ fade-in 2s;
}
```
diff --git a/adev-ja/src/content/guide/animations/overview.md b/adev-ja/src/content/guide/animations/overview.md
index fcfee29661..04981eaa65 100644
--- a/adev-ja/src/content/guide/animations/overview.md
+++ b/adev-ja/src/content/guide/animations/overview.md
@@ -34,9 +34,7 @@ Import `provideAnimationsAsync` from `@angular/platform-browser/animations/async
```ts {header: "Enabling Animations", linenums}
bootstrapApplication(AppComponent, {
- providers: [
- provideAnimationsAsync(),
- ]
+ providers: [provideAnimationsAsync()],
});
```
@@ -127,13 +125,13 @@ The `animate()` function \(second argument of the transition function\) accepts
The `timings` parameter takes either a number or a string defined in three parts.
```ts
-animate (duration)
+animate(duration);
```
or
```ts
-animate ('duration delay easing')
+animate('duration delay easing');
```
The first part, `duration`, is required.
@@ -191,7 +189,7 @@ HELPFUL: Some additional notes on using styles within [`state`](api/animations/s
- Include multiple state pairs within the same `transition()` argument:
```ts
- transition( 'on => off, off => void' )
+ transition('on => off, off => void');
```
### Triggering the animation
diff --git a/adev-ja/src/content/guide/aria/toolbar.en.md b/adev-ja/src/content/guide/aria/toolbar.en.md
index 3f204d5cc0..926e8c4410 100644
--- a/adev-ja/src/content/guide/aria/toolbar.en.md
+++ b/adev-ja/src/content/guide/aria/toolbar.en.md
@@ -135,22 +135,14 @@ The `multi` input controls whether multiple widgets within a group can be select
```html {highlight: [15]}
-
+
+
```
`class`および`style`バインディングはどちらも、
@@ -267,8 +275,9 @@ export class UserProfile {
イベントの詳細に基づいてより具体的な動作に委譲しても問題ありません。
```ts
-
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
class RichText {
handleKeydown(event: KeyboardEvent) {
if (event.ctrlKey) {
@@ -277,7 +286,7 @@ class RichText {
} else if (event.key === 'I') {
this.activateItalic();
}
-// ...
+ // ...
}
}
}
@@ -313,10 +322,13 @@ Angularは、各ライフサイクルメソッドに対応するTypeScriptイン
```ts
import {Component, OnInit} from '@angular/core';
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
export class UserProfile implements OnInit {
-
// The `OnInit` interface ensures this method is named correctly.
- ngOnInit() { /* ... */ }
+ ngOnInit() {
+ /* ... */
+ }
}
```
diff --git a/adev-ja/src/content/ecosystem/rxjs-interop/output-interop.md b/adev-ja/src/content/ecosystem/rxjs-interop/output-interop.md
index bd9faff699..5990164ab7 100644
--- a/adev-ja/src/content/ecosystem/rxjs-interop/output-interop.md
+++ b/adev-ja/src/content/ecosystem/rxjs-interop/output-interop.md
@@ -8,16 +8,18 @@ The `@angular/rxjs-interop` package offers two APIs related to component and dir
The `outputFromObservable` lets you create a component or directive output that emits based on an RxJS observable:
-```ts {highlight:[9]}
+```ts {highlight:[11]}
import {Directive} from '@angular/core';
import {outputFromObservable} from '@angular/core/rxjs-interop';
-@Directive({/*...*/})
+@Directive({
+ /*...*/
+})
class Draggable {
- pointerMoves$: Observable
+
-
+
diff --git a/adev-ja/src/content/guide/aria/toolbar.md b/adev-ja/src/content/guide/aria/toolbar.md
index 280ca3a99b..b78aaf37b0 100644
--- a/adev-ja/src/content/guide/aria/toolbar.md
+++ b/adev-ja/src/content/guide/aria/toolbar.md
@@ -135,22 +135,14 @@ Angularのツールバーは、以下の機能を備えた完全にアクセシ
```html {highlight: [15]}
-
+
-
+
diff --git a/adev-ja/src/content/guide/components/anatomy-of-components.en.md b/adev-ja/src/content/guide/components/anatomy-of-components.en.md
index 924843ad34..c9732799a0 100644
--- a/adev-ja/src/content/guide/components/anatomy-of-components.en.md
+++ b/adev-ja/src/content/guide/components/anatomy-of-components.en.md
@@ -44,7 +44,7 @@ You can alternatively choose to write your template and styles in separate files
templateUrl: 'profile-photo.html',
styleUrl: 'profile-photo.css',
})
-export class ProfilePhoto { }
+export class ProfilePhoto {}
```
This can help separate the concerns of _presentation_ from _behavior_ in your project. You can choose one approach for your entire project, or you decide which to use for each component.
@@ -67,7 +67,7 @@ import {ProfilePhoto} from './profile-photo';
imports: [ProfilePhoto],
/* ... */
})
-export class UserProfile { }
+export class UserProfile {}
```
By default, Angular components are _standalone_, meaning that you can directly add them to the `imports` array of other components. Components created with an earlier version of Angular may instead specify `standalone: false` in their `@Component` decorator. For these components, you instead import the `NgModule` in which the component is defined. See the full [`NgModule` guide](guide/ngmodules) for details.
diff --git a/adev-ja/src/content/guide/components/anatomy-of-components.md b/adev-ja/src/content/guide/components/anatomy-of-components.md
index 8e28dda770..53464d6882 100644
--- a/adev-ja/src/content/guide/components/anatomy-of-components.md
+++ b/adev-ja/src/content/guide/components/anatomy-of-components.md
@@ -44,7 +44,7 @@ export class ProfilePhoto { }
templateUrl: 'profile-photo.html',
styleUrl: 'profile-photo.css',
})
-export class ProfilePhoto { }
+export class ProfilePhoto {}
```
これにより、プロジェクト内の_表示_と_動作_の懸念事項を分離できます。プロジェクト全体に対して1つのアプローチを選択するか、コンポーネントごとにどちらを使用するかを決定できます。
@@ -67,7 +67,7 @@ import {ProfilePhoto} from './profile-photo';
imports: [ProfilePhoto],
/* ... */
})
-export class UserProfile { }
+export class UserProfile {}
```
デフォルトでは、Angularコンポーネントは*スタンドアロン*です。つまり、他のコンポーネントの`imports`配列に直接追加できます。以前のバージョンのAngularで作成されたコンポーネントは、代わりに`@Component`デコレーターで`standalone: false`を指定している場合があります。これらのコンポーネントの場合、代わりにコンポーネントが定義されている`NgModule`をインポートします。詳細は、完全な[`NgModule`ガイド](guide/ngmodules)を参照してください。
diff --git a/adev-ja/src/content/guide/components/inputs.en.md b/adev-ja/src/content/guide/components/inputs.en.md
index 73651d7573..0b2d8236f9 100644
--- a/adev-ja/src/content/guide/components/inputs.en.md
+++ b/adev-ja/src/content/guide/components/inputs.en.md
@@ -10,7 +10,9 @@ When you use a component, you commonly want to pass some data to it. A component
```ts {highlight:[5]}
import {Component, input} from '@angular/core';
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
// Declare an input named 'value' with a default value of zero.
value = input(0);
@@ -26,7 +28,9 @@ This lets you bind to the property in a template:
If an input has a default value, TypeScript infers the type from the default value:
```ts
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
// TypeScript infers that this input is a number, returning InputSignal.
value = input(0);
@@ -38,7 +42,9 @@ You can explicitly declare a type for the input by specifying a generic paramete
If an input without a default value is not set, its value is `undefined`:
```ts
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
// Produces an InputSignal because `value` may not be set.
value = input();
@@ -60,7 +66,9 @@ The `input` function returns an `InputSignal`. You can read the value by calling
```ts {highlight:[5]}
import {Component, input, computed} from '@angular/core';
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
// Declare an input named 'value' with a default value of zero.
value = input(0);
@@ -77,7 +85,9 @@ Signals created by the `input` function are read-only.
You can declare that an input is `required` by calling `input.required` instead of `input`:
```ts {highlight:[3]}
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
// Declare a required input named value. Returns an `InputSignal`.
value = input.required();
@@ -127,7 +137,9 @@ The most common use-case for input transforms is to accept a wider range of valu
When you specify an input transform, the type of the transform function's parameter determines the types of values that can be set to the input in a template.
```ts
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
widthPx = input('', {transform: appendPx});
}
@@ -146,7 +158,9 @@ Angular includes two built-in transform functions for the two most common scenar
```ts
import {Component, input, booleanAttribute, numberAttribute} from '@angular/core';
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
disabled = input(false, {transform: booleanAttribute});
value = input(0, {transform: numberAttribute});
@@ -163,7 +177,9 @@ _presence_ of the attribute indicates a "true" value. However, Angular's `boolea
You can specify the `alias` option to change the name of an input in templates.
```ts {highlight:[3]}
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
value = input(0, {alias: 'sliderValue'});
}
@@ -186,14 +202,16 @@ When creating a component, you can define a model input similarly to how you cre
Both types of input allow someone to bind a value into the property. However, **model inputs allow the component author to write values into the property**. If the property is bound with a two-way binding, the new value propagates to that binding.
```ts
-@Component({ /* ... */})
+@Component({
+ /* ... */
+})
export class CustomSlider {
// Define a model input named "value".
value = model(0);
increment() {
// Update the model input with a new value, propagating the value to any bindings.
- this.value.update(oldValue => oldValue + 10);
+ this.value.update((oldValue) => oldValue + 10);
}
}
@@ -212,7 +230,7 @@ export class MediaControls {
In the above example, the `CustomSlider` can write values into its `value` model input, which then propagates those values back to the `volume` signal in `MediaControls`. This binding keeps the values of `value` and `volume` in sync. Notice that the binding passes the `volume` signal instance, not the _value_ of the signal.
-In other respects, model inputs work similarly to standard inputs. You can read the value by calling the signal function, including in reactive contexts like `computed` and `effect`.
+In other respects, model inputs work similarly to standard inputs. You can read the value by calling the signal function, including in [reactive contexts](guide/signals#reactive-contexts) like `computed` and `effect`.
See [Two-way binding](guide/templates/two-way-binding) for more details on two-way binding in templates.
@@ -239,7 +257,9 @@ In the example above, the `CustomSlider` can write values into its `value` model
When you declare a model input in a component or directive, Angular automatically creates a corresponding [output](guide/components/outputs) for that model. The output's name is the model input's name suffixed with "Change".
```ts
-@Directive({ /* ... */ })
+@Directive({
+ /* ... */
+})
export class CustomCheckbox {
// This automatically creates an output named "checkedChange".
// Can be subscribed to using `(checkedChange)="handler()"` in the template.
@@ -351,7 +371,9 @@ export class CustomSlider {
return this.internalValue;
}
- set value(newValue: number) { this.internalValue = newValue; }
+ set value(newValue: number) {
+ this.internalValue = newValue;
+ }
private internalValue = 0;
}
diff --git a/adev-ja/src/content/guide/components/inputs.md b/adev-ja/src/content/guide/components/inputs.md
index 5a995abc4a..52574fc20f 100644
--- a/adev-ja/src/content/guide/components/inputs.md
+++ b/adev-ja/src/content/guide/components/inputs.md
@@ -10,7 +10,9 @@ TIP: 他のウェブフレームワークに精通している場合は、入力
```ts {highlight:[5]}
import {Component, input} from '@angular/core';
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
// Declare an input named 'value' with a default value of zero.
value = input(0);
@@ -26,7 +28,9 @@ export class CustomSlider {
入力にデフォルト値がある場合、TypeScriptはデフォルト値から型を推論します。
```ts
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
// TypeScriptは、この入力が数値であると推論し、InputSignalを返します。
value = input(0);
@@ -38,7 +42,9 @@ export class CustomSlider {
デフォルト値のない入力が設定されていない場合、その値は`undefined`になります。
```ts
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
// `value`は設定されない可能性があるため、InputSignalを生成します。
value = input();
@@ -60,7 +66,9 @@ export class CustomSlider {
```ts {highlight:[5]}
import {Component, input, computed} from '@angular/core';
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
// Declare an input named 'value' with a default value of zero.
value = input(0);
@@ -77,7 +85,9 @@ export class CustomSlider {
`input`の代わりに`input.required`を呼び出すことで、入力が`required`であることを宣言できます。
```ts {highlight:[3]}
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
// Declare a required input named value. Returns an `InputSignal`.
value = input.required();
@@ -127,7 +137,9 @@ function trimString(value: string | undefined): string {
入力変換を指定すると、変換関数の引数の型によって、テンプレートで入力に設定できる値の型が決まります。
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
widthPx = input('', {transform: appendPx});
}
@@ -146,7 +158,9 @@ Angularには、最も一般的な2つのシナリオのための2つの組み
```ts
import {Component, input, booleanAttribute, numberAttribute} from '@angular/core';
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
disabled = input(false, {transform: booleanAttribute});
value = input(0, {transform: numberAttribute});
@@ -163,7 +177,9 @@ export class CustomSlider {
`alias`オプションを指定して、テンプレートでの入力の名前を変更できます。
```ts {highlight:[3]}
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
value = input(0, {alias: 'sliderValue'});
}
@@ -186,14 +202,16 @@ export class CustomSlider {
どちらの種類の入力も、値をプロパティにバインドすることを可能にします。しかし、**モデル入力は、コンポーネントの作者がプロパティに値を書き込むことを可能にします。**プロパティが双方向バインディングでバインドされている場合、新しい値はそのバインディングに伝播します。
```ts
-@Component({ /* ... */})
+@Component({
+ /* ... */
+})
export class CustomSlider {
// "value"という名前のモデル入力を定義します。
value = model(0);
increment() {
// 新しい値でモデル入力を更新し、値をすべてのバインディングに伝播します。
- this.value.update(oldValue => oldValue + 10);
+ this.value.update((oldValue) => oldValue + 10);
}
}
@@ -212,7 +230,7 @@ export class MediaControls {
上記の例では、`CustomSlider`は`value`モデル入力に値を書き込むことができ、それによって`MediaControls`の`volume`シグナルに値が伝播します。このバインディングにより、`value`と`volume`の値が同期します。バインディングはシグナルの_値_ではなく、`volume`シグナルのインスタンスを渡していることに注意してください。
-他の点では、モデル入力は標準入力と同様に機能します。`computed`や`effect`のようなリアクティブなコンテキスト内を含め、シグナル関数を呼び出すことで値を読み取ることができます。
+他の点では、モデル入力は標準入力と同様に機能します。`computed`や`effect`のような[リアクティブなコンテキスト](guide/signals#reactive-contexts)内を含め、シグナル関数を呼び出すことで値を読み取ることができます。
テンプレートでの双方向バインディングの詳細については、[双方向バインディング](guide/templates/two-way-binding)を参照してください。
@@ -239,7 +257,9 @@ export class MediaControls {
コンポーネントまたはディレクティブでモデル入力を宣言すると、Angularはそのモデルに対応する[出力](guide/components/outputs)を自動的に作成します。出力の名前は、モデル入力の名前に「Change」が付いたものです。
```ts
-@Directive({ /* ... */ })
+@Directive({
+ /* ... */
+})
export class CustomCheckbox {
// これにより、「checkedChange」という名前の出力が自動的に作成されます。
// テンプレートで `(checkedChange)="handler()"` を使用して購読できます。
@@ -351,7 +371,9 @@ export class CustomSlider {
return this.internalValue;
}
- set value(newValue: number) { this.internalValue = newValue; }
+ set value(newValue: number) {
+ this.internalValue = newValue;
+ }
private internalValue = 0;
}
diff --git a/adev-ja/src/content/guide/components/outputs.en.md b/adev-ja/src/content/guide/components/outputs.en.md
index 57a302cc3e..b21550ef9e 100644
--- a/adev-ja/src/content/guide/components/outputs.en.md
+++ b/adev-ja/src/content/guide/components/outputs.en.md
@@ -5,7 +5,9 @@ TIP: This guide assumes you've already read the [Essentials Guide](essentials).
Angular components can define custom events by assigning a property to the `output` function:
```ts {highlight:[3]}
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class ExpandablePanel {
panelClosed = output();
}
@@ -18,7 +20,7 @@ export class ExpandablePanel {
The `output` function returns an `OutputEmitterRef`. You can emit an event by calling the `emit` method on the `OutputEmitterRef`:
```ts
- this.panelClosed.emit();
+this.panelClosed.emit();
```
Angular refers to properties initialized with the `output` function as **outputs**. You can use outputs to raise custom events, similar to native browser events like `click`.
@@ -43,7 +45,7 @@ this.valueChanged.emit(7);
this.thumbDropped.emit({
pointerX: 123,
pointerY: 456,
-})
+});
```
When defining an event listener in a template, you can access the event data from the `$event` variable:
@@ -71,7 +73,9 @@ export class App {
The `output` function accepts a parameter that lets you specify a different name for the event in a template:
```ts
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
changed = output({alias: 'valueChanged'});
}
@@ -93,7 +97,7 @@ from the component instance. The `OutputRef` type includes a `subscribe` method:
```ts
const someComponentRef: ComponentRef = viewContainerRef.createComponent(/*...*/);
-someComponentRef.instance.someEventProperty.subscribe(eventData => {
+someComponentRef.instance.someEventProperty.subscribe((eventData) => {
console.log(eventData);
});
```
@@ -101,7 +105,7 @@ someComponentRef.instance.someEventProperty.subscribe(eventData => {
Angular automatically cleans up event subscriptions when it destroys components with subscribers. Alternatively, you can manually unsubscribe from an event. The `subscribe` function returns an `OutputRefSubscription` with an `unsubscribe` method:
```ts
-const eventSubscription = someComponent.someEventProperty.subscribe(eventData => {
+const eventSubscription = someComponent.someEventProperty.subscribe((eventData) => {
console.log(eventData);
});
@@ -130,7 +134,9 @@ original decorator-based `@Output` API remains fully supported.
You can alternatively define custom events by assigning a property to a new `EventEmitter` and adding the `@Output` decorator:
```ts
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class ExpandablePanel {
@Output() panelClosed = new EventEmitter();
}
@@ -143,7 +149,9 @@ You can emit an event by calling the `emit` method on the `EventEmitter`.
The `@Output` decorator accepts a parameter that lets you specify a different name for the event in a template:
```ts
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
@Output('valueChanged') changed = new EventEmitter();
}
diff --git a/adev-ja/src/content/guide/components/outputs.md b/adev-ja/src/content/guide/components/outputs.md
index e1941e6485..0c27cb9408 100644
--- a/adev-ja/src/content/guide/components/outputs.md
+++ b/adev-ja/src/content/guide/components/outputs.md
@@ -5,7 +5,9 @@ TIP: このガイドは、[基本概念のガイド](essentials) を既読して
Angularコンポーネントは、`output`関数にプロパティを割り当てることでカスタムイベントを定義できます。
```ts {highlight:[3]}
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class ExpandablePanel {
panelClosed = output();
}
@@ -18,7 +20,7 @@ export class ExpandablePanel {
`output`関数は`OutputEmitterRef`を返します。`OutputEmitterRef`の`emit`メソッドを呼び出すことで、イベントを発生させることができます。
```ts
- this.panelClosed.emit();
+this.panelClosed.emit();
```
Angularでは、`output`関数で初期化されたプロパティを**出力**と呼びます。出力を使用すると、`click`などのネイティブブラウザイベントと同様に、カスタムイベントを発生させることができます。
@@ -43,7 +45,7 @@ this.valueChanged.emit(7);
this.thumbDropped.emit({
pointerX: 123,
pointerY: 456,
-})
+});
```
テンプレートでイベントリスナーを定義する場合、`$event`変数からイベントデータにアクセスできます。
@@ -71,7 +73,9 @@ export class App {
`output`関数は、テンプレートでイベントに異なる名前を指定できるパラメーターを受け入れます。
```ts
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
changed = output({alias: 'valueChanged'});
}
@@ -93,7 +97,7 @@ export class CustomSlider {
```ts
const someComponentRef: ComponentRef = viewContainerRef.createComponent(/*...*/);
-someComponentRef.instance.someEventProperty.subscribe(eventData => {
+someComponentRef.instance.someEventProperty.subscribe((eventData) => {
console.log(eventData);
});
```
@@ -101,7 +105,7 @@ someComponentRef.instance.someEventProperty.subscribe(eventData => {
Angularは、サブスクライバーを持つコンポーネントを破棄するときに、イベントサブスクリプションを自動的にクリーンアップします。または、イベントから手動で購読解除できます。`subscribe`関数は、`unsubscribe`メソッドを持つ`OutputRefSubscription`を返します。
```ts
-const eventSubscription = someComponent.someEventProperty.subscribe(eventData => {
+const eventSubscription = someComponent.someEventProperty.subscribe((eventData) => {
console.log(eventData);
});
@@ -130,7 +134,9 @@ TIP: Angularチームは新規プロジェクトでは`output`関数の使用を
代替として、新しい`EventEmitter`にプロパティを割り当て、`@Output`デコレーターを追加することで、カスタムイベントを定義できます。
```ts
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class ExpandablePanel {
@Output() panelClosed = new EventEmitter();
}
@@ -143,7 +149,9 @@ export class ExpandablePanel {
`@Output`デコレーターは、テンプレートでイベントに異なる名前を指定できるパラメーターを受け入れます。
```ts
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomSlider {
@Output('valueChanged') changed = new EventEmitter();
}
diff --git a/adev-ja/src/content/guide/components/programmatic-rendering.en.md b/adev-ja/src/content/guide/components/programmatic-rendering.en.md
index 51887ae359..f1d2a2f051 100644
--- a/adev-ja/src/content/guide/components/programmatic-rendering.en.md
+++ b/adev-ja/src/content/guide/components/programmatic-rendering.en.md
@@ -174,12 +174,20 @@ export class AppWarningComponent {
```
```ts
-import { Component, ViewContainerRef, signal, inputBinding, outputBinding, twoWayBinding, inject } from '@angular/core';
-import { FocusTrap } from "@angular/cdk/a11y";
-import { ThemeDirective } from '../theme.directive';
+import {
+ Component,
+ ViewContainerRef,
+ signal,
+ inputBinding,
+ outputBinding,
+ twoWayBinding,
+ inject,
+} from '@angular/core';
+import {FocusTrap} from '@angular/cdk/a11y';
+import {ThemeDirective} from '../theme.directive';
@Component({
- template: `('close', (confirmed) => {
console.log('Closed with result:', confirmed);
- })
+ }),
],
directives: [
FocusTrap,
- { type: ThemeDirective, bindings: [inputBinding('theme', () => 'warning')] }
- ]
+ {type: ThemeDirective, bindings: [inputBinding('theme', () => 'warning')]},
+ ],
});
}
}
@@ -220,9 +228,9 @@ import {
inputBinding,
outputBinding,
} from '@angular/core';
-import { PopupComponent } from './popup.component';
+import {PopupComponent} from './popup.component';
-@Injectable({ providedIn: 'root' })
+@Injectable({providedIn: 'root'})
export class PopupService {
private readonly injector = inject(EnvironmentInjector);
private readonly appRef = inject(ApplicationRef);
diff --git a/adev-ja/src/content/guide/components/programmatic-rendering.md b/adev-ja/src/content/guide/components/programmatic-rendering.md
index 1147946182..1d7631d64f 100644
--- a/adev-ja/src/content/guide/components/programmatic-rendering.md
+++ b/adev-ja/src/content/guide/components/programmatic-rendering.md
@@ -174,12 +174,20 @@ export class AppWarningComponent {
```
```ts
-import { Component, ViewContainerRef, signal, inputBinding, outputBinding, twoWayBinding, inject } from '@angular/core';
-import { FocusTrap } from "@angular/cdk/a11y";
-import { ThemeDirective } from '../theme.directive';
+import {
+ Component,
+ ViewContainerRef,
+ signal,
+ inputBinding,
+ outputBinding,
+ twoWayBinding,
+ inject,
+} from '@angular/core';
+import {FocusTrap} from '@angular/cdk/a11y';
+import {ThemeDirective} from '../theme.directive';
@Component({
- template: `('close', (confirmed) => {
console.log('Closed with result:', confirmed);
- })
+ }),
],
directives: [
FocusTrap,
- { type: ThemeDirective, bindings: [inputBinding('theme', () => 'warning')] }
- ]
+ {type: ThemeDirective, bindings: [inputBinding('theme', () => 'warning')]},
+ ],
});
}
}
@@ -220,9 +228,9 @@ import {
inputBinding,
outputBinding,
} from '@angular/core';
-import { PopupComponent } from './popup.component';
+import {PopupComponent} from './popup.component';
-@Injectable({ providedIn: 'root' })
+@Injectable({providedIn: 'root'})
export class PopupService {
private readonly injector = inject(EnvironmentInjector);
private readonly appRef = inject(ApplicationRef);
diff --git a/adev-ja/src/content/guide/components/queries.en.md b/adev-ja/src/content/guide/components/queries.en.md
index de451090de..512067b0fa 100644
--- a/adev-ja/src/content/guide/components/queries.en.md
+++ b/adev-ja/src/content/guide/components/queries.en.md
@@ -7,7 +7,7 @@ A component can define **queries** that find child elements and read values from
Developers most commonly use queries to retrieve references to child components, directives, DOM elements, and more.
All query functions return signals that reflect the most up-to-date results. You can read the
-result by calling the signal function, including in reactive contexts like `computed` and `effect`.
+result by calling the signal function, including in [reactive contexts](guide/signals#reactive-contexts) like `computed` and `effect`.
There are two categories of query: **view queries** and **content queries.**
@@ -149,7 +149,9 @@ If a child query (`viewChild` or `contentChild`) does not find a result, its val
In some cases, especially with `viewChild`, you know with certainty that a specific child is always available. In other cases, you may want to strictly enforce that a specific child is present. For these cases, you can use a _required query_.
```ts
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
export class CustomCard {
header = viewChild.required(CustomCardHeader);
body = contentChild.required(CustomCardBody);
@@ -216,8 +218,9 @@ All query functions accept an options object as a second parameter. These option
By default, the query locator indicates both the element you're searching for and the value retrieved. You can alternatively specify the `read` option to retrieve a different value from the element matched by the locator.
```ts
-
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomExpando {
toggle = contentChild(ExpandoContent, {read: TemplateRef});
}
@@ -267,7 +270,7 @@ original decorator-based query APIs remain fully supported.
You can alternatively declare queries by adding the corresponding decorator to a property. Decorator-based queries behave the same way as signal-based queries except as described below.
-### View queries
+### View queries {#decorator-view-queries}
You can query for a single result with the `@ViewChild` decorator.
@@ -330,11 +333,11 @@ export class CustomCard {
`@ViewChildren` creates a `QueryList` object that contains the query results. You can subscribe to changes to the query results over time via the `changes` property.
-### Content queries
+### Content queries {#decorator-content-queries}
You can query for a single result with the `@ContentChild` decorator.
-```angular-ts {highlight: [14, 16, 17, 18, 25]}
+```angular-ts {highlight: [15, 16, 17, 18, 19, 26]}
@Component({
selector: 'custom-toggle',
/*...*/
diff --git a/adev-ja/src/content/guide/components/queries.md b/adev-ja/src/content/guide/components/queries.md
index 283d7d2a88..4be5c09f5b 100644
--- a/adev-ja/src/content/guide/components/queries.md
+++ b/adev-ja/src/content/guide/components/queries.md
@@ -7,7 +7,7 @@ TIP: このガイドでは、[基本概念のガイド](essentials)を読んで
開発者は、クエリを使用して、子コンポーネント、ディレクティブ、DOM要素などの参照を取得することがほとんどです。
すべてのクエリ関数は、最新の結果を反映するシグナルを返します。
-`computed`や`effect`などのリアクティブなコンテキストでも、シグナル関数を呼び出すことで結果を読み取れます。
+`computed`や`effect`などの[リアクティブなコンテキスト](guide/signals#reactive-contexts)でも、シグナル関数を呼び出すことで結果を読み取れます。
クエリには、**ビュークエリ**と**コンテンツクエリ**の2つのカテゴリーがあります。
@@ -149,7 +149,9 @@ export class UserProfile { }
場合によっては、特に`viewChild`を使用する場合、特定の子が常に利用可能であることが確実な場合があります。他の場合では、特定の子が存在することを厳格に適用したい場合があります。これらの場合、_必須クエリ_を使用できます。
```ts
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
export class CustomCard {
header = viewChild.required(CustomCardHeader);
body = contentChild.required(CustomCardBody);
@@ -216,8 +218,9 @@ export class CustomList {
デフォルトでは、クエリロケーターは、検索対象の要素と取得される値の両方を示します。代わりに、`read`オプションを指定して、ロケーターによって一致した要素から別の値を取得できます。
```ts
-
-@Component({/*...*/})
+@Component({
+ /*...*/
+})
export class CustomExpando {
toggle = contentChild(ExpandoContent, {read: TemplateRef});
}
@@ -267,7 +270,7 @@ TIP: Angularチームは新規プロジェクトにはシグナルベースの
代わりに、対応するデコレーターをプロパティに追加することでもクエリを宣言できます。デコレーターベースのクエリは、下記で説明する点を除いて、シグナルベースのクエリと同じように動作します。
-### ビュークエリ
+### ビュークエリ {#decorator-view-queries}
`@ViewChild`デコレーターを使用して、単一の結果をクエリできます。
@@ -330,11 +333,11 @@ export class CustomCard {
`@ViewChildren`は、クエリ結果を含む`QueryList`オブジェクトを作成します。`changes`プロパティを使用して、時間の経過とともにクエリ結果の変更を購読できます。
-### コンテンツクエリ
+### コンテンツクエリ {#decorator-content-queries}
`@ContentChild`デコレーターを使用して、単一の結果をクエリできます。
-```angular-ts {highlight: [14, 16, 17, 18, 25]}
+```angular-ts {highlight: [15, 16, 17, 18, 19, 26]}
@Component({
selector: 'custom-toggle',
/* ... */
diff --git a/adev-ja/src/content/guide/di/creating-and-using-services.en.md b/adev-ja/src/content/guide/di/creating-and-using-services.en.md
index f8df5139a9..d7b1486f6a 100644
--- a/adev-ja/src/content/guide/di/creating-and-using-services.en.md
+++ b/adev-ja/src/content/guide/di/creating-and-using-services.en.md
@@ -18,18 +18,18 @@ Here is an example of a service that allows users to add and request data:
```ts
// 📄 src/app/basic-data-store.ts
-import { Injectable } from '@angular/core';
+import {Injectable} from '@angular/core';
-@Injectable({ providedIn: 'root' })
+@Injectable({providedIn: 'root'})
export class BasicDataStore {
- private data: string[] = []
+ private data: string[] = [];
addData(item: string): void {
- this.data.push(item)
+ this.data.push(item);
}
getData(): string[] {
- return [...this.data]
+ return [...this.data];
}
}
```
@@ -73,8 +73,8 @@ export class ExampleComponent {
### Injecting into another service
```ts
-import { inject, Injectable } from '@angular/core';
-import { AdvancedDataStore } from './advanced-data-store';
+import {inject, Injectable} from '@angular/core';
+import {AdvancedDataStore} from './advanced-data-store';
@Injectable({
providedIn: 'root',
diff --git a/adev-ja/src/content/guide/di/creating-and-using-services.md b/adev-ja/src/content/guide/di/creating-and-using-services.md
index 2d80bd4949..02236a8ff4 100644
--- a/adev-ja/src/content/guide/di/creating-and-using-services.md
+++ b/adev-ja/src/content/guide/di/creating-and-using-services.md
@@ -18,18 +18,18 @@ TypeScriptクラスに`@Injectable()`デコレーターを追加して、手動
```ts
// 📄 src/app/basic-data-store.ts
-import { Injectable } from '@angular/core';
+import {Injectable} from '@angular/core';
-@Injectable({ providedIn: 'root' })
+@Injectable({providedIn: 'root'})
export class BasicDataStore {
- private data: string[] = []
+ private data: string[] = [];
addData(item: string): void {
- this.data.push(item)
+ this.data.push(item);
}
getData(): string[] {
- return [...this.data]
+ return [...this.data];
}
}
```
@@ -73,8 +73,8 @@ export class ExampleComponent {
### 別のサービスへの注入 {#injecting-into-another-service}
```ts
-import { inject, Injectable } from '@angular/core';
-import { AdvancedDataStore } from './advanced-data-store';
+import {inject, Injectable} from '@angular/core';
+import {AdvancedDataStore} from './advanced-data-store';
@Injectable({
providedIn: 'root',
diff --git a/adev-ja/src/content/guide/di/creating-injectable-service.md b/adev-ja/src/content/guide/di/creating-injectable-service.md
index 0d1784ea2f..1dad19288e 100644
--- a/adev-ja/src/content/guide/di/creating-injectable-service.md
+++ b/adev-ja/src/content/guide/di/creating-injectable-service.md
@@ -23,9 +23,15 @@ Here's an example of a service class that logs to the browser console:
```ts {header: "logger.service.ts (class)"}
export class Logger {
- log(msg: unknown) { console.log(msg); }
- error(msg: unknown) { console.error(msg); }
- warn(msg: unknown) { console.warn(msg); }
+ log(msg: unknown) {
+ console.log(msg);
+ }
+ error(msg: unknown) {
+ console.error(msg);
+ }
+ warn(msg: unknown) {
+ console.warn(msg);
+ }
}
```
@@ -33,25 +39,24 @@ Services can depend on other services.
For example, here's a `HeroService` that depends on the `Logger` service, and also uses `BackendService` to get heroes.
That service in turn might depend on the `HttpClient` service to fetch heroes asynchronously from a server:
-
-import { inject } from "@angular/core";
+```ts {header: "hero.service.ts", highlight="[7,8,12,13]"}
+import {inject} from '@angular/core';
export class HeroService {
-private heroes: Hero[] = [];
+ private heroes: Hero[] = [];
-private backend = inject(BackendService);
-private logger = inject(Logger);
+ private backend = inject(BackendService);
+ private logger = inject(Logger);
-async getHeroes() {
-// Fetch
-this.heroes = await this.backend.getAll(Hero);
-// Log
-this.logger.log(`Fetched ${this.heroes.length} heroes.`);
-return this.heroes;
-}
+ async getHeroes() {
+ // Fetch
+ this.heroes = await this.backend.getAll(Hero);
+ // Log
+ this.logger.log(`Fetched ${this.heroes.length} heroes.`);
+ return this.heroes;
+ }
}
-
+```
## Creating an injectable service with the CLI
@@ -61,9 +66,9 @@ To generate a new `HeroService` class in the `src/app/heroes` folder, follow the
1. Run this [Angular CLI](/tools/cli) command:
-
+```sh
ng generate service heroes/hero
-
+```
This command creates the following default `HeroService`:
diff --git a/adev-ja/src/content/guide/di/defining-dependency-providers.md b/adev-ja/src/content/guide/di/defining-dependency-providers.md
index 3702715d59..f685b05ef3 100644
--- a/adev-ja/src/content/guide/di/defining-dependency-providers.md
+++ b/adev-ja/src/content/guide/di/defining-dependency-providers.md
@@ -16,7 +16,7 @@ While the `@Injectable` decorator with `providedIn: 'root'` works great for serv
An `InjectionToken` is an object that Angular's dependency injection system uses to uniquely identify values for injection. Think of it as a special key that lets you store and retrieve any type of value in Angular's DI system:
```ts
-import { InjectionToken } from '@angular/core';
+import {InjectionToken} from '@angular/core';
// Create a token for a string value
export const API_URL = new InjectionToken('api.url');
@@ -40,7 +40,7 @@ An `InjectionToken` that has a `factory` results in `providedIn: 'root'` by defa
```ts
// 📁 /app/config.token.ts
-import { InjectionToken } from '@angular/core';
+import {InjectionToken} from '@angular/core';
export interface AppConfig {
apiUrl: string;
@@ -56,15 +56,15 @@ export const APP_CONFIG = new InjectionToken('app.config', {
version: '1.0.0',
features: {
darkMode: true,
- analytics: false
- }
- })
+ analytics: false,
+ },
+ }),
});
// No need to add to providers array - available everywhere!
@Component({
selector: 'app-header',
- template: `('logger.function', {
console[level](`[${new Date().toISOString()}] ${message}`);
}
};
- }
+ },
});
// 📁 /app/storage.token.ts
// Providing browser APIs as tokens
export const LOCAL_STORAGE = new InjectionToken('localStorage', {
// providedIn: 'root' is configured as the default
- factory: () => window.localStorage
+ factory: () => window.localStorage,
});
export const SESSION_STORAGE = new InjectionToken('sessionStorage', {
providedIn: 'root',
- factory: () => window.sessionStorage
+ factory: () => window.sessionStorage,
});
// 📁 /app/feature-flags.token.ts
@@ -125,7 +125,7 @@ export const FEATURE_FLAGS = new InjectionToken>('feature.f
flags.set('newDashboard', false);
return flags;
- }
+ },
});
```
@@ -148,7 +148,7 @@ When you need more control than `providedIn: 'root'` offers, you can manually co
### Example: Service without `providedIn`
```ts
-import { Injectable, Component, inject } from '@angular/core';
+import {Injectable, Component, inject} from '@angular/core';
// Service without providedIn
@Injectable()
@@ -165,7 +165,7 @@ export class LocalDataStore {
selector: 'app-example',
// A provider is required here because the `LocalDataStore` service has no providedIn.
providers: [LocalDataStore],
- template: `...`
+ template: `...`,
})
export class ExampleComponent {
dataStore = inject(LocalDataStore);
@@ -177,9 +177,9 @@ export class ExampleComponent {
Services with `providedIn: 'root'` can be overridden at the component level. This ties the instance of the service to the life of a component. As a result, when the component gets destroyed, the provided service is also destroyed as well.
```ts
-import { Injectable, Component, inject } from '@angular/core';
+import {Injectable, Component, inject} from '@angular/core';
-@Injectable({ providedIn: 'root' })
+@Injectable({providedIn: 'root'})
export class DataStore {
private data: ListItem[] = [];
}
@@ -189,7 +189,7 @@ export class DataStore {
selector: 'app-isolated',
// Creates new instance of `DataStore` rather than using the root-provided instance.
providers: [DataStore],
- template: `...`
+ template: `...`,
})
export class IsolatedComponent {
dataStore = inject(DataStore); // Component-specific instance
@@ -302,8 +302,8 @@ Angular provides a built-in [`InjectionToken`](api/core/InjectionToken) class th
```ts
// 📁 /app/tokens.ts
-import { InjectionToken } from '@angular/core';
-import { DataService } from './data-service.interface';
+import {InjectionToken} from '@angular/core';
+import {DataService} from './data-service.interface';
export const DATA_SERVICE_TOKEN = new InjectionToken('DataService');
```
@@ -341,8 +341,8 @@ interface DataService {
// Interfaces disappear after TypeScript compilation
@Component({
providers: [
- { provide: DataService, useClass: LocalDataService } // Error!
- ]
+ {provide: DataService, useClass: LocalDataService}, // Error!
+ ],
})
export class ExampleComponent {
private dataService = inject(DataService); // Error!
@@ -352,9 +352,7 @@ export class ExampleComponent {
export const DATA_SERVICE_TOKEN = new InjectionToken('DataService');
@Component({
- providers: [
- { provide: DATA_SERVICE_TOKEN, useClass: LocalDataService }
- ]
+ providers: [{provide: DATA_SERVICE_TOKEN, useClass: LocalDataService}],
})
export class ExampleComponent {
private dataService = inject(DATA_SERVICE_TOKEN); // Works!
@@ -371,25 +369,21 @@ The InjectionToken provides a runtime value that Angular's DI system can use, wh
```ts
// Shorthand
-providers: [DataService]
+providers: [DataService];
// Full syntax
-providers: [
- { provide: DataService, useClass: DataService }
-]
+providers: [{provide: DataService, useClass: DataService}];
// Different implementation
-providers: [
- { provide: DataService, useClass: MockDataService }
-]
+providers: [{provide: DataService, useClass: MockDataService}];
// Conditional implementation
providers: [
{
provide: StorageService,
- useClass: environment.production ? CloudStorageService : LocalStorageService
- }
-]
+ useClass: environment.production ? CloudStorageService : LocalStorageService,
+ },
+];
```
#### Practical example: Logger substitution
@@ -397,7 +391,7 @@ providers: [
You can substitute implementations to extend functionality:
```ts
-import { Injectable, Component, inject } from '@angular/core';
+import {Injectable, Component, inject} from '@angular/core';
// Base logger
@Injectable()
@@ -431,8 +425,8 @@ export class EvenBetterLogger extends Logger {
selector: 'app-example',
providers: [
UserService, // EvenBetterLogger needs this
- { provide: Logger, useClass: EvenBetterLogger }
- ]
+ {provide: Logger, useClass: EvenBetterLogger},
+ ],
})
export class ExampleComponent {
private logger = inject(Logger); // Gets EvenBetterLogger instance
@@ -445,10 +439,10 @@ export class ExampleComponent {
```ts
providers: [
- { provide: API_URL_TOKEN, useValue: 'https://api.example.com' },
- { provide: MAX_RETRIES_TOKEN, useValue: 3 },
- { provide: FEATURE_FLAGS_TOKEN, useValue: { darkMode: true, beta: false } }
-]
+ {provide: API_URL_TOKEN, useValue: 'https://api.example.com'},
+ {provide: MAX_RETRIES_TOKEN, useValue: 3},
+ {provide: FEATURE_FLAGS_TOKEN, useValue: {darkMode: true, beta: false}},
+];
```
IMPORTANT: TypeScript types and interfaces cannot serve as dependency values. They exist only at compile-time.
@@ -477,21 +471,19 @@ const appConfig: AppConfig = {
appTitle: 'My Application',
features: {
darkMode: true,
- analytics: false
- }
+ analytics: false,
+ },
};
// Provide in bootstrap
bootstrapApplication(AppComponent, {
- providers: [
- { provide: APP_CONFIG, useValue: appConfig }
- ]
+ providers: [{provide: APP_CONFIG, useValue: appConfig}],
});
// Use in component
@Component({
selector: 'app-header',
- template: `('interceptors');
providers: [
- { provide: INTERCEPTOR_TOKEN, useClass: AuthInterceptor, multi: true },
- { provide: INTERCEPTOR_TOKEN, useClass: LoggingInterceptor, multi: true },
- { provide: INTERCEPTOR_TOKEN, useClass: RetryInterceptor, multi: true }
-]
+ {provide: INTERCEPTOR_TOKEN, useClass: AuthInterceptor, multi: true},
+ {provide: INTERCEPTOR_TOKEN, useClass: LoggingInterceptor, multi: true},
+ {provide: INTERCEPTOR_TOKEN, useClass: RetryInterceptor, multi: true},
+];
```
When you inject `INTERCEPTOR_TOKEN`, you'll receive an array containing instances of all three interceptors.
@@ -638,11 +630,11 @@ Use application-level providers in `bootstrapApplication` when:
// main.ts
bootstrapApplication(AppComponent, {
providers: [
- { provide: API_BASE_URL, useValue: 'https://api.example.com' },
- { provide: INTERCEPTOR_TOKEN, useClass: AuthInterceptor, multi: true },
- LoggingService, // Used throughout the app
- { provide: ErrorHandler, useClass: GlobalErrorHandler }
- ]
+ {provide: API_BASE_URL, useValue: 'https://api.example.com'},
+ {provide: INTERCEPTOR_TOKEN, useClass: AuthInterceptor, multi: true},
+ LoggingService, // Used throughout the app
+ {provide: ErrorHandler, useClass: GlobalErrorHandler},
+ ],
});
```
@@ -725,19 +717,19 @@ export const routes: Routes = [
{
path: 'admin',
providers: [
- AdminService, // Only loaded with admin routes
- { provide: FEATURE_FLAGS, useValue: { adminMode: true } }
+ AdminService, // Only loaded with admin routes
+ {provide: FEATURE_FLAGS, useValue: {adminMode: true}},
],
- loadChildren: () => import('./admin/admin.routes')
+ loadChildren: () => import('./admin/admin.routes'),
},
{
path: 'shop',
providers: [
- ShoppingCartService, // Isolated shopping state
- PaymentService
+ ShoppingCartService, // Isolated shopping state
+ PaymentService,
],
- loadChildren: () => import('./shop/shop.routes')
- }
+ loadChildren: () => import('./shop/shop.routes'),
+ },
];
```
@@ -751,7 +743,7 @@ Instead of requiring users to manually configure complex providers, library auth
```ts
// 📁 /libs/analytics/src/providers.ts
-import { InjectionToken, Provider, inject } from '@angular/core';
+import {InjectionToken, Provider, inject} from '@angular/core';
// Configuration interface
export interface AnalyticsConfig {
@@ -774,10 +766,7 @@ export class AnalyticsService {
// Provider function for consumers
export function provideAnalytics(config: AnalyticsConfig): Provider[] {
- return [
- { provide: ANALYTICS_CONFIG, useValue: config },
- AnalyticsService
- ];
+ return [{provide: ANALYTICS_CONFIG, useValue: config}, AnalyticsService];
}
// Usage in consumer app
@@ -786,9 +775,9 @@ bootstrapApplication(AppComponent, {
providers: [
provideAnalytics({
trackingId: 'GA-12345',
- enableDebugMode: !environment.production
- })
- ]
+ enableDebugMode: !environment.production,
+ }),
+ ],
});
```
@@ -798,13 +787,13 @@ For more complex scenarios, you can combine multiple configuration approaches:
```ts
// 📁 /libs/http-client/src/provider.ts
-import { Provider, InjectionToken, inject } from '@angular/core';
+import {Provider, InjectionToken, inject} from '@angular/core';
// Feature flags for optional functionality
export enum HttpFeatures {
Interceptors = 'interceptors',
Caching = 'caching',
- Retry = 'retry'
+ Retry = 'retry',
}
// Configuration interfaces
@@ -826,7 +815,7 @@ const HTTP_FEATURES = new InjectionToken>('http.features');
// Core service
class HttpClientService {
- private config = inject(HTTP_CONFIG, { optional: true });
+ private config = inject(HTTP_CONFIG, {optional: true});
private features = inject(HTTP_FEATURES);
get(url: string) {
@@ -845,18 +834,15 @@ class CacheInterceptor {
}
// Main provider function
-export function provideHttpClient(
- config?: HttpConfig,
- ...features: HttpFeature[]
-): Provider[] {
+export function provideHttpClient(config?: HttpConfig, ...features: HttpFeature[]): Provider[] {
const providers: Provider[] = [
- { provide: HTTP_CONFIG, useValue: config || {} },
- { provide: HTTP_FEATURES, useValue: new Set(features.map(f => f.kind)) },
- HttpClientService
+ {provide: HTTP_CONFIG, useValue: config || {}},
+ {provide: HTTP_FEATURES, useValue: new Set(features.map((f) => f.kind))},
+ HttpClientService,
];
// Add feature-specific providers
- features.forEach(feature => {
+ features.forEach((feature) => {
providers.push(...feature.providers);
});
@@ -872,28 +858,25 @@ export interface HttpFeature {
export function withInterceptors(...interceptors: any[]): HttpFeature {
return {
kind: HttpFeatures.Interceptors,
- providers: interceptors.map(interceptor => ({
+ providers: interceptors.map((interceptor) => ({
provide: INTERCEPTOR_TOKEN,
useClass: interceptor,
- multi: true
- }))
+ multi: true,
+ })),
};
}
export function withCaching(): HttpFeature {
return {
kind: HttpFeatures.Caching,
- providers: [CacheInterceptor]
+ providers: [CacheInterceptor],
};
}
export function withRetry(config: RetryConfig): HttpFeature {
return {
kind: HttpFeatures.Retry,
- providers: [
- { provide: RETRY_CONFIG, useValue: config },
- RetryInterceptor
- ]
+ providers: [{provide: RETRY_CONFIG, useValue: config}, RetryInterceptor],
};
}
@@ -901,12 +884,12 @@ export function withRetry(config: RetryConfig): HttpFeature {
bootstrapApplication(AppComponent, {
providers: [
provideHttpClient(
- { baseUrl: 'https://api.example.com' },
+ {baseUrl: 'https://api.example.com'},
withInterceptors(AuthInterceptor, LoggingInterceptor),
withCaching(),
- withRetry({ maxAttempts: 3, delayMs: 1000 })
- )
- ]
+ withRetry({maxAttempts: 3, delayMs: 1000}),
+ ),
+ ],
});
```
diff --git a/adev-ja/src/content/guide/di/dependency-injection-context.en.md b/adev-ja/src/content/guide/di/dependency-injection-context.en.md
index b04d6a7e7f..e0b6f7aec9 100644
--- a/adev-ja/src/content/guide/di/dependency-injection-context.en.md
+++ b/adev-ja/src/content/guide/di/dependency-injection-context.en.md
@@ -23,10 +23,12 @@ Some APIs are designed to be run in an injection context. This is the case, for
Here is an example for `CanActivateFn`
```ts {highlight: [3]}
-const canActivateTeam: CanActivateFn =
- (route: ActivatedRouteSnapshot, state: RouterStateSnapshot) => {
- return inject(PermissionsService).canActivate(inject(UserToken), route.params.id);
- };
+const canActivateTeam: CanActivateFn = (
+ route: ActivatedRouteSnapshot,
+ state: RouterStateSnapshot,
+) => {
+ return inject(PermissionsService).canActivate(inject(UserToken), route.params.id);
+};
```
## Run within an injection context
@@ -36,7 +38,7 @@ This requires access to a given injector, like the `EnvironmentInjector`, for ex
```ts {highlight: [9], header"hero.service.ts"}
@Injectable({
- providedIn: 'root'
+ providedIn: 'root',
})
export class HeroService {
private environmentInjector = inject(EnvironmentInjector);
@@ -56,21 +58,23 @@ Note that [`inject`](/api/core/inject) will return an instance only if the injec
Angular provides the `assertInInjectionContext` helper function to assert that the current context is an injection context and throws a clear error if not. Pass a reference to the calling function so the error message points to the correct API entry point. This produces a clearer, more actionable message than the default generic injection error.
```ts
-import { ElementRef, assertInInjectionContext, inject } from '@angular/core';
+import {ElementRef, assertInInjectionContext, inject} from '@angular/core';
export function injectNativeElement(): T {
- assertInInjectionContext(injectNativeElement);
- return inject(ElementRef).nativeElement;
+ assertInInjectionContext(injectNativeElement);
+ return inject(ElementRef).nativeElement;
}
```
You can then call this helper **from an injection context** (constructor, field initializer, provider factory, or code executed via `runInInjectionContext`):
```ts
-import { Component, inject } from '@angular/core';
-import { injectNativeElement } from './dom-helpers';
+import {Component, inject} from '@angular/core';
+import {injectNativeElement} from './dom-helpers';
-@Component({ /* … */ })
+@Component({
+ /* … */
+})
export class PreviewCard {
readonly hostEl = injectNativeElement(); // Field initializer runs in an injection context.
diff --git a/adev-ja/src/content/guide/di/dependency-injection-context.md b/adev-ja/src/content/guide/di/dependency-injection-context.md
index 4044fe77ce..d986c13139 100644
--- a/adev-ja/src/content/guide/di/dependency-injection-context.md
+++ b/adev-ja/src/content/guide/di/dependency-injection-context.md
@@ -23,10 +23,12 @@ NOTE: クラスコンストラクターとフィールドイニシャライザ
`CanActivateFn` の例を次に示します。
```ts {highlight: [3]}
-const canActivateTeam: CanActivateFn =
- (route: ActivatedRouteSnapshot, state: RouterStateSnapshot) => {
- return inject(PermissionsService).canActivate(inject(UserToken), route.params.id);
- };
+const canActivateTeam: CanActivateFn = (
+ route: ActivatedRouteSnapshot,
+ state: RouterStateSnapshot,
+) => {
+ return inject(PermissionsService).canActivate(inject(UserToken), route.params.id);
+};
```
## 注入コンテキスト内で実行する
@@ -36,7 +38,7 @@ const canActivateTeam: CanActivateFn =
```ts {highlight: [9], header"hero.service.ts"}
@Injectable({
- providedIn: 'root'
+ providedIn: 'root',
})
export class HeroService {
private environmentInjector = inject(EnvironmentInjector);
@@ -56,21 +58,23 @@ export class HeroService {
Angularは、現在のコンテキストが注入コンテキストであることをアサートし、そうでない場合は明確なエラーをスローするための `assertInInjectionContext` ヘルパー関数を提供します。呼び出し元の関数への参照を渡すと、エラーメッセージが正しいAPIエントリーポイントを指し示すようになります。これにより、デフォルトの汎用的な注入エラーよりも明確で実用的なメッセージが生成されます。
```ts
-import { ElementRef, assertInInjectionContext, inject } from '@angular/core';
+import {ElementRef, assertInInjectionContext, inject} from '@angular/core';
export function injectNativeElement(): T {
- assertInInjectionContext(injectNativeElement);
- return inject(ElementRef).nativeElement;
+ assertInInjectionContext(injectNativeElement);
+ return inject(ElementRef).nativeElement;
}
```
このヘルパーは、**注入コンテキスト内から**（コンストラクター、フィールドイニシャライザー、プロバイダーファクトリー、または `runInInjectionContext` 経由で実行されるコード）呼び出すことができます。
```ts
-import { Component, inject } from '@angular/core';
-import { injectNativeElement } from './dom-helpers';
+import {Component, inject} from '@angular/core';
+import {injectNativeElement} from './dom-helpers';
-@Component({ /* … */ })
+@Component({
+ /* … */
+})
export class PreviewCard {
readonly hostEl = injectNativeElement(); // フィールドイニシャライザーは注入コンテキスト内で実行されます。
diff --git a/adev-ja/src/content/guide/di/di-in-action.en.md b/adev-ja/src/content/guide/di/di-in-action.en.md
index 423d7fff38..5d866b3cfb 100644
--- a/adev-ja/src/content/guide/di/di-in-action.en.md
+++ b/adev-ja/src/content/guide/di/di-in-action.en.md
@@ -24,7 +24,6 @@ export class HighlightDirective {
this.element.nativeElement.style.color = 'red';
}
}
-
```
## Inject the host element's tag name
diff --git a/adev-ja/src/content/guide/di/di-in-action.md b/adev-ja/src/content/guide/di/di-in-action.md
index 149e4a78ba..f1b419e12e 100644
--- a/adev-ja/src/content/guide/di/di-in-action.md
+++ b/adev-ja/src/content/guide/di/di-in-action.md
@@ -24,7 +24,6 @@ export class HighlightDirective {
this.element.nativeElement.style.color = 'red';
}
}
-
```
## ホスト要素のタグ名を注入する {#inject-the-host-elements-tag-name}
diff --git a/adev-ja/src/content/guide/di/hierarchical-dependency-injection.en.md b/adev-ja/src/content/guide/di/hierarchical-dependency-injection.en.md
index 1b54c0a127..f9a09ce173 100644
--- a/adev-ja/src/content/guide/di/hierarchical-dependency-injection.en.md
+++ b/adev-ja/src/content/guide/di/hierarchical-dependency-injection.en.md
@@ -37,10 +37,10 @@ Tree-shaking is especially useful for a library because the application which us
Provide services using `providedIn` of `@Injectable()` as follows:
```ts {highlight:[4]}
-import { Injectable } from '@angular/core';
+import {Injectable} from '@angular/core';
@Injectable({
- providedIn: 'root' // <--provides this service in the root EnvironmentInjector
+ providedIn: 'root', // <--provides this service in the root EnvironmentInjector
})
export class ItemService {
name = 'telephone';
@@ -109,9 +109,7 @@ You can do this to configure a non-default provider of a service that is shared
Here is an example of the case where the component router configuration includes a non-default [location strategy](guide/routing#location-strategy) by listing its provider in the `providers` list of the `ApplicationConfig`.
```ts
-providers: [
- { provide: LocationStrategy, useClass: HashLocationStrategy }
-]
+providers: [{provide: LocationStrategy, useClass: HashLocationStrategy}];
```
For `NgModule` based applications, configure app-wide providers in the `AppModule` `providers`.
@@ -214,7 +212,7 @@ For example, in the following `SelfNoDataComponent`, notice the injected `LeafSe
@Component({
selector: 'app-self-no-data',
templateUrl: './self-no-data.component.html',
- styleUrls: ['./self-no-data.component.css']
+ styleUrls: ['./self-no-data.component.css'],
})
export class SelfNoDataComponent {
public leaf = inject(LeafService, {optional: true, self: true});
@@ -261,7 +259,7 @@ This is when you'd use `skipSelf`:
templateUrl: './skipself.component.html',
styleUrls: ['./skipself.component.css'],
// Angular would ignore this LeafService instance
- providers: [{ provide: LeafService, useValue: { emoji: '🍁' } }]
+ providers: [{provide: LeafService, useValue: {emoji: '🍁'}}],
})
export class SkipselfComponent {
// Use skipSelf as inject option
@@ -280,7 +278,7 @@ In the following example, the `Person` service is injected during property initi
```ts
class Person {
- parent = inject(Person, {optional: true, skipSelf: true})
+ parent = inject(Person, {optional: true, skipSelf: true});
}
```
@@ -317,7 +315,7 @@ Import each of them from `@angular/core` and use each in the component class con
```ts {header:"self-no-data.component.ts" highlight:[2]}
export class SelfNoDataComponent {
- constructor(@Self() @Optional() public leaf?: LeafService) { }
+ constructor(@Self() @Optional() public leaf?: LeafService) {}
}
```
@@ -330,9 +328,7 @@ Understanding the underlying logical structure of the Angular template will give
Components are used in your templates, as in the following example:
```html
-
-
+
```
HELPFUL: Usually, you declare the components and their templates in separate files.
@@ -387,7 +383,7 @@ The example application has a `FlowerService` provided in `root` with an `emoji`
```ts {header:"lower.service.ts"}
@Injectable({
- providedIn: 'root'
+ providedIn: 'root',
})
export class FlowerService {
emoji = '🌺';
@@ -398,9 +394,9 @@ Consider an application with only an `AppComponent` and a `ChildComponent`.
The most basic rendered view would look like nested HTML elements such as the following:
```html
-
-
-
+
+
+
```
@@ -425,7 +421,7 @@ Knowledge of this structure can inform how you provide and inject your services,
Now, consider that `` injects the `FlowerService`:
```typescript
-export class AppComponent {
+export class AppComponent {
flower = inject(FlowerService);
}
```
@@ -599,7 +595,8 @@ In the `ChildComponent` template, add the following binding:
Additionally, add the same to the `AppComponent` template:
```html
-` as shown in `child.component.ts`:
```typescript
- flower = inject(FlowerService, { skipSelf: true })
+flower = inject(FlowerService, {skipSelf: true});
```
With `skipSelf`, the `` injector doesn't look to itself for the `FlowerService`.
@@ -900,7 +897,7 @@ Here are `host` and `skipSelf` in the `animal` property initialization:
```typescript
export class ChildComponent {
- animal = inject(AnimalService, { host: true, skipSelf: true });
+ animal = inject(AnimalService, {host: true, skipSelf: true});
}
```
@@ -1085,7 +1082,7 @@ Every component would share the same service instance, and each component would
To prevent this, configure the component-level injector of `HeroTaxReturnComponent` to provide the service, using the `providers` property in the component metadata.
```typescript
- providers: [HeroTaxReturnService]
+providers: [HeroTaxReturnService];
```
The `HeroTaxReturnComponent` has its own provider of the `HeroTaxReturnService`.
diff --git a/adev-ja/src/content/guide/di/hierarchical-dependency-injection.md b/adev-ja/src/content/guide/di/hierarchical-dependency-injection.md
index 672b5ce875..78499ddaac 100644
--- a/adev-ja/src/content/guide/di/hierarchical-dependency-injection.md
+++ b/adev-ja/src/content/guide/di/hierarchical-dependency-injection.md
@@ -37,10 +37,10 @@ Angularには、次の2つのインジェクター階層があります。
`providedIn` を使用して、次のように `@Injectable()` を使用してサービスを提供します。
```ts {highlight:[4]}
-import { Injectable } from '@angular/core';
+import {Injectable} from '@angular/core';
@Injectable({
- providedIn: 'root' // <--ルート EnvironmentInjector でこのサービスを提供します
+ providedIn: 'root', // <--ルート EnvironmentInjector でこのサービスを提供します
})
export class ItemService {
name = 'telephone';
@@ -109,9 +109,7 @@ stateDiagram-v2
コンポーネントルーターの構成にデフォルト以外の [ロケーション戦略](guide/routing#location-strategy) が含まれている場合、 `ApplicationConfig` の `providers` リストにそのプロバイダーをリストすることによって、その例を示します。
```ts
-providers: [
- { provide: LocationStrategy, useClass: HashLocationStrategy }
-]
+providers: [{provide: LocationStrategy, useClass: HashLocationStrategy}];
```
`NgModule` ベースのアプリケーションの場合、アプリケーション全体のプロバイダーを `AppModule` の `providers` で構成します。
@@ -214,7 +212,7 @@ export class OptionalComponent {
@Component({
selector: 'app-self-no-data',
templateUrl: './self-no-data.component.html',
- styleUrls: ['./self-no-data.component.css']
+ styleUrls: ['./self-no-data.component.css'],
})
export class SelfNoDataComponent {
public leaf = inject(LeafService, {optional: true, self: true});
@@ -261,7 +259,7 @@ export class LeafService {
templateUrl: './skipself.component.html',
styleUrls: ['./skipself.component.css'],
// Angular はこの LeafService インスタンスを無視します
- providers: [{ provide: LeafService, useValue: { emoji: '🍁' } }]
+ providers: [{provide: LeafService, useValue: {emoji: '🍁'}}],
})
export class SkipselfComponent {
// Use skipSelf as inject option
@@ -280,7 +278,7 @@ export class SkipselfComponent {
```ts
class Person {
- parent = inject(Person, {optional: true, skipSelf: true})
+ parent = inject(Person, {optional: true, skipSelf: true});
}
```
@@ -317,7 +315,7 @@ export class HostComponent {
```ts {header:"self-no-data.component.ts" highlight:[2]}
export class SelfNoDataComponent {
- constructor(@Self() @Optional() public leaf?: LeafService) { }
+ constructor(@Self() @Optional() public leaf?: LeafService) {}
}
```
@@ -330,9 +328,7 @@ Angularテンプレートの基になる論理構造を理解すると、サー
コンポーネントは、次の例のようにテンプレートで使用されます。
```html
-
-
+
```
HELPFUL: 通常、コンポーネントとそのテンプレートは別々のファイルに宣言します。
@@ -387,7 +383,7 @@ HELPFUL: 通常、コンポーネントとそのテンプレートは別々の
```ts {header:"lower.service.ts"}
@Injectable({
- providedIn: 'root'
+ providedIn: 'root',
})
export class FlowerService {
emoji = '🌺';
@@ -398,9 +394,9 @@ export class FlowerService {
最も基本的なレンダリングされたビューは、次のようなネストされたHTML要素のように見えます。
```html
-
-
-
+
+
+
```
@@ -425,7 +421,7 @@ export class FlowerService {
次に、 `` が `FlowerService` を注入しているとします。
```typescript
-export class AppComponent {
+export class AppComponent {
flower = inject(FlowerService);
}
```
@@ -599,7 +595,8 @@ export class ChildComponent {
さらに、 `AppComponent` テンプレートにも同じものを追加します。
```html
-` のプロパティ初期化子です。
```typescript
- flower = inject(FlowerService, { skipSelf: true })
+flower = inject(FlowerService, {skipSelf: true});
```
`skipSelf` を使用すると、`` インジェクターは `FlowerService` を自分自身で探しません。
@@ -900,7 +897,7 @@ export class ChildComponent {
```typescript
export class ChildComponent {
- animal = inject(AnimalService, { host: true, skipSelf: true });
+ animal = inject(AnimalService, {host: true, skipSelf: true});
}
```
@@ -1085,7 +1082,7 @@ _編集対象の税務申告_ は、 `input` プロパティを介して到着
これを防ぐために、コンポーネントレベルのインジェクター `HeroTaxReturnComponent` を構成して、コンポーネントメタデータの `providers` プロパティを使用してサービスを提供します。
```typescript
- providers: [HeroTaxReturnService]
+providers: [HeroTaxReturnService];
```
`HeroTaxReturnComponent` には、 `HeroTaxReturnService` の独自の提供者がいます。
diff --git a/adev-ja/src/content/guide/di/lightweight-injection-tokens.en.md b/adev-ja/src/content/guide/di/lightweight-injection-tokens.en.md
index f526fb0a38..a4f13143db 100644
--- a/adev-ja/src/content/guide/di/lightweight-injection-tokens.en.md
+++ b/adev-ja/src/content/guide/di/lightweight-injection-tokens.en.md
@@ -29,45 +29,45 @@ This component contains a body and can contain an optional header:
;
```
-In a likely implementation, the `` component uses `@ContentChild()` or `@ContentChildren()` to get `` and ``, as in the following:
+In a likely implementation, the `` component uses `contentChild` or `contentChildren` to get `` and ``, as in the following:
```ts {highlight: [14]}
-import {Component, ContentChild} from '@angular/core';
+import {Component, contentChild} from '@angular/core';
@Component({
selector: 'lib-header',
…,
})
-class LibHeaderComponent {}
+class LibHeader {}
@Component({
selector: 'lib-card',
…,
})
-class LibCardComponent {
- @ContentChild(LibHeaderComponent) header: LibHeaderComponent | null = null;
+class LibCard {
+ readonly header = contentChild(LibHeader);
}
```
Because `` is optional, the element can appear in the template in its minimal form, `` is not used and you would expect it to be tree-shaken, but that is not what happens.
-This is because `LibCardComponent` actually contains two references to the `LibHeaderComponent`:
+This is because `LibCard` actually contains two references to the `LibHeader`:
```ts
-@ContentChild(LibHeaderComponent) header: LibHeaderComponent;
+readonly header = contentChild(LibHeader);
```
-- One of these reference is in the _type position_-- that is, it specifies `LibHeaderComponent` as a type: `header: LibHeaderComponent;`.
-- The other reference is in the _value position_-- that is, LibHeaderComponent is the value of the `@ContentChild()` parameter decorator: `@ContentChild(LibHeaderComponent)`.
+- One of these reference is in the _type position_-- that is, it specifies `LibHeader` as a type: `readonly header: Signal`.
+- The other reference is in the _value position_-- that is, `LibHeader` is the value passed into the `contentChild` function: `contentChild(LibHeader)`.
The compiler handles token references in these positions differently:
- The compiler erases _type position_ references after conversion from TypeScript, so they have no impact on tree-shaking.
- The compiler must keep _value position_ references at runtime, which **prevents** the component from being tree-shaken.
-In the example, the compiler retains the `LibHeaderComponent` token that occurs in the value position.
+In the example, the compiler retains the `LibHeader` token that occurs in the value position.
This prevents the referenced component from being tree-shaken, even if the application does not actually use `` anywhere.
-If `LibHeaderComponent` 's code, template, and styles combine to become too large, including it unnecessarily can significantly increase the size of the client application.
+If `LibHeader` 's code, template, and styles combine to become too large, including it unnecessarily can significantly increase the size of the client application.
## When to use the lightweight injection token pattern
@@ -75,20 +75,20 @@ The tree-shaking problem arises when a component is used as an injection token.
There are two cases when that can happen:
- The token is used in the value position of a [content query](guide/components/queries#content-queries).
-- The token is used as a type specifier for constructor injection.
+- The token is used with the `inject` function.
-In the following example, both uses of the `OtherComponent` token cause retention of `OtherComponent`, preventing it from being tree-shaken when it is not used:
+In the following example, both uses of the `CustomOther` token cause retention of `CustomOther`, preventing it from being tree-shaken when it is not used:
```ts {highlight: [[2],[4]]}
-class MyComponent {
- constructor(@Optional() other: OtherComponent) {}
+class App {
+ private readonly other = inject(CustomOther, {optional: true});
- @ContentChild(OtherComponent) other: OtherComponent | null;
+ readonly header = contentChild(CustomOther);
}
```
Although tokens used only as type specifiers are removed when converted to JavaScript, all tokens used for dependency injection are needed at runtime.
-These effectively change `constructor(@Optional() other: OtherComponent)` to `constructor(@Optional() @Inject(OtherComponent) other)`.
+When using `inject(CustomOther)`, `CustomOther` is passed as a value argument.
The token is now in a value position, which causes the tree-shaker to keep the reference.
HELPFUL: Libraries should use [tree-shakable providers](guide/di/dependency-injection#providing-dependency) for all services, providing dependencies at the root level rather than in components or modules.
@@ -98,40 +98,40 @@ HELPFUL: Libraries should use [tree-shakable providers](guide/di/dependency-inje
The lightweight injection token design pattern consists of using a small abstract class as an injection token, and providing the actual implementation at a later stage.
The abstract class is retained, not tree-shaken, but it is small and has no material impact on the application size.
-The following example shows how this works for the `LibHeaderComponent`:
+The following example shows how this works for the `LibHeader`:
```ts {highlight: [[1],[5], [15]]}
abstract class LibHeaderToken {}
@Component({
selector: 'lib-header',
- providers: [{provide: LibHeaderToken, useExisting: LibHeaderComponent}],
+ providers: [{provide: LibHeaderToken, useExisting: LibHeader}],
…,
})
-class LibHeaderComponent extends LibHeaderToken {}
+class LibHeader extends LibHeaderToken {}
@Component({
selector: 'lib-card',
…,
})
-class LibCardComponent {
- @ContentChild(LibHeaderToken) header: LibHeaderToken | null = null;
+class LibCard {
+ readonly header = contentChild(LibHeaderToken);
}
```
-In this example, the `LibCardComponent` implementation no longer refers to `LibHeaderComponent` in either the type position or the value position.
-This lets full tree-shaking of `LibHeaderComponent` take place.
+In this example, the `LibCard` implementation no longer refers to `LibHeader` in either the type position or the value position.
+This lets full tree-shaking of `LibHeader` take place.
The `LibHeaderToken` is retained, but it is only a class declaration, with no concrete implementation.
It is small and does not materially impact the application size when retained after compilation.
-Instead, `LibHeaderComponent` itself implements the abstract `LibHeaderToken` class.
+Instead, `LibHeader` itself implements the abstract `LibHeaderToken` class.
You can safely use that token as the provider in the component definition, allowing Angular to correctly inject the concrete type.
To summarize, the lightweight injection token pattern consists of the following:
1. A lightweight injection token that is represented as an abstract class.
2. A component definition that implements the abstract class.
-3. Injection of the lightweight pattern, using `@ContentChild()` or `@ContentChildren()`.
+3. Injection of the lightweight pattern, using `contentChild` or `contentChildren`.
4. A provider in the implementation of the lightweight injection token which associates the lightweight injection token with the implementation.
### Use the lightweight injection token for API definition
@@ -141,8 +141,8 @@ The token is now an abstract class. Since the injectable component implements th
The implementation of the method, with all its code overhead, resides in the injectable component that can be tree-shaken.
This lets the parent communicate with the child, if it is present, in a type-safe manner.
-For example, the `LibCardComponent` now queries `LibHeaderToken` rather than `LibHeaderComponent`.
-The following example shows how the pattern lets `LibCardComponent` communicate with the `LibHeaderComponent` without actually referring to `LibHeaderComponent`:
+For example, the `LibCard` now queries `LibHeaderToken` rather than `LibHeader`.
+The following example shows how the pattern lets `LibCard` communicate with the `LibHeader` without actually referring to `LibHeader`:
```ts {highlight: [[2],[9],[11],[19]]}
abstract class LibHeaderToken {
@@ -151,9 +151,9 @@ abstract class LibHeaderToken {
@Component({
selector: 'lib-header',
- providers: [{provide: LibHeaderToken, useExisting: LibHeaderComponent}],
+ providers: [{provide: LibHeaderToken, useExisting: LibHeader}],
})
-class LibHeaderComponent extends LibHeaderToken {
+class LibHeader extends LibHeaderToken {
doSomething(): void {
// Concrete implementation of `doSomething`
}
@@ -162,12 +162,12 @@ class LibHeaderComponent extends LibHeaderToken {
@Component({
selector: 'lib-card',
})
-class LibCardComponent implements AfterContentInit {
- @ContentChild(LibHeaderToken) header: LibHeaderToken | null = null;
+class LibCard implements AfterContentInit {
+ readonly header = contentChild(LibHeaderToken);
ngAfterContentInit(): void {
- if (this.header !== null) {
- this.header?.doSomething();
+ if (this.header() !== undefined) {
+ this.header()!.doSomething();
}
}
}
@@ -180,8 +180,8 @@ If the child component has been tree-shaken, there is no runtime reference to it
### Naming your lightweight injection token
Lightweight injection tokens are only useful with components.
-The Angular style guide suggests that you name components using the "Component" suffix.
-The example "LibHeaderComponent" follows this convention.
+The [Angular Style Guide](style-guide) suggests that you name components without the suffix `Component`.
+The example `LibHeader` follows this convention.
You should maintain the relationship between the component and its token while still distinguishing between them.
-The recommended style is to use the component base name with the suffix "`Token`" to name your lightweight injection tokens: "`LibHeaderToken`."
+The recommended style is to use the component base name with the suffix `Token` to name your lightweight injection tokens: `LibHeaderToken`.
diff --git a/adev-ja/src/content/guide/di/lightweight-injection-tokens.md b/adev-ja/src/content/guide/di/lightweight-injection-tokens.md
index 51669ad4c5..71ca7f2795 100644
--- a/adev-ja/src/content/guide/di/lightweight-injection-tokens.md
+++ b/adev-ja/src/content/guide/di/lightweight-injection-tokens.md
@@ -29,45 +29,45 @@ Angularがインジェクショントークンを格納する方法により、
;
```
-一般的な実装では、 `` コンポーネントは、次の例のように `@ContentChild()` または `@ContentChildren()` を使用して `` と `` を取得します。
+一般的な実装では、 `` コンポーネントは、次の例のように `contentChild` または `contentChildren` を使用して `` と `` を取得します。
```ts {highlight: [14]}
-import {Component, ContentChild} from '@angular/core';
+import {Component, contentChild} from '@angular/core';
@Component({
selector: 'lib-header',
…,
})
-class LibHeaderComponent {}
+class LibHeader {}
@Component({
selector: 'lib-card',
…,
})
-class LibCardComponent {
- @ContentChild(LibHeaderComponent) header: LibHeaderComponent | null = null;
+class LibCard {
+ readonly header = contentChild(LibHeader);
}
```
`` はオプションなので、要素はテンプレートに最小限の形式 `` は使用されず、ツリーシェイクされることを期待しますが、実際にはそうなりません。
-これは、 `LibCardComponent` には `LibHeaderComponent` への参照が2つあるためです。
+これは、 `LibCard` には `LibHeader` への参照が2つあるためです。
```ts
-@ContentChild(LibHeaderComponent) header: LibHeaderComponent;
+readonly header = contentChild(LibHeader);
```
-- これらの参照の1つは _型の位置_ にあります。つまり、 `LibHeaderComponent` を型として指定します: `header: LibHeaderComponent;`。
-- もう1つの参照は _値の位置_ にあります。つまり、LibHeaderComponentは `@ContentChild()` パラメータデコレーターの値です: `@ContentChild(LibHeaderComponent)`。
+- これらの参照の1つは _型の位置_ にあります。つまり、 `LibHeader` を型として指定します: `readonly header: Signal`。
+- もう1つの参照は _値の位置_ にあります。つまり、`LibHeader` は `contentChild` 関数に渡される値です: `contentChild(LibHeader)`。
コンパイラはこれらの位置にあるトークン参照を異なる方法で処理します。
- コンパイラは、TypeScriptから変換した後の _型の位置_ の参照を消去するため、ツリーシェイクには影響しません。
- コンパイラは、_値の位置_ の参照をランタイムに保持する必要があり、これが**妨げます** コンポーネントがツリーシェイクされること。
-この例では、コンパイラは値位置にある `LibHeaderComponent` トークンを保持します。
+この例では、コンパイラは値位置にある `LibHeader` トークンを保持します。
これにより、アプリケーションで実際に `` をどこでも使用していない場合でも、参照されるコンポーネントがツリーシェイクされることがなくなります。
-`LibHeaderComponent` のコード、テンプレート、スタイルを組み合わせると大きくなりすぎるため、不要に含めるとクライアントアプリケーションのサイズが大幅に増加する可能性があります。
+`LibHeader` のコード、テンプレート、スタイルを組み合わせると大きくなりすぎるため、不要に含めるとクライアントアプリケーションのサイズが大幅に増加する可能性があります。
## 軽量インジェクショントークンパターンを使用する場合
diff --git a/adev-ja/src/content/guide/di/overview.en.md b/adev-ja/src/content/guide/di/overview.en.md
index 5a37b7ecfc..cb0829d211 100644
--- a/adev-ja/src/content/guide/di/overview.en.md
+++ b/adev-ja/src/content/guide/di/overview.en.md
@@ -46,16 +46,16 @@ Common types of services include:
The following example declares a service named `AnalyticsLogger`:
```ts
-import { Injectable } from '@angular/core';
+import {Injectable} from '@angular/core';
-@Injectable({ providedIn: 'root' })
+@Injectable({providedIn: 'root'})
export class AnalyticsLogger {
trackEvent(category: string, value: string) {
console.log('Analytics event logged:', {
category,
value,
- timestamp: new Date().toISOString()
- })
+ timestamp: new Date().toISOString(),
+ });
}
}
```
@@ -119,10 +119,10 @@ export class MyDirective {
```
```ts
-import { Injectable, inject } from '@angular/core';
-import { HttpClient } from '@angular/common/http';
+import {Injectable, inject} from '@angular/core';
+import {HttpClient} from '@angular/common/http';
-@Injectable({ providedIn: 'root' })
+@Injectable({providedIn: 'root'})
export class MyService {
// ✅ In a service
private http = inject(HttpClient);
@@ -134,7 +134,7 @@ export const authGuard = () => {
// ✅ In a route guard
const auth = inject(AuthService);
return auth.isAuthenticated();
-}
+};
```
Angular uses the term "injection context" to describe any place in your code where you can call [`inject`](/api/core/inject). While component, directive, and service construction is the most common, see [injection contexts](/guide/di/dependency-injection-context) for more details.
diff --git a/adev-ja/src/content/guide/di/overview.md b/adev-ja/src/content/guide/di/overview.md
index d8d4de9bb6..e2964a7e44 100644
--- a/adev-ja/src/content/guide/di/overview.md
+++ b/adev-ja/src/content/guide/di/overview.md
@@ -46,16 +46,16 @@ Angular _サービス_ は `@Injectable` で装飾されたTypeScriptクラス
次の例は、`AnalyticsLogger` という名前のサービスを宣言しています。
```ts
-import { Injectable } from '@angular/core';
+import {Injectable} from '@angular/core';
-@Injectable({ providedIn: 'root' })
+@Injectable({providedIn: 'root'})
export class AnalyticsLogger {
trackEvent(category: string, value: string) {
console.log('Analytics event logged:', {
category,
value,
- timestamp: new Date().toISOString()
- })
+ timestamp: new Date().toISOString(),
+ });
}
}
```
@@ -119,10 +119,10 @@ export class MyDirective {
```
```ts
-import { Injectable, inject } from '@angular/core';
-import { HttpClient } from '@angular/common/http';
+import {Injectable, inject} from '@angular/core';
+import {HttpClient} from '@angular/common/http';
-@Injectable({ providedIn: 'root' })
+@Injectable({providedIn: 'root'})
export class MyService {
// ✅ サービス内
private http = inject(HttpClient);
@@ -134,7 +134,7 @@ export const authGuard = () => {
// ✅ ルートガード内
const auth = inject(AuthService);
return auth.isAuthenticated();
-}
+};
```
Angularは「注入コンテキスト」という用語を使用して、コード内で [`inject`](/api/core/inject) を呼び出せる場所を説明します。コンポーネント、ディレクティブ、サービスの構築が最も一般的ですが、詳細については[注入コンテキスト](/guide/di/dependency-injection-context)を参照してください。
diff --git a/adev-ja/src/content/guide/directives/attribute-directives.en.md b/adev-ja/src/content/guide/directives/attribute-directives.en.md
index 843c1a4003..e072054840 100644
--- a/adev-ja/src/content/guide/directives/attribute-directives.en.md
+++ b/adev-ja/src/content/guide/directives/attribute-directives.en.md
@@ -67,7 +67,7 @@ The background color appears when the pointer hovers over the paragraph element
This section walks you through setting the highlight color while applying the `HighlightDirective`.
-1. In `highlight.directive.ts`, import `Input` from `@angular/core`.
+1. In `highlight.directive.ts`, import `input` from `@angular/core`.
` element in
template: 'admin-menu.html',
hostDirectives: [MenuBehavior],
})
-export class AdminMenu { }
+export class AdminMenu {}
```
When the framework renders a component, Angular also creates an instance of each host directive. The
@@ -45,13 +45,15 @@ in your component's API by expanding the entry in `hostDirectives`:
@Component({
selector: 'admin-menu',
template: 'admin-menu.html',
- hostDirectives: [{
- directive: MenuBehavior,
- inputs: ['menuId'],
- outputs: ['menuClosed'],
- }],
+ hostDirectives: [
+ {
+ directive: MenuBehavior,
+ inputs: ['menuId'],
+ outputs: ['menuClosed'],
+ },
+ ],
})
-export class AdminMenu { }
+export class AdminMenu {}
```
By explicitly specifying the inputs and outputs, consumers of the component with `hostDirective` can
@@ -69,13 +71,15 @@ component:
@Component({
selector: 'admin-menu',
template: 'admin-menu.html',
- hostDirectives: [{
- directive: MenuBehavior,
- inputs: ['menuId: id'],
- outputs: ['menuClosed: closed'],
- }],
+ hostDirectives: [
+ {
+ directive: MenuBehavior,
+ inputs: ['menuId: id'],
+ outputs: ['menuClosed: closed'],
+ },
+ ],
})
-export class AdminMenu { }
+export class AdminMenu {}
```
```angular-html
@@ -131,7 +135,7 @@ The following example shows minimal use of a host directive:
template: 'admin-menu.html',
hostDirectives: [MenuBehavior],
})
-export class AdminMenu { }
+export class AdminMenu {}
```
The order of execution here is:
diff --git a/adev-ja/src/content/guide/directives/directive-composition-api.md b/adev-ja/src/content/guide/directives/directive-composition-api.md
index 8722545645..faf9391d6b 100644
--- a/adev-ja/src/content/guide/directives/directive-composition-api.md
+++ b/adev-ja/src/content/guide/directives/directive-composition-api.md
@@ -20,7 +20,7 @@ Angularディレクティブは、再利用可能な動作をカプセル化す
template: 'admin-menu.html',
hostDirectives: [MenuBehavior],
})
-export class AdminMenu { }
+export class AdminMenu {}
```
フレームワークがコンポーネントをレンダリングすると、Angularは各ホストディレクティブのインスタンスも作成します。
@@ -45,13 +45,15 @@ export class AdminMenu { }
@Component({
selector: 'admin-menu',
template: 'admin-menu.html',
- hostDirectives: [{
- directive: MenuBehavior,
- inputs: ['menuId'],
- outputs: ['menuClosed'],
- }],
+ hostDirectives: [
+ {
+ directive: MenuBehavior,
+ inputs: ['menuId'],
+ outputs: ['menuClosed'],
+ },
+ ],
})
-export class AdminMenu { }
+export class AdminMenu {}
```
入力と出力を明示的に指定することで、`hostDirective` を持つコンポーネントのコンシューマーは
@@ -69,13 +71,15 @@ export class AdminMenu { }
@Component({
selector: 'admin-menu',
template: 'admin-menu.html',
- hostDirectives: [{
- directive: MenuBehavior,
- inputs: ['menuId: id'],
- outputs: ['menuClosed: closed'],
- }],
+ hostDirectives: [
+ {
+ directive: MenuBehavior,
+ inputs: ['menuId: id'],
+ outputs: ['menuClosed: closed'],
+ },
+ ],
})
-export class AdminMenu { }
+export class AdminMenu {}
```
```angular-html
@@ -131,7 +135,7 @@ export class SpecializedMenuWithTooltip { }
template: 'admin-menu.html',
hostDirectives: [MenuBehavior],
})
-export class AdminMenu { }
+export class AdminMenu {}
```
ここでの実行順序は次のとおりです。
diff --git a/adev-ja/src/content/guide/directives/structural-directives.en.md b/adev-ja/src/content/guide/directives/structural-directives.en.md
index 4c41ed1dd3..0e696ce225 100644
--- a/adev-ja/src/content/guide/directives/structural-directives.en.md
+++ b/adev-ja/src/content/guide/directives/structural-directives.en.md
@@ -85,7 +85,6 @@ export class SelectDirective {
private templateRef = inject(TemplateRef);
private viewContainerRef = inject(ViewContainerRef);
}
-
```
@@ -95,7 +94,6 @@ Add a `selectFrom` `input()` property.
```ts
export class SelectDirective {
// ...
-
selectFrom = input.required();
}
```
@@ -107,7 +105,6 @@ With `SelectDirective` now scaffolded as a structural directive with its input,
```ts
export class SelectDirective {
// ...
-
async ngOnInit() {
const data = await this.selectFrom.load();
this.viewContainerRef.createEmbeddedView(this.templateRef, {
@@ -129,9 +126,7 @@ That's it - `SelectDirective` is up and running. A follow-up step might be to [a
When you write your own structural directives, use the following syntax:
```ts {hideCopy}
-
-_:prefix="( :let | :expression ) (';' | ',')? ( :let | :as | :keyExp )_"
-
+_: prefix = "( :let | :expression ) (';' | ',')? ( :let | :as | :keyExp )_";
```
The following patterns describe each portion of the structural directive grammar:
diff --git a/adev-ja/src/content/guide/directives/structural-directives.md b/adev-ja/src/content/guide/directives/structural-directives.md
index 9741c73c37..32abd03686 100644
--- a/adev-ja/src/content/guide/directives/structural-directives.md
+++ b/adev-ja/src/content/guide/directives/structural-directives.md
@@ -85,7 +85,6 @@ export class SelectDirective {
private templateRef = inject(TemplateRef);
private viewContainerRef = inject(ViewContainerRef);
}
-
```
@@ -95,7 +94,6 @@ export class SelectDirective {
```ts
export class SelectDirective {
// ...
-
selectFrom = input.required();
}
```
@@ -107,7 +105,6 @@ export class SelectDirective {
```ts
export class SelectDirective {
// ...
-
async ngOnInit() {
const data = await this.selectFrom.load();
this.viewContainerRef.createEmbeddedView(this.templateRef, {
@@ -129,9 +126,7 @@ export class SelectDirective {
独自の構造ディレクティブを作成する際は、次の構文を使用します。
```ts {hideCopy}
-
-_:prefix="( :let | :expression ) (';' | ',')? ( :let | :as | :keyExp )_"
-
+_: prefix = "( :let | :expression ) (';' | ',')? ( :let | :as | :keyExp )_";
```
次のパターンは、構造ディレクティブ文法の各部分を説明しています。
diff --git a/adev-ja/src/content/guide/drag-drop.md b/adev-ja/src/content/guide/drag-drop.md
index 9962c92e9e..c33451438e 100644
--- a/adev-ja/src/content/guide/drag-drop.md
+++ b/adev-ja/src/content/guide/drag-drop.md
@@ -96,7 +96,7 @@ Use the `cdkDropListGroup` directive if you have an unknown number of connected
-
@@ -54,7 +54,7 @@ This separates form state management from your component's data model. The form
Template-driven Forms stores data in component properties. You access values directly:
```ts
-const credentials = { email: this.email, password: this.password };
+const credentials = {email: this.email, password: this.password};
```
This is the most direct approach but requires manually assembling values when you need them. Angular manages form state through directives in the template.
@@ -67,8 +67,8 @@ Signal Forms uses a schema function where you bind validators to field paths:
```ts
loginForm = form(this.loginModel, (fieldPath) => {
- required(fieldPath.email, { message: 'Email is required' });
- email(fieldPath.email, { message: 'Enter a valid email address' });
+ required(fieldPath.email, {message: 'Email is required'});
+ email(fieldPath.email, {message: 'Enter a valid email address'});
});
```
@@ -78,7 +78,7 @@ Reactive Forms attaches validators when creating controls:
```ts
loginForm = new FormGroup({
- email: new FormControl('', [Validators.required, Validators.email])
+ email: new FormControl('', [Validators.required, Validators.email]),
});
```
@@ -99,7 +99,7 @@ TypeScript integration differs significantly between approaches, affecting how m
Signal Forms infers types from your model structure:
```ts
-const loginModel = signal({ email: '', password: '' });
+const loginModel = signal({email: '', password: ''});
const loginForm = form(loginModel);
// TypeScript knows: loginForm.email exists and returns FieldState
```
@@ -111,7 +111,7 @@ Reactive Forms requires explicit type annotations with typed forms:
```ts
const loginForm = new FormGroup({
email: new FormControl(''),
- password: new FormControl('')
+ password: new FormControl(''),
});
// TypeScript knows: loginForm.controls.email is FormControl
```
diff --git a/adev-ja/src/content/guide/forms/signals/comparison.md b/adev-ja/src/content/guide/forms/signals/comparison.md
index 1837546ed0..082cc84840 100644
--- a/adev-ja/src/content/guide/forms/signals/comparison.md
+++ b/adev-ja/src/content/guide/forms/signals/comparison.md
@@ -22,7 +22,7 @@ NOTE: シグナルフォームはAngular v21の時点では[experimental](refere
違いを理解する最善の方法は、3つのアプローチすべてで実装された同じフォームを見ることです。
-
@@ -54,7 +54,7 @@ const credentials = this.loginForm.value; // { email: '...', password: '...' }
テンプレート駆動フォームは、コンポーネントのプロパティにデータを保存します。値に直接アクセスします。
```ts
-const credentials = { email: this.email, password: this.password };
+const credentials = {email: this.email, password: this.password};
```
これは最も直接的なアプローチですが、値が必要なときに手動で組み立てる必要があります。Angularは、テンプレート内のディレクティブを通じてフォームの状態を管理します。
@@ -67,8 +67,8 @@ const credentials = { email: this.email, password: this.password };
```ts
loginForm = form(this.loginModel, (fieldPath) => {
- required(fieldPath.email, { message: 'Email is required' });
- email(fieldPath.email, { message: 'Enter a valid email address' });
+ required(fieldPath.email, {message: 'Email is required'});
+ email(fieldPath.email, {message: 'Enter a valid email address'});
});
```
@@ -78,7 +78,7 @@ Reactive Formsは、コントロールを作成するときにバリデーター
```ts
loginForm = new FormGroup({
- email: new FormControl('', [Validators.required, Validators.email])
+ email: new FormControl('', [Validators.required, Validators.email]),
});
```
@@ -99,7 +99,7 @@ TypeScriptの統合はアプローチによって大きく異なり、コンパ
シグナルフォームは、モデル構造から型を推論します。
```ts
-const loginModel = signal({ email: '', password: '' });
+const loginModel = signal({email: '', password: ''});
const loginForm = form(loginModel);
// TypeScript knows: loginForm.email exists and returns FieldState
```
@@ -111,7 +111,7 @@ Reactive Formsは、型付きフォームで明示的な型アノテーション
```ts
const loginForm = new FormGroup({
email: new FormControl(''),
- password: new FormControl('')
+ password: new FormControl(''),
});
// TypeScript knows: loginForm.controls.email is FormControl
```
diff --git a/adev-ja/src/content/guide/forms/signals/custom-controls.en.md b/adev-ja/src/content/guide/forms/signals/custom-controls.en.md
index 6492b3d557..163aee9bc6 100644
--- a/adev-ja/src/content/guide/forms/signals/custom-controls.en.md
+++ b/adev-ja/src/content/guide/forms/signals/custom-controls.en.md
@@ -419,14 +419,16 @@ IMPORTANT: Don't implement validation logic in your control. Define validation r
```typescript
// Avoid: Validation in control
export class BadControl implements FormValueControl {
- value = model('')
- isValid() { return this.value().length >= 8 } // Don't do this!
+ value = model('');
+ isValid() {
+ return this.value().length >= 8;
+ } // Don't do this!
}
// Good: Validation in schema, control displays results
-accountForm = form(this.accountModel, schemaPath => {
- minLength(schemaPath.password, 8, { message: 'Password must be at least 8 characters' })
-})
+accountForm = form(this.accountModel, (schemaPath) => {
+ minLength(schemaPath.password, 8, {message: 'Password must be at least 8 characters'});
+});
```
## Next steps
diff --git a/adev-ja/src/content/guide/forms/signals/custom-controls.md b/adev-ja/src/content/guide/forms/signals/custom-controls.md
index 419ef14201..49aebe6ac2 100644
--- a/adev-ja/src/content/guide/forms/signals/custom-controls.md
+++ b/adev-ja/src/content/guide/forms/signals/custom-controls.md
@@ -419,14 +419,16 @@ IMPORTANT: コントロールにバリデーションロジックを実装しな
```typescript
// 悪い例：コントロール内でのバリデーション
export class BadControl implements FormValueControl {
- value = model('')
- isValid() { return this.value().length >= 8 } // これは行わないでください！
+ value = model('');
+ isValid() {
+ return this.value().length >= 8;
+ } // これは行わないでください！
}
// 良い例：スキーマでバリデーションし、コントロールは結果を表示
-accountForm = form(this.accountModel, schemaPath => {
- minLength(schemaPath.password, 8, { message: 'Password must be at least 8 characters' })
-})
+accountForm = form(this.accountModel, (schemaPath) => {
+ minLength(schemaPath.password, 8, {message: 'Password must be at least 8 characters'});
+});
```
## 次のステップ {#next-steps}
diff --git a/adev-ja/src/content/guide/forms/signals/designing-your-form-model.md b/adev-ja/src/content/guide/forms/signals/designing-your-form-model.md
index f78d33d782..007f092d3a 100644
--- a/adev-ja/src/content/guide/forms/signals/designing-your-form-model.md
+++ b/adev-ja/src/content/guide/forms/signals/designing-your-form-model.md
@@ -10,14 +10,14 @@ The form model represents the raw user input as it appears in the UI. For instan
```ts
interface AppointmentFormModel {
- name: string; // Appointment owner's name
- date: Date; // Appointment date (carries only date information, time component is unused)
- time: string; // Selected time as a string
+ name: string; // Appointment owner's name
+ date: Date; // Appointment date (carries only date information, time component is unused)
+ time: string; // Selected time as a string
}
interface AppointmentDomainModel {
- name: string; // Appointment owner's name
- time: Date; // Appointment time (carries both date and time information)
+ name: string; // Appointment owner's name
+ time: Date; // Appointment time (carries both date and time information)
}
```
@@ -38,15 +38,15 @@ const taskModel = signal({
title: '',
description: '',
priority: 'medium',
- completed: false
-})
+ completed: false,
+});
```
```ts {avoid, header: 'Partial initialization'}
const taskModel = signal({
- title: ''
+ title: '',
// Missing description, priority, completed
-})
+});
```
Missing initial values mean those fields won't exist in the field tree, making them inaccessible for form interactions.
@@ -58,8 +58,8 @@ Each model should represent a single form or a cohesive set of related data:
```ts {prefer, header: 'Focused on a single purpose'}
const loginModel = signal({
email: '',
- password: ''
-})
+ password: '',
+});
```
```ts {avoid, header: 'Mixing unrelated concerns'}
@@ -71,8 +71,8 @@ const appModel = signal({
theme: 'light',
language: 'en',
// Shopping cart
- cartItems: []
-})
+ cartItems: [],
+});
```
Separate models for different concerns makes forms easier to understand and reuse. Create multiple forms if you're managing distinct sets of data.
@@ -84,9 +84,9 @@ Design models with validation in mind. Group fields that validate together:
```ts {prefer, header: 'Related fields grouped for comparison'}
// Password fields grouped for comparison
interface PasswordChangeData {
- currentPassword: string
- newPassword: string
- confirmPassword: string
+ currentPassword: string;
+ newPassword: string;
+ confirmPassword: string;
}
```
@@ -102,8 +102,8 @@ Although the size options look numeric, `
An image loader is not **required** in order to use NgOptimizedImage, but using one with an image CDN enables powerful performance features, including automatic `srcset`s for your images.
@@ -53,9 +50,7 @@ A brief guide for setting up a loader can be found in the [Configuring an Image
To activate the `NgOptimizedImage` directive, replace your image's `src` attribute with `ngSrc`.
```html
-
-![]()
-
+![]()
```
If you're using a [built-in third-party loader](#built-in-loaders), make sure to omit the base URL path from `src`, as that will be prepended automatically by the loader.
@@ -64,9 +59,7 @@ If you're using a [built-in third-party loader](#built-in-loaders), make sure to
Always mark the [LCP image](https://web.dev/lcp/#what-elements-are-considered) on your page as `priority` to prioritize its loading.
```html
-
-![]()
-
+![]()
```
Marking an image as `priority` applies the following optimizations:
@@ -81,9 +74,7 @@ Angular displays a warning during development if the LCP element is an image tha
In order to prevent [image-related layout shifts](https://web.dev/css-web-vitals/#images-and-layout-shifts), NgOptimizedImage requires that you specify a height and width for your image, as follows:
```html
-
-![]()
-
+![]()
```
For **responsive images** (images which you've styled to grow and shrink relative to the viewport), the `width` and `height` attributes should be the intrinsic size of the image file. For responsive images it's also important to [set a value for `sizes`.](#responsive-images)
@@ -101,9 +92,7 @@ In cases where you want to have an image fill a containing element, you can use
When you add the `fill` attribute to your image, you do not need and should not include a `width` and `height`, as in this example:
```html
-
-![]()
-
+![]()
```
You can use the [object-fit](https://developer.mozilla.org/docs/Web/CSS/object-fit) CSS property to change how the image will fill its container. If you style your image with `object-fit: "contain"`, the image will maintain its aspect ratio and be "letterboxed" to fit the element. If you set `object-fit: "cover"`, the element will retain its aspect ratio, fully fill the element, and some content may be "cropped" off.
@@ -133,9 +122,7 @@ You can adjust how the background image fills the container as described in the
NgOptimizedImage can display an automatic low-resolution placeholder for your image if you're using a CDN or image host that provides automatic image resizing. Take advantage of this feature by adding the `placeholder` attribute to your image:
```html
-
-![]()
-
+![]()
```
Adding this attribute automatically requests a second, smaller version of the image using your specified image loader. This small image will be applied as a `background-image` style with a CSS blur while your image loads. If no image loader is provided, no placeholder image can be generated and an error will be thrown.
@@ -160,14 +147,7 @@ If you want sharp edges around your blurred placeholder, you can wrap your image
You can also specify a placeholder using a base64 [data URL](https://developer.mozilla.org/docs/Web/HTTP/Basics_of_HTTP/Data_URLs) without an image loader. The data url format is `data:image/[imagetype];[data]`, where `[imagetype]` is the image format, just as `png`, and `[data]` is a base64 encoding of the image. That encoding can be done using the command line or in JavaScript. For specific commands, see [the MDN documentation](https://developer.mozilla.org/docs/Web/HTTP/Basics_of_HTTP/Data_URLs#encoding_data_into_base64_format). An example of a data URL placeholder with truncated data is shown below:
```html
-
-![]()
-
+![]()
```
However, large data URLs increase the size of your Angular bundles and slow down page load. If you cannot use an image loader, the Angular team recommends keeping base64 placeholder images smaller than 4KB and using them exclusively on critical images. In addition to decreasing placeholder dimensions, consider changing image formats or parameters used when saving images. At very low resolutions, these parameters can have a large effect on file size.
@@ -177,13 +157,7 @@ However, large data URLs increase the size of your Angular bundles and slow down
By default, NgOptimizedImage applies a CSS blur effect to image placeholders. To render a placeholder without blur, provide a `placeholderConfig` argument with an object that includes the `blur` property, set to false. For example:
```html
-![]()
+![]()
```
## Adjusting image styling
@@ -205,9 +179,7 @@ A [`preconnect` resource hint](https://web.dev/preconnect-and-dns-prefetch) for
Preconnect links are automatically generated for domains provided as an argument to a [loader](#optional-set-up-a-loader). If an image origin cannot be automatically identified, and no preconnect link is detected for the LCP image, `NgOptimizedImage` will warn during development. In that case, you should manually add a resource hint to `index.html`. Within the `` of the document, add a `link` tag with `rel="preconnect"`, as shown below:
```html
-
-
```
To disable preconnect warnings, inject the `PRECONNECT_CHECK_BLOCKLIST` token:
@@ -233,7 +205,7 @@ If your image should be "fixed" in size (i.e. the same size across devices, exce
Example srcset generated:
```html
-![]()
+![]()
```
#### Responsive images
@@ -266,17 +238,13 @@ providers: [
If you would like to manually define a `srcset` attribute, you can provide your own using the `ngSrcset` attribute:
```html
-
-![]()
-
+![]()
```
If the `ngSrcset` attribute is present, `NgOptimizedImage` generates and sets the `srcset` based on the sizes included. Do not include image file names in `ngSrcset` - the directive infers this information from `ngSrc`. The directive supports both width descriptors (e.g. `100w`) and density descriptors (e.g. `1x`).
```html
-
-![]()
-
+![]()
```
### Disabling automatic srcset generation
@@ -284,9 +252,7 @@ If the `ngSrcset` attribute is present, `NgOptimizedImage` generates and sets th
To disable srcset generation for a single image, you can add the `disableOptimizedSrcset` attribute on the image:
```html
-
-![]()
-
+![]()
```
### Disabling image lazy loading
@@ -294,9 +260,7 @@ To disable srcset generation for a single image, you can add the `disableOptimiz
By default, `NgOptimizedImage` sets `loading=lazy` for all images that are not marked `priority`. You can disable this behavior for non-priority images by setting the `loading` attribute. This attribute accepts values: `eager`, `auto`, and `lazy`. [See the documentation for the standard image `loading` attribute for details](https://developer.mozilla.org/docs/Web/API/HTMLImageElement/loading#value).
```html
-
-![]()
-
+![]()
```
### Controlling image decoding
@@ -308,16 +272,16 @@ You can still override this behavior by explicitly setting the `decoding` attrib
```html
-![]()
+![]()
-![]()
+![]()
-![]()
+![]()
-![]()
+![]()
```
**Allowed values**
@@ -331,9 +295,7 @@ You can still override this behavior by explicitly setting the `decoding` attrib
You may want to have images displayed at varying widths on differently-sized screens. A common example of this pattern is a grid- or column-based layout that renders a single column on mobile devices, and two columns on larger devices. You can capture this behavior in the `sizes` attribute, using a "media query" syntax, such as the following:
```html
-
-![]()
-
+![]()
```
The `sizes` attribute in the above example says "I expect this image to be 100 percent of the screen width on devices under 768px wide. Otherwise, I expect it to be 50 percent of the screen width.
@@ -428,9 +390,7 @@ const myCustomLoader = (config: ImageLoaderConfig) => {
Note that in the above example, we've invented the 'roundedCorners' property name to control a feature of our custom loader. We could then use this feature when creating an image, as follows:
```html
-
-![]()
-
+![]()
```
## Frequently Asked Questions
diff --git a/adev-ja/src/content/guide/image-optimization.md b/adev-ja/src/content/guide/image-optimization.md
index 7459cc38e3..8945183c4f 100644
--- a/adev-ja/src/content/guide/image-optimization.md
+++ b/adev-ja/src/content/guide/image-optimization.md
@@ -28,9 +28,7 @@ CSSで背景画像を使用している場合は、[こちらから開始して
`NgOptimizedImage`ディレクティブを`@angular/common`からインポートします。
```ts
-
-import { NgOptimizedImage } from '@angular/common'
-
+import {NgOptimizedImage} from '@angular/common';
```
そして、スタンドアロンコンポーネントまたはNgModuleの`imports`配列に含めます。
@@ -42,7 +40,6 @@ imports: [
],
```
-
NgOptimizedImageを使用するために画像ローダーは**必須ではありません**が、画像CDNと組み合わせて使用すると、画像の自動`srcset`を含む強力なパフォーマンス機能が有効になります。
@@ -53,9 +50,7 @@ NgOptimizedImageを使用するために画像ローダーは**必須ではあ
`NgOptimizedImage`ディレクティブを有効にするには、画像の`src`属性を`ngSrc`に置き換えます。
```html
-
-![]()
-
+![]()
```
[組み込みのサードパーティローダー](#built-in-loaders)を使用している場合は、`src`からベースURLパスを省略してください。これはローダーによって自動的に前置されます。
@@ -64,9 +59,7 @@ NgOptimizedImageを使用するために画像ローダーは**必須ではあ
ページの[LCP画像](https://web.dev/lcp/#what-elements-are-considered)は、その読み込みを優先するために常に`priority`としてマークしてください。
```html
-
-![]()
-
+![]()
```
画像を`priority`としてマークすると、以下の最適化が適用されます。
@@ -81,9 +74,7 @@ LCP要素が`priority`属性を持たない画像である場合、Angularは開
[画像関連のレイアウトシフト](https://web.dev/css-web-vitals/#images-and-layout-shifts)を防ぐため、NgOptimizedImageでは次のように画像の高さと幅を指定する必要があります。
```html
-
-![]()
-
+![]()
```
**レスポンシブ画像**（ビューポートに対して拡大縮小するようにスタイル設定された画像）の場合、`width`および`height`属性は画像ファイルの固有のサイズである必要があります。レスポンシブ画像の場合、[`sizes`の値を設定する](#responsive-images)ことも重要です。
@@ -101,9 +92,7 @@ NOTE: 画像のサイズが不明な場合は、以下で説明するように
画像に`fill`属性を追加する場合、以下の例のように`width`と`height`を含める必要はなく、含めるべきではありません。
```html
-
-![]()
-
+![]()
```
[object-fit](https://developer.mozilla.org/docs/Web/CSS/object-fit)CSSプロパティを使用して、画像がコンテナをどのように埋めるかを変更できます。画像を`object-fit: "contain"`でスタイル設定すると、画像はアスペクト比を維持し、要素にフィットするように「レターボックス」されます。`object-fit: "cover"`を設定すると、要素はアスペクト比を維持し、要素を完全に埋めますが、一部のコンテンツは「切り取られる」場合があります。
@@ -133,9 +122,7 @@ IMPORTANT:「fill」画像が適切にレンダリングされるには、その
NgOptimizedImageは、CDNまたは画像ホストが自動画像リサイズを提供している場合、画像の低解像度の自動プレースホルダーを表示できます。この機能を利用するには、画像に`placeholder`属性を追加します。
```html
-
-![]()
-
+![]()
```
この属性を追加すると、指定された画像ローダーを使用して、画像の2番目の小さいバージョンが自動的にリクエストされます。この小さい画像は、画像が読み込まれる間、CSSのぼかしを伴う`background-image`スタイルとして適用されます。画像ローダーが提供されていない場合、プレースホルダー画像は生成されず、エラーがスローされます。
@@ -160,14 +147,7 @@ providers: [
画像ローダーなしで、base64 [データURL](https://developer.mozilla.org/docs/Web/HTTP/Basics_of_HTTP/Data_URLs)を使用してプレースホルダーを指定できます。データURLの形式は`data:image/[imagetype];[data]`で、`[imagetype]`は`png`のような画像形式、`[data]`は画像のbase64エンコーディングです。このエンコーディングはコマンドラインまたはJavaScriptで行うことができます。具体的なコマンドについては、[MDNドキュメント](https://developer.mozilla.org/docs/Web/HTTP/Basics_of_HTTP/Data_URLs#encoding_data_into_base64_format)を参照してください。データが切り詰められたデータURLプレースホルダーの例を以下に示します。
```html
-
-![]()
-
+![]()
```
しかし、大きなデータURLはAngularバンドルのサイズを増やし、ページロードを遅くします。画像ローダーを使用できない場合、Angularチームはbase64プレースホルダー画像を4KB未満に保ち、重要な画像にのみ使用することを推奨しています。プレースホルダーの寸法を小さくすることに加えて、画像形式や画像を保存する際に使用するパラメーターの変更も検討してください。非常に低い解像度では、これらのパラメーターがファイルサイズに大きな影響を与える可能性があります。
@@ -177,13 +157,7 @@ providers: [
デフォルトでは、NgOptimizedImageは画像プレースホルダーにCSSのぼかし効果を適用します。ぼかしなしでプレースホルダーをレンダリングするには、`blur`プロパティをfalseに設定したオブジェクトを含む`placeholderConfig`引数を指定します。例:
```html
-![]()
+![]()
```
## 画像のスタイル調整 {#adjusting-image-styling}
@@ -205,9 +179,7 @@ NgOptimizedImageには、アプリケーションの読み込みパフォーマ
プリコネクトリンクは、[ローダー](#configuring-an-image-loader-for-ngoptimizedimage)への引数として提供されたドメインに対して自動的に生成されます。画像オリジンを自動的に識別できない場合、またはLCP画像に対してプリコネクトリンクが検出されない場合、`NgOptimizedImage`は開発中に警告を表示します。その場合、`index.html`にリソースヒントを手動で追加する必要があります。ドキュメントの``内に、以下に示すように`rel="preconnect"`を持つ`link`タグを追加します。
```html
-
-
```
プリコネクト警告を無効にするには、`PRECONNECT_CHECK_BLOCKLIST`トークンをインジェクトします。
@@ -233,7 +205,7 @@ providers: [
生成されるsrcsetの例:
```html
-![]()
+![]()
```
#### レスポンシブ画像 {#responsive-images}
@@ -266,17 +238,13 @@ providers: [
`srcset`属性を手動で定義したい場合、`ngSrcset`属性を使用して独自のものを指定できます:
```html
-
-![]()
-
+![]()
```
`ngSrcset`属性が存在する場合、`NgOptimizedImage`は含まれるサイズに基づいて`srcset`を生成および設定します。`ngSrcset`に画像ファイル名を含めないでください。ディレクティブはこの情報を`ngSrc`から推測します。このディレクティブは、幅記述子（例: `100w`）と密度記述子（例: `1x`）の両方をサポートしています。
```html
-
-![]()
-
+![]()
```
### 自動srcset生成の無効化 {#disabling-automatic-srcset-generation}
@@ -284,9 +252,7 @@ providers: [
単一の画像に対してsrcset生成を無効にするには、画像に`disableOptimizedSrcset`属性を追加できます。
```html
-
-![]()
-
+![]()
```
### 画像の遅延読み込みの無効化 {#disabling-image-lazy-loading}
@@ -294,9 +260,7 @@ providers: [
デフォルトでは、`NgOptimizedImage`は`priority`とマークされていないすべての画像に対して`loading=lazy`を設定します。優先度の低い画像に対してこの動作を無効にするには、`loading`属性を設定します。この属性は`eager`、`auto`、`lazy`の値をサポートします。詳細については、[標準の画像`loading`属性に関するドキュメントを参照してください](https://developer.mozilla.org/docs/Web/API/HTMLImageElement/loading#value)。
```html
-
-![]()
-
+![]()
```
### 画像のデコード制御 {#controlling-image-decoding}
@@ -308,16 +272,16 @@ providers: [
```html
-![]()
+![]()
-![]()
+![]()
-![]()
+![]()
-![]()
+![]()
```
**許可される値**
@@ -331,9 +295,7 @@ providers: [
異なるサイズの画面で画像を異なる幅で表示したい場合があります。このパターンの一般的な例は、モバイルデバイスでは単一の列を、より大きなデバイスでは2つの列をレンダリングするグリッドベースまたはカラムベースのレイアウトです。この動作は、以下のような「メディアクエリ」構文を使用して`sizes`属性で表現できます。
```html
-
-![]()
-
+![]()
```
上記の例の`sizes`属性は、「この画像は幅768px未満のデバイスでは画面幅の100%になることを想定しています。それ以外の場合は、画面幅の50%になることを想定しています。」という意味です。
@@ -428,9 +390,7 @@ const myCustomLoader = (config: ImageLoaderConfig) => {
上記の例では、カスタムローダーの機能を制御するために「roundedCorners」というプロパティ名を考案したことに注意してください。この機能は、画像を生成する際に次のように使用できます。
```html
-
-![]()
-
+![]()
```
## よくある質問 {#frequently-asked-questions}
diff --git a/adev-ja/src/content/guide/ngmodules/overview.md b/adev-ja/src/content/guide/ngmodules/overview.md
index c0b4bbdfd7..76739afcee 100644
--- a/adev-ja/src/content/guide/ngmodules/overview.md
+++ b/adev-ja/src/content/guide/ngmodules/overview.md
@@ -10,7 +10,7 @@ import {NgModule} from '@angular/core';
@NgModule({
// Metadata goes here
})
-export class CustomMenuModule { }
+export class CustomMenuModule {}
```
An NgModule has two main responsibilities:
@@ -28,7 +28,7 @@ The `declarations` property of the `@NgModule` metadata declares the components,
// CustomMenu and CustomMenuItem are components.
declarations: [CustomMenu, CustomMenuItem],
})
-export class CustomMenuModule { }
+export class CustomMenuModule {}
```
In the example above, the components `CustomMenu` and `CustomMenuItem` belong to `CustomMenuModule`.
@@ -45,7 +45,7 @@ const WIDGETS = [MENU_COMPONENTS, CustomSlider];
// CustomSlider, and CustomCheckbox.
declarations: [WIDGETS, CustomCheckbox],
})
-export class CustomMenuModule { }
+export class CustomMenuModule {}
```
If Angular discovers any components, directives, or pipes declared in more than one NgModule, it reports an error.
@@ -58,7 +58,9 @@ Any components, directives, or pipes must be explicitly marked as `standalone: f
standalone: false,
/* ... */
})
-export class CustomMenu { /* ... */ }
+export class CustomMenu {
+ /* ... */
+}
```
### imports
@@ -72,7 +74,7 @@ Components declared in an NgModule may depend on other components, directives, a
imports: [PopupTrigger, SelectionIndicator],
declarations: [CustomMenu, CustomMenuItem],
})
-export class CustomMenuModule { }
+export class CustomMenuModule {}
```
The `imports` array accepts other NgModules, as well as standalone components, directives, and pipes.
@@ -83,27 +85,27 @@ An NgModule can _export_ its declared components, directives, and pipes such tha
```typescript
@NgModule({
- imports: [PopupTrigger, SelectionIndicator],
- declarations: [CustomMenu, CustomMenuItem],
+ imports: [PopupTrigger, SelectionIndicator],
+ declarations: [CustomMenu, CustomMenuItem],
- // Make CustomMenu and CustomMenuItem available to
- // components and NgModules that import CustomMenuModule.
- exports: [CustomMenu, CustomMenuItem],
+ // Make CustomMenu and CustomMenuItem available to
+ // components and NgModules that import CustomMenuModule.
+ exports: [CustomMenu, CustomMenuItem],
})
-export class CustomMenuModule { }
+export class CustomMenuModule {}
```
The `exports` property is not limited to declarations, however. An NgModule can also export any other components, directives, pipes, and NgModules that it imports.
```typescript
@NgModule({
- imports: [PopupTrigger, SelectionIndicator],
- declarations: [CustomMenu, CustomMenuItem],
+ imports: [PopupTrigger, SelectionIndicator],
+ declarations: [CustomMenu, CustomMenuItem],
- // Also make PopupTrigger available to any component or NgModule that imports CustomMenuModule.
- exports: [CustomMenu, CustomMenuItem, PopupTrigger],
+ // Also make PopupTrigger available to any component or NgModule that imports CustomMenuModule.
+ exports: [CustomMenu, CustomMenuItem, PopupTrigger],
})
-export class CustomMenuModule { }
+export class CustomMenuModule {}
```
## `NgModule` providers
@@ -124,14 +126,14 @@ An `NgModule` can specify `providers` for injected dependencies. These providers
providers: [OverlayManager],
/* ... */
})
-export class CustomMenuModule { }
+export class CustomMenuModule {}
@NgModule({
imports: [CustomMenuModule],
declarations: [UserProfile],
providers: [UserDataClient],
})
-export class UserProfileModule { }
+export class UserProfileModule {}
```
In the example above:
@@ -149,9 +151,7 @@ Any providers included in this way are eagerly loaded, increasing the JavaScript
```typescript
bootstrapApplication(MyApplicationRoot, {
- providers: [
- CustomMenuModule.forRoot(/* some config */),
- ],
+ providers: [CustomMenuModule.forRoot(/* some config */)],
});
```
@@ -160,11 +160,11 @@ Similarly, some NgModules may define a static `forChild` that indicates the prov
```typescript
@Component({
/* ... */
- providers: [
- CustomMenuModule.forChild(/* some config */),
- ],
+ providers: [CustomMenuModule.forChild(/* some config */)],
})
-export class UserProfile { /* ... */ }
+export class UserProfile {
+ /* ... */
+}
```
## Bootstrapping an application
@@ -173,7 +173,7 @@ IMPORTANT: The Angular team recommends using [bootstrapApplication](api/platform
The `@NgModule` decorator accepts an optional `bootstrap` array that may contain one or more components.
-You can use the [`bootstrapModule`](https://angular.dev/api/core/PlatformRef#bootstrapModule) method from either [`platformBrowser`](api/platform-browser/platformBrowser) or [`platformServer`](api/platform-server/platformServer) to start an Angular application. When run, this function locates any elements on the page with a CSS selector that matches the listed componet(s) and renders those components on the page.
+You can use the [`bootstrapModule`](/api/core/PlatformRef#bootstrapModule) method from either [`platformBrowser`](api/platform-browser/platformBrowser) or [`platformServer`](api/platform-server/platformServer) to start an Angular application. When run, this function locates any elements on the page with a CSS selector that matches the listed componet(s) and renders those components on the page.
```typescript
import {platformBrowser} from '@angular/platform-browser';
@@ -181,7 +181,7 @@ import {platformBrowser} from '@angular/platform-browser';
@NgModule({
bootstrap: [MyApplication],
})
-export class MyApplicationModule { }
+export class MyApplicationModule {}
platformBrowser().bootstrapModule(MyApplicationModule);
```
diff --git a/adev-ja/src/content/guide/routing/common-router-tasks.en.md b/adev-ja/src/content/guide/routing/common-router-tasks.en.md
index 9d4ce0574b..61c29c5ead 100644
--- a/adev-ja/src/content/guide/routing/common-router-tasks.en.md
+++ b/adev-ja/src/content/guide/routing/common-router-tasks.en.md
@@ -22,9 +22,7 @@ To get information from a route:
Add the `withComponentInputBinding` feature to the `provideRouter` method.
```ts
-providers: [
- provideRouter(appRoutes, withComponentInputBinding()),
-]
+providers: [provideRouter(appRoutes, withComponentInputBinding())];
```
@@ -34,7 +32,7 @@ providers: [
Update the component to have an `input()` property matching the name of the parameter.
```ts
-id = input.required()
+id = input.required();
hero = computed(() => this.service.getHero(id()));
```
@@ -51,7 +49,7 @@ id = input.required({
transform: (maybeUndefined: string | undefined) => maybeUndefined ?? '0',
});
// or
-id = input();
+id = input();
internalId = linkedSignal(() => this.id() ?? getDefaultId());
```
@@ -68,9 +66,9 @@ To display a 404 page, set up a [wildcard route](guide/routing/common-router-tas
```ts
const routes: Routes = [
- { path: 'first-component', component: FirstComponent },
- { path: 'second-component', component: SecondComponent },
- { path: '**', component: PageNotFoundComponent }, // Wildcard route for a 404 page
+ {path: 'first-component', component: FirstComponent},
+ {path: 'second-component', component: SecondComponent},
+ {path: '**', component: PageNotFoundComponent}, // Wildcard route for a 404 page
];
```
diff --git a/adev-ja/src/content/guide/routing/common-router-tasks.md b/adev-ja/src/content/guide/routing/common-router-tasks.md
index 583a712205..e58eba4c51 100644
--- a/adev-ja/src/content/guide/routing/common-router-tasks.md
+++ b/adev-ja/src/content/guide/routing/common-router-tasks.md
@@ -22,9 +22,7 @@
`provideRouter` メソッドに `withComponentInputBinding` 機能を追加します。
```ts
-providers: [
- provideRouter(appRoutes, withComponentInputBinding()),
-]
+providers: [provideRouter(appRoutes, withComponentInputBinding())];
```
@@ -34,7 +32,7 @@ providers: [
パラメータ名と一致する `input()` プロパティを持つようにコンポーネントを更新します。
```ts
-id = input.required()
+id = input.required();
hero = computed(() => this.service.getHero(id()));
```
@@ -51,7 +49,7 @@ id = input.required({
transform: (maybeUndefined: string | undefined) => maybeUndefined ?? '0',
});
// or
-id = input();
+id = input();
internalId = linkedSignal(() => this.id() ?? getDefaultId());
```
@@ -68,9 +66,9 @@ NOTE: 静的なルートデータ、解決されたルートデータ、パス
```ts
const routes: Routes = [
- { path: 'first-component', component: FirstComponent },
- { path: 'second-component', component: SecondComponent },
- { path: '**', component: PageNotFoundComponent }, // Wildcard route for a 404 page
+ {path: 'first-component', component: FirstComponent},
+ {path: 'second-component', component: SecondComponent},
+ {path: '**', component: PageNotFoundComponent}, // Wildcard route for a 404 page
];
```
diff --git a/adev-ja/src/content/guide/routing/customizing-route-behavior.en.md b/adev-ja/src/content/guide/routing/customizing-route-behavior.en.md
index a489a8e15d..ae063dd423 100644
--- a/adev-ja/src/content/guide/routing/customizing-route-behavior.en.md
+++ b/adev-ja/src/content/guide/routing/customizing-route-behavior.en.md
@@ -24,7 +24,7 @@ Switching to `'computed'` keeps the in-flight history index in sync with the Ang
This setting is most helpful when your app uses `urlUpdateStrategy: 'eager'` or when guards frequently cancel popstate navigations initiated by the browser.
```ts
-provideRouter(routes, withRouterConfig({ canceledNavigationResolution: 'computed' }));
+provideRouter(routes, withRouterConfig({canceledNavigationResolution: 'computed'}));
```
### React to same-URL navigations
@@ -34,13 +34,13 @@ provideRouter(routes, withRouterConfig({ canceledNavigationResolution: 'computed
This is useful when you want repeated clicks on a list filter, left-nav item, or refresh button to trigger new data retrieval even though the URL does not change.
```ts
-provideRouter(routes, withRouterConfig({ onSameUrlNavigation: 'reload' }));
+provideRouter(routes, withRouterConfig({onSameUrlNavigation: 'reload'}));
```
You can also control this behavior on individual navigations rather than globally. This allows you to keep the keep the default of `'ignore'` while selectively enabling reload behavior for specific use cases:
```ts
-router.navigate(['/some-path'], { onSameUrlNavigation: 'reload' });
+router.navigate(['/some-path'], {onSameUrlNavigation: 'reload'});
```
### Control parameter inheritance
@@ -50,7 +50,7 @@ router.navigate(['/some-path'], { onSameUrlNavigation: 'reload' });
With the default `'emptyOnly'`, child routes inherit params only when their path is empty or the parent does not declare a component.
```ts
-provideRouter(routes, withRouterConfig({ paramsInheritanceStrategy: 'always' }));
+provideRouter(routes, withRouterConfig({paramsInheritanceStrategy: 'always'}));
```
```ts
@@ -65,17 +65,19 @@ export const routes: Routes = [
children: [
{
path: 'customers/:customerId',
- component: Customer
- }
- ]
- }
- ]
- }
+ component: Customer,
+ },
+ ],
+ },
+ ],
+ },
];
```
```ts
-@Component({ /* ... */})
+@Component({
+ /* ... */
+})
export class CustomerComponent {
private route = inject(ActivatedRoute);
@@ -85,10 +87,16 @@ export class CustomerComponent {
}
```
-Using `'always'` ensures matrix parameters, route data, and resolved values are available further down the route tree—handy when you share contextual identifiers across feature areas such as `/org/:orgId/projects/:projectId/customers/:customerId`.
+Using `'always'` ensures matrix parameters, route data, and resolved values are available further down the route tree—handy when you share contextual identifiers across feature areas such as:
+
+```text {hideCopy}
+/org/:orgId/projects/:projectId/customers/:customerId
+```
```ts
-@Component({ /* ... */})
+@Component({
+ /* ... */
+})
export class CustomerComponent {
private route = inject(ActivatedRoute);
@@ -106,7 +114,7 @@ export class CustomerComponent {
Consider this when your analytics pipeline needs to see the attempted route even if guards block it.
```ts
-provideRouter(routes, withRouterConfig({ urlUpdateStrategy: 'eager' }));
+provideRouter(routes, withRouterConfig({urlUpdateStrategy: 'eager'}));
```
### Choose default query parameter handling
@@ -114,7 +122,7 @@ provideRouter(routes, withRouterConfig({ urlUpdateStrategy: 'eager' }));
`defaultQueryParamsHandling` sets the fallback behavior for `Router.createUrlTree` when the call does not specify `queryParamsHandling`. `'replace'` is the default and swaps out the existing query string. `'merge'` combines the provided values with the current ones, and `'preserve'` keeps the existing query parameters unless you explicitly supply new ones.
```ts
-provideRouter(routes, withRouterConfig({ defaultQueryParamsHandling: 'merge' }));
+provideRouter(routes, withRouterConfig({defaultQueryParamsHandling: 'merge'}));
```
This is especially helpful for search and filter pages to automatically retain existing filters when additional parameters are provided.
@@ -147,21 +155,27 @@ Angular's `RouteReuseStrategy` class allows you to customize navigation behavior
"Detached route handles" are Angular's way of storing component instances and their entire view hierarchy. When a route is detached, Angular preserves the component instance, its child components, and all associated state in memory. This preserved state can later be reattached when navigating back to the route.
-The `RouteReuseStrategy` class provides five methods that control the lifecycle of route components:
+The `RouteReuseStrategy` class provides the following methods that control the lifecycle of route components:
-| Method | Description |
-| -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
-| [`shouldDetach`](api/router/RouteReuseStrategy#shouldDetach) | Determines if a route should be stored for later reuse when navigating away |
-| [`store`](api/router/RouteReuseStrategy#store) | Stores the detached route handle when `shouldDetach` returns true |
-| [`shouldAttach`](api/router/RouteReuseStrategy#shouldAttach) | Determines if a stored route should be reattached when navigating to it |
-| [`retrieve`](api/router/RouteReuseStrategy#retrieve) | Returns the previously stored route handle for reattachment |
-| [`shouldReuseRoute`](api/router/RouteReuseStrategy#shouldReuseRoute) | Determines if the router should reuse the current route instance instead of destroying it during navigation |
+| Method | Description |
+| ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- |
+| [`shouldDetach`](api/router/RouteReuseStrategy#shouldDetach) | Determines if a route should be stored for later reuse when navigating away |
+| [`store`](api/router/RouteReuseStrategy#store) | Stores the detached route handle when `shouldDetach` returns true |
+| [`shouldAttach`](api/router/RouteReuseStrategy#shouldAttach) | Determines if a stored route should be reattached when navigating to it |
+| [`retrieve`](api/router/RouteReuseStrategy#retrieve) | Returns the previously stored route handle for reattachment |
+| [`shouldReuseRoute`](api/router/RouteReuseStrategy#shouldReuseRoute) | Determines if the router should reuse the current route instance instead of destroying it during navigation |
+| [`shouldDestroyInjector`](api/router/RouteReuseStrategy#shouldDestroyInjector) | (Experimental) Determines if the router should destroy the injector of a detached route when it is no longer stored |
The following example demonstrates a custom route reuse strategy that selectively preserves component state based on route metadata:
```ts
-import { RouteReuseStrategy, Route, ActivatedRouteSnapshot, DetachedRouteHandle } from '@angular/router';
-import { Injectable } from '@angular/core';
+import {
+ RouteReuseStrategy,
+ Route,
+ ActivatedRouteSnapshot,
+ DetachedRouteHandle,
+} from '@angular/router';
+import {Injectable} from '@angular/core';
@Injectable()
export class CustomRouteReuseStrategy implements RouteReuseStrategy {
@@ -189,7 +203,7 @@ export class CustomRouteReuseStrategy implements RouteReuseStrategy {
retrieve(route: ActivatedRouteSnapshot): DetachedRouteHandle | null {
// Returns the stored route handle for reattachment
const key = this.getRouteKey(route);
- return route.data['reuse'] === true ? this.handlers.get(key) ?? null : null;
+ return route.data['reuse'] === true ? (this.handlers.get(key) ?? null) : null;
}
shouldReuseRoute(future: ActivatedRouteSnapshot, curr: ActivatedRouteSnapshot): boolean {
@@ -203,8 +217,79 @@ export class CustomRouteReuseStrategy implements RouteReuseStrategy {
}
```
+### Manually destroying detached route handles
+
+When implementing a custom `RouteReuseStrategy`, you may need to manually destroy a `DetachedRouteHandle` if you decide to discard it without reattaching it. For example, if your strategy has a cache size limit or expires handles after a certain time, you must ensure the component and its state are properly destroyed to avoid memory leaks.
+
+Since `DetachedRouteHandle` is an opaque type, you cannot call a destroy method directly on it. Instead, use the `destroyDetachedRouteHandle` function provided by the Router.
+
+```ts
+import { destroyDetachedRouteHandle } from '@angular/router';
+
+// ... inside your strategy
+if (this.handles.size > MAX_CACHE_SIZE) {
+ const handle = this.handles.get(oldestKey);
+ if (handle) {
+ destroyDetachedRouteHandle(handle);
+ this.handles.delete(oldestKey);
+ }
+}
+```
+
NOTE: Avoid using the route path as the key when `canMatch` guards are involved, as it may lead to duplicate entries.
+### (Experimental) Automatic cleanup of unused route injectors
+
+By default, Angular does not destroy the injectors of detached routes, even if they are no longer stored by the `RouteReuseStrategy`. This is primarily because this level of memory management is not commonly needed for most applications.
+
+To enable automatic cleanup of unused route injectors, you can use the `withExperimentalAutoCleanupInjectors` feature in your router configuration. This feature checks which routes are currently stored by the strategy after navigations and destroys the injectors of any detached routes that are not currently stored by the reuse strategy.
+
+```ts
+import { provideRouter, withExperimentalAutoCleanupInjectors } from '@angular/router';
+
+export const appConfig: ApplicationConfig = {
+ providers: [
+ provideRouter(routes, withExperimentalAutoCleanupInjectors())
+ ]
+};
+```
+
+If you do not provide a custom `RouteReuseStrategy` or your custom strategy extends `BaseRouteReuseStrategy`, injectors will now be destroyed when the route is inactive.
+
+#### Cleanup with a custom `RouteReuseStrategy`
+
+If your application uses a custom `RouteReuseStrategy` _and_ the strategy does not extend `BaseRouteReuseStrategy`, you must implement `shouldDestroyInjector` to tell the router which routes should have their injectors destroyed:
+
+```ts
+@Injectable()
+export class CustomRouteReuseStrategy implements RouteReuseStrategy {
+ // ... other methods
+
+ shouldDestroyInjector(route: Route): boolean {
+ return !route.data['retainInjector'];
+ }
+}
+```
+
+If your strategy ever stores a `DetachedRouteHandle`, you will also need to tell the Router about these so it does not destroy any injectors needed by that detached handle:
+
+```ts
+@Injectable()
+export class CustomRouteReuseStrategy implements RouteReuseStrategy {
+ private readonly handles = new Map();
+
+ store(route: ActivatedRouteSnapshot, handle: DetachedRouteHandle | null) {
+ this.handles.set(route.routeConfig!, handle);
+ }
+
+ retrieveStoredRouteHandles(): DetachedRouteHandle {
+ return Array.from(this.handles.values());
+ }
+
+ // ... other methods
+}
+```
+
### Configuring a route to use a custom route reuse strategy
Routes can opt into reuse behavior through route configuration metadata. This approach keeps the reuse logic separate from component code, making it easy to adjust behavior without modifying components:
@@ -214,7 +299,7 @@ export const routes: Routes = [
{
path: 'products',
component: ProductListComponent,
- data: { reuse: true } // Component state persists across navigations
+ data: {reuse: true}, // Component state persists across navigations
},
{
path: 'products/:id',
@@ -224,8 +309,8 @@ export const routes: Routes = [
{
path: 'search',
component: SearchComponent,
- data: { reuse: true } // Preserves search results and filter state
- }
+ data: {reuse: true}, // Preserves search results and filter state
+ },
];
```
@@ -235,8 +320,8 @@ You can also configure a custom route reuse strategy at the application level th
export const appConfig: ApplicationConfig = {
providers: [
provideRouter(routes),
- { provide: RouteReuseStrategy, useClass: CustomRouteReuseStrategy }
- ]
+ {provide: RouteReuseStrategy, useClass: CustomRouteReuseStrategy},
+ ],
};
```
@@ -256,17 +341,12 @@ Angular provides two preloading strategies out of the box:
The `PreloadAllModules` strategy can be configured as follows:
```ts
-import { ApplicationConfig } from '@angular/core';
-import { provideRouter, withPreloading, PreloadAllModules } from '@angular/router';
-import { routes } from './app.routes';
+import {ApplicationConfig} from '@angular/core';
+import {provideRouter, withPreloading, PreloadAllModules} from '@angular/router';
+import {routes} from './app.routes';
export const appConfig: ApplicationConfig = {
- providers: [
- provideRouter(
- routes,
- withPreloading(PreloadAllModules)
- )
- ]
+ providers: [provideRouter(routes, withPreloading(PreloadAllModules))],
};
```
@@ -277,10 +357,10 @@ The `PreloadAllModules` strategy works well for small to medium applications whe
Custom preloading strategies implement the `PreloadingStrategy` interface, which requires a single `preload` method. This method receives the route configuration and a function that triggers the actual module load. The strategy returns an Observable that emits when preloading completes or an empty Observable to skip preloading:
```ts
-import { Injectable } from '@angular/core';
-import { PreloadingStrategy, Route } from '@angular/router';
-import { Observable, of, timer } from 'rxjs';
-import { mergeMap } from 'rxjs/operators';
+import {Injectable} from '@angular/core';
+import {PreloadingStrategy, Route} from '@angular/router';
+import {Observable, of, timer} from 'rxjs';
+import {mergeMap} from 'rxjs/operators';
@Injectable()
export class SelectivePreloadingStrategy implements PreloadingStrategy {
@@ -297,24 +377,24 @@ export class SelectivePreloadingStrategy implements PreloadingStrategy {
This selective strategy checks route metadata to determine preloading behavior. Routes can opt into preloading through their configuration:
```ts
-import { Routes } from '@angular/router';
+import {Routes} from '@angular/router';
export const routes: Routes = [
{
path: 'dashboard',
loadChildren: () => import('./dashboard/dashboard.routes'),
- data: { preload: true } // Preload immediately after initial navigation
+ data: {preload: true}, // Preload immediately after initial navigation
},
{
path: 'reports',
loadChildren: () => import('./reports/reports.routes'),
- data: { preload: false } // Only load when user navigates to reports
+ data: {preload: false}, // Only load when user navigates to reports
},
{
path: 'admin',
- loadChildren: () => import('./admin/admin.routes')
+ loadChildren: () => import('./admin/admin.routes'),
// No preload flag - won't be preloaded
- }
+ },
];
```
@@ -337,15 +417,14 @@ The `UrlHandlingStrategy` class gives you control over this boundary between Ang
Custom URL handling strategies extend the `UrlHandlingStrategy` class and implement three methods. The `shouldProcessUrl` method determines whether Angular should handle a given URL, `extract` returns the portion of the URL that Angular should process, and `merge` combines the URL fragment with the rest of the URL:
```ts
-import { Injectable } from '@angular/core';
-import { UrlHandlingStrategy, UrlTree } from '@angular/router';
+import {Injectable} from '@angular/core';
+import {UrlHandlingStrategy, UrlTree} from '@angular/router';
@Injectable()
export class CustomUrlHandlingStrategy implements UrlHandlingStrategy {
shouldProcessUrl(url: UrlTree): boolean {
// Only handle URLs that start with /app or /admin
- return url.toString().startsWith('/app') ||
- url.toString().startsWith('/admin');
+ return url.toString().startsWith('/app') || url.toString().startsWith('/admin');
}
extract(url: UrlTree): UrlTree {
@@ -367,15 +446,15 @@ This strategy creates clear boundaries in the URL space. Angular handles `/app`
You can register a custom strategy through Angular's dependency injection system:
```ts
-import { ApplicationConfig } from '@angular/core';
-import { provideRouter } from '@angular/router';
-import { UrlHandlingStrategy } from '@angular/router';
+import {ApplicationConfig} from '@angular/core';
+import {provideRouter} from '@angular/router';
+import {UrlHandlingStrategy} from '@angular/router';
export const appConfig: ApplicationConfig = {
providers: [
provideRouter(routes),
- { provide: UrlHandlingStrategy, useClass: CustomUrlHandlingStrategy }
- ]
+ {provide: UrlHandlingStrategy, useClass: CustomUrlHandlingStrategy},
+ ],
};
```
@@ -392,20 +471,20 @@ The router evaluates custom matchers during the route matching phase, before pat
A custom matcher is a function that receives URL segments and returns either a match result with consumed segments and parameters, or null to indicate no match. The matcher function runs before Angular evaluates the route's path property:
```ts
-import { Route, UrlSegment, UrlSegmentGroup, UrlMatchResult } from '@angular/router';
+import {Route, UrlSegment, UrlSegmentGroup, UrlMatchResult} from '@angular/router';
export function customMatcher(
segments: UrlSegment[],
group: UrlSegmentGroup,
- route: Route
+ route: Route,
): UrlMatchResult | null {
// Matching logic here
if (matchSuccessful) {
return {
consumed: segments,
posParams: {
- paramName: new UrlSegment('paramValue', {})
- }
+ paramName: new UrlSegment('paramValue', {}),
+ },
};
}
return null;
@@ -417,17 +496,17 @@ export function customMatcher(
Consider an API documentation site that needs to route based on version numbers in the URL. Different versions might have different component structures or feature sets:
```ts
-import { Routes, UrlSegment, UrlMatchResult } from '@angular/router';
+import {Routes, UrlSegment, UrlMatchResult} from '@angular/router';
export function versionMatcher(segments: UrlSegment[]): UrlMatchResult | null {
// Match patterns like /v1/docs, /v2.1/docs, /v3.0.1/docs
if (segments.length >= 2 && segments[0].path.match(/^v\d+(\.\d+)*$/)) {
return {
- consumed: segments.slice(0, 2), // Consume version and 'docs'
+ consumed: segments.slice(0, 2), // Consume version and 'docs'
posParams: {
- version: segments[0], // Make version available as a parameter
- section: segments[1] // Make section available too
- }
+ version: segments[0], // Make version available as a parameter
+ section: segments[1], // Make section available too
+ },
};
}
return null;
@@ -437,12 +516,12 @@ export function versionMatcher(segments: UrlSegment[]): UrlMatchResult | null {
export const routes: Routes = [
{
matcher: versionMatcher,
- component: DocumentationComponent
+ component: DocumentationComponent,
},
{
path: 'latest/docs',
- redirectTo: 'v3/docs'
- }
+ redirectTo: 'v3/docs',
+ },
];
```
@@ -505,16 +584,16 @@ export function localeMatcher(segments: UrlSegment[]): UrlMatchResult | null {
return {
consumed: [segments[0]],
posParams: {
- locale: segments[0]
- }
+ locale: segments[0],
+ },
};
} else {
// No locale prefix, use default locale
return {
- consumed: [], // Don't consume any segments
+ consumed: [], // Don't consume any segments
posParams: {
- locale: new UrlSegment('en', {})
- }
+ locale: new UrlSegment('en', {}),
+ },
};
}
}
@@ -539,8 +618,8 @@ export function productMatcher(segments: UrlSegment[]): UrlMatchResult | null {
consumed: [segments[0]],
posParams: {
productType: new UrlSegment('book', {}),
- identifier: new UrlSegment(firstSegment.substring(5), {})
- }
+ identifier: new UrlSegment(firstSegment.substring(5), {}),
+ },
};
}
@@ -550,8 +629,8 @@ export function productMatcher(segments: UrlSegment[]): UrlMatchResult | null {
consumed: segments.slice(0, 2),
posParams: {
productType: new UrlSegment('electronics', {}),
- identifier: segments[1]
- }
+ identifier: segments[1],
+ },
};
}
@@ -562,8 +641,8 @@ export function productMatcher(segments: UrlSegment[]): UrlMatchResult | null {
posParams: {
productType: new UrlSegment('clothing', {}),
brand: segments[1],
- identifier: segments[2]
- }
+ identifier: segments[2],
+ },
};
}
diff --git a/adev-ja/src/content/guide/routing/customizing-route-behavior.md b/adev-ja/src/content/guide/routing/customizing-route-behavior.md
index bf8deb1767..aae7263fbe 100644
--- a/adev-ja/src/content/guide/routing/customizing-route-behavior.md
+++ b/adev-ja/src/content/guide/routing/customizing-route-behavior.md
@@ -24,7 +24,7 @@ NOTE: カスタムストラテジーを実装する前に、デフォルトの
この設定は、アプリケーションが`urlUpdateStrategy: 'eager'`を使用している場合や、ガードがブラウザによって開始された`popstate`ナビゲーションを頻繁にキャンセルする場合に最も役立ちます。
```ts
-provideRouter(routes, withRouterConfig({ canceledNavigationResolution: 'computed' }));
+provideRouter(routes, withRouterConfig({canceledNavigationResolution: 'computed'}));
```
### 同じURLへのナビゲーションへの対応 {#react-to-same-url-navigations}
@@ -34,13 +34,13 @@ provideRouter(routes, withRouterConfig({ canceledNavigationResolution: 'computed
これは、URLが変更されない場合でも、リストフィルター、左側のナビゲーション項目、または更新ボタンを繰り返しクリックして新しいデータ取得をトリガーしたい場合に便利です。
```ts
-provideRouter(routes, withRouterConfig({ onSameUrlNavigation: 'reload' }));
+provideRouter(routes, withRouterConfig({onSameUrlNavigation: 'reload'}));
```
グローバルにではなく、個々のナビゲーションでこの動作を制御できます。これにより、特定のユースケースに対してリロード動作を選択的に有効にしながら、デフォルトの`'ignore'`を維持できます。
```ts
-router.navigate(['/some-path'], { onSameUrlNavigation: 'reload' });
+router.navigate(['/some-path'], {onSameUrlNavigation: 'reload'});
```
### パラメータ継承の制御 {#control-parameter-inheritance}
@@ -50,7 +50,7 @@ router.navigate(['/some-path'], { onSameUrlNavigation: 'reload' });
デフォルトの`'emptyOnly'`では、子ルートはパスが空の場合、または親がコンポーネントを宣言していない場合にのみパラメータを継承します。
```ts
-provideRouter(routes, withRouterConfig({ paramsInheritanceStrategy: 'always' }));
+provideRouter(routes, withRouterConfig({paramsInheritanceStrategy: 'always'}));
```
```ts
@@ -65,17 +65,19 @@ export const routes: Routes = [
children: [
{
path: 'customers/:customerId',
- component: Customer
- }
- ]
- }
- ]
- }
+ component: Customer,
+ },
+ ],
+ },
+ ],
+ },
];
```
```ts
-@Component({ /* ... */})
+@Component({
+ /* ... */
+})
export class CustomerComponent {
private route = inject(ActivatedRoute);
@@ -85,10 +87,16 @@ export class CustomerComponent {
}
```
-`'always'`を使用すると、マトリックスパラメータ、ルートデータ、および解決された値がルートツリーのさらに下で利用可能になります。これは、`/org/:orgId/projects/:projectId/customers/:customerId`のような機能領域間でコンテキスト識別子を共有する場合に便利です。
+`'always'`を使用すると、マトリックスパラメータ、ルートデータ、および解決された値がルートツリーのさらに下で利用可能になります。これは、次のような機能領域間でコンテキスト識別子を共有する場合に便利です:
+
+```text {hideCopy}
+/org/:orgId/projects/:projectId/customers/:customerId
+```
```ts
-@Component({ /* ... */})
+@Component({
+ /* ... */
+})
export class CustomerComponent {
private route = inject(ActivatedRoute);
@@ -106,7 +114,7 @@ export class CustomerComponent {
分析パイプラインが、ガードによってブロックされた場合でも試行されたルートを確認する必要がある場合にこれを検討してください。
```ts
-provideRouter(routes, withRouterConfig({ urlUpdateStrategy: 'eager' }));
+provideRouter(routes, withRouterConfig({urlUpdateStrategy: 'eager'}));
```
### デフォルトのクエリパラメータ処理の選択 {#choose-default-query-parameter-handling}
@@ -114,7 +122,7 @@ provideRouter(routes, withRouterConfig({ urlUpdateStrategy: 'eager' }));
`defaultQueryParamsHandling`は、呼び出しが`queryParamsHandling`を指定しない場合の`Router.createUrlTree`のフォールバック動作を設定します。`'replace'`はデフォルトで、既存のクエリ文字列を置き換えます。`'merge'`は提供された値を現在の値と結合し、`'preserve'`は明示的に新しいクエリパラメータを指定しない限り、既存のクエリパラメータを保持します。
```ts
-provideRouter(routes, withRouterConfig({ defaultQueryParamsHandling: 'merge' }));
+provideRouter(routes, withRouterConfig({defaultQueryParamsHandling: 'merge'}));
```
これは、追加のパラメータが提供されたときに既存のフィルターを自動的に保持するために、検索およびフィルターページで特に役立ちます。
@@ -147,21 +155,27 @@ Angularの`RouteReuseStrategy`クラスを使用すると、「デタッチさ
「デタッチされたルートハンドル」は、Angularがコンポーネントインスタンスとそのビュー階層全体を保存する方法です。ルートがデタッチされると、Angularはコンポーネントインスタンス、その子コンポーネント、および関連するすべての状態をメモリに保持します。この保持された状態は、後でそのルートに戻ったときに再アタッチできます。
-`RouteReuseStrategy`クラスは、ルートコンポーネントのライフサイクルを制御する5つのメソッドを提供します:
+`RouteReuseStrategy`クラスは、ルートコンポーネントのライフサイクルを制御する次のメソッドを提供します:
-| メソッド | 説明 |
-| -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
-| [`shouldDetach`](api/router/RouteReuseStrategy#shouldDetach) | ルートから離れるときに、後で再利用するためにルートを保存すべきかどうかを決定します |
-| [`store`](api/router/RouteReuseStrategy#store) | `shouldDetach`がtrueを返した場合に、デタッチされたルートハンドルを保存します |
-| [`shouldAttach`](api/router/RouteReuseStrategy#shouldAttach) | 保存されたルートにナビゲートするときに、それを再アタッチすべきかどうかを決定します |
-| [`retrieve`](api/router/RouteReuseStrategy#retrieve) | 以前に保存されたルートハンドルを再アタッチのために返します |
-| [`shouldReuseRoute`](api/router/RouteReuseStrategy#shouldReuseRoute) | ナビゲーション中に現在のルートインスタンスを破棄する代わりに、ルーターが再利用すべきかどうかを決定します |
+| メソッド | 説明 |
+| ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- |
+| [`shouldDetach`](api/router/RouteReuseStrategy#shouldDetach) | ルートから離れるときに、後で再利用するためにルートを保存すべきかどうかを決定します |
+| [`store`](api/router/RouteReuseStrategy#store) | `shouldDetach`がtrueを返した場合に、デタッチされたルートハンドルを保存します |
+| [`shouldAttach`](api/router/RouteReuseStrategy#shouldAttach) | 保存されたルートにナビゲートするときに、それを再アタッチすべきかどうかを決定します |
+| [`retrieve`](api/router/RouteReuseStrategy#retrieve) | 以前に保存されたルートハンドルを再アタッチのために返します |
+| [`shouldReuseRoute`](api/router/RouteReuseStrategy#shouldReuseRoute) | ナビゲーション中に現在のルートインスタンスを破棄する代わりに、ルーターが再利用すべきかどうかを決定します |
+| [`shouldDestroyInjector`](api/router/RouteReuseStrategy#shouldDestroyInjector) | (実験的) ルーターが、保存されなくなったデタッチされたルートのインジェクターを破棄すべきかどうかを決定します |
次の例は、ルートメタデータに基づいてコンポーネントの状態を選択的に保持するカスタムルート再利用戦略を示しています:
```ts
-import { RouteReuseStrategy, Route, ActivatedRouteSnapshot, DetachedRouteHandle } from '@angular/router';
-import { Injectable } from '@angular/core';
+import {
+ RouteReuseStrategy,
+ Route,
+ ActivatedRouteSnapshot,
+ DetachedRouteHandle,
+} from '@angular/router';
+import {Injectable} from '@angular/core';
@Injectable()
export class CustomRouteReuseStrategy implements RouteReuseStrategy {
@@ -189,7 +203,7 @@ export class CustomRouteReuseStrategy implements RouteReuseStrategy {
retrieve(route: ActivatedRouteSnapshot): DetachedRouteHandle | null {
// Returns the stored route handle for reattachment
const key = this.getRouteKey(route);
- return route.data['reuse'] === true ? this.handlers.get(key) ?? null : null;
+ return route.data['reuse'] === true ? (this.handlers.get(key) ?? null) : null;
}
shouldReuseRoute(future: ActivatedRouteSnapshot, curr: ActivatedRouteSnapshot): boolean {
@@ -203,8 +217,79 @@ export class CustomRouteReuseStrategy implements RouteReuseStrategy {
}
```
+### デタッチされたルートハンドルを手動で破棄する {#manually-destroying-detached-route-handles}
+
+カスタム`RouteReuseStrategy`を実装する際、再アタッチせずにそれを破棄することにした場合、`DetachedRouteHandle`を手動で破棄する必要がある場合があります。たとえば、ストラテジーにキャッシュサイズの制限がある場合や、一定時間後にハンドルの有効期限が切れる場合、メモリリークを防ぐために、コンポーネントとその状態が適切に破棄されていることを確認する必要があります。
+
+`DetachedRouteHandle`は不透明な型であるため、それに対して直接破棄メソッドを呼び出すことはできません。代わりに、ルーターが提供する`destroyDetachedRouteHandle`関数を使用します。
+
+```ts
+import {destroyDetachedRouteHandle} from '@angular/router';
+
+// ... inside your strategy
+if (this.handles.size > MAX_CACHE_SIZE) {
+ const handle = this.handles.get(oldestKey);
+ if (handle) {
+ destroyDetachedRouteHandle(handle);
+ this.handles.delete(oldestKey);
+ }
+}
+```
+
NOTE: `canMatch`ガードが関与している場合、重複したエントリにつながる可能性があるため、キーとしてルートパスを使用することは避けてください。
+### (実験的) 未使用のルートインジェクターの自動クリーンアップ {#experimental-automatic-cleanup-of-unused-route-injectors}
+
+デフォルトでは、Angularは、`RouteReuseStrategy`によって保存されなくなった場合でも、デタッチされたルートのインジェクターを破棄しません。これは主に、このレベルのメモリ管理がほとんどのアプリケーションで一般的に必要とされていないためです。
+
+未使用のルートインジェクターの自動クリーンアップを有効にするには、ルーター設定で`withExperimentalAutoCleanupInjectors`機能を使用できます。この機能は、ナビゲーション後に現在ストラテジーによって保存されているルートを確認し、現在の再利用戦略によって保存されていないデタッチされたルートのインジェクターを破棄します。
+
+```ts
+import {provideRouter, withExperimentalAutoCleanupInjectors} from '@angular/router';
+
+export const appConfig: ApplicationConfig = {
+ providers: [
+ provideRouter(routes, withExperimentalAutoCleanupInjectors())
+ ]
+};
+```
+
+カスタム`RouteReuseStrategy`を提供しない場合、またはカスタム戦略が`BaseRouteReuseStrategy`を拡張している場合、ルートが非アクティブになったときにインジェクターが破棄されるようになります。
+
+#### カスタム`RouteReuseStrategy`を使用したクリーンアップ {#cleanup-with-a-custom-routereusestrategy}
+
+アプリケーションがカスタム`RouteReuseStrategy`を使用しており、_かつ_そのストラテジーが`BaseRouteReuseStrategy`を拡張していない場合、どのルートがインジェクターを破棄すべきかをルーターに伝えるために`shouldDestroyInjector`を実装する必要があります:
+
+```ts
+@Injectable()
+export class CustomRouteReuseStrategy implements RouteReuseStrategy {
+ // ... other methods
+
+ shouldDestroyInjector(route: Route): boolean {
+ return !route.data['retainInjector'];
+ }
+}
+```
+
+ストラテジーが`DetachedRouteHandle`を保存する場合、そのデタッチされたハンドルが必要とするインジェクターをルーターが破棄しないように、これらについてもルーターに伝える必要があります:
+
+```ts
+@Injectable()
+export class CustomRouteReuseStrategy implements RouteReuseStrategy {
+ private readonly handles = new Map();
+
+ store(route: ActivatedRouteSnapshot, handle: DetachedRouteHandle | null) {
+ this.handles.set(route.routeConfig!, handle);
+ }
+
+ retrieveStoredRouteHandles(): DetachedRouteHandle {
+ return Array.from(this.handles.values());
+ }
+
+ // ... other methods
+}
+```
+
### カスタムルート再利用戦略を使用するようにルートを設定する {#configuring-a-route-to-use-a-custom-route-reuse-strategy}
ルートは、ルート設定メタデータを通じて再利用の動作をオプトインできます。このアプローチでは、再利用ロジックをコンポーネントのコードから分離し、コンポーネントを変更することなく動作を簡単に調整できるようにします:
@@ -214,7 +299,7 @@ export const routes: Routes = [
{
path: 'products',
component: ProductListComponent,
- data: { reuse: true } // Component state persists across navigations
+ data: {reuse: true}, // Component state persists across navigations
},
{
path: 'products/:id',
@@ -224,8 +309,8 @@ export const routes: Routes = [
{
path: 'search',
component: SearchComponent,
- data: { reuse: true } // Preserves search results and filter state
- }
+ data: {reuse: true}, // Preserves search results and filter state
+ },
];
```
@@ -235,8 +320,8 @@ export const routes: Routes = [
export const appConfig: ApplicationConfig = {
providers: [
provideRouter(routes),
- { provide: RouteReuseStrategy, useClass: CustomRouteReuseStrategy }
- ]
+ {provide: RouteReuseStrategy, useClass: CustomRouteReuseStrategy},
+ ],
};
```
@@ -256,17 +341,12 @@ Angularは、標準で2つのプリロード戦略を提供しています:
`PreloadAllModules`戦略は次のように設定できます:
```ts
-import { ApplicationConfig } from '@angular/core';
-import { provideRouter, withPreloading, PreloadAllModules } from '@angular/router';
-import { routes } from './app.routes';
+import {ApplicationConfig} from '@angular/core';
+import {provideRouter, withPreloading, PreloadAllModules} from '@angular/router';
+import {routes} from './app.routes';
export const appConfig: ApplicationConfig = {
- providers: [
- provideRouter(
- routes,
- withPreloading(PreloadAllModules)
- )
- ]
+ providers: [provideRouter(routes, withPreloading(PreloadAllModules))],
};
```
@@ -277,10 +357,10 @@ export const appConfig: ApplicationConfig = {
カスタムプリロード戦略は`PreloadingStrategy`インターフェースを実装します。これには単一の`preload`メソッドが必要です。このメソッドは、ルート設定と、実際のモジュール読み込みをトリガーする関数を受け取ります。この戦略は、プリロードが完了したときにemitするObservableか、プリロードをスキップするための空のObservableを返します:
```ts
-import { Injectable } from '@angular/core';
-import { PreloadingStrategy, Route } from '@angular/router';
-import { Observable, of, timer } from 'rxjs';
-import { mergeMap } from 'rxjs/operators';
+import {Injectable} from '@angular/core';
+import {PreloadingStrategy, Route} from '@angular/router';
+import {Observable, of, timer} from 'rxjs';
+import {mergeMap} from 'rxjs/operators';
@Injectable()
export class SelectivePreloadingStrategy implements PreloadingStrategy {
@@ -297,24 +377,24 @@ export class SelectivePreloadingStrategy implements PreloadingStrategy {
この選択的戦略は、ルートメタデータをチェックしてプリロードの動作を決定します。ルートは、その設定を通じてプリロードをオプトインできます:
```ts
-import { Routes } from '@angular/router';
+import {Routes} from '@angular/router';
export const routes: Routes = [
{
path: 'dashboard',
loadChildren: () => import('./dashboard/dashboard.routes'),
- data: { preload: true } // Preload immediately after initial navigation
+ data: {preload: true}, // Preload immediately after initial navigation
},
{
path: 'reports',
loadChildren: () => import('./reports/reports.routes'),
- data: { preload: false } // Only load when user navigates to reports
+ data: {preload: false}, // Only load when user navigates to reports
},
{
path: 'admin',
- loadChildren: () => import('./admin/admin.routes')
+ loadChildren: () => import('./admin/admin.routes'),
// No preload flag - won't be preloaded
- }
+ },
];
```
@@ -337,15 +417,14 @@ URLハンドリングストラテジーは、AngularルーターがどのURLを
カスタムURLハンドリングストラテジーは`UrlHandlingStrategy`クラスを拡張し、3つのメソッドを実装します。`shouldProcessUrl`メソッドはAngularが特定のURLを処理すべきかどうかを判断し、`extract`はAngularが処理すべきURLの部分を返し、`merge`はURLフラグメントをURLの残りの部分と結合します:
```ts
-import { Injectable } from '@angular/core';
-import { UrlHandlingStrategy, UrlTree } from '@angular/router';
+import {Injectable} from '@angular/core';
+import {UrlHandlingStrategy, UrlTree} from '@angular/router';
@Injectable()
export class CustomUrlHandlingStrategy implements UrlHandlingStrategy {
shouldProcessUrl(url: UrlTree): boolean {
// Only handle URLs that start with /app or /admin
- return url.toString().startsWith('/app') ||
- url.toString().startsWith('/admin');
+ return url.toString().startsWith('/app') || url.toString().startsWith('/admin');
}
extract(url: UrlTree): UrlTree {
@@ -367,15 +446,15 @@ export class CustomUrlHandlingStrategy implements UrlHandlingStrategy {
Angularの依存性の注入システムを通じて、カスタムストラテジーを登録できます:
```ts
-import { ApplicationConfig } from '@angular/core';
-import { provideRouter } from '@angular/router';
-import { UrlHandlingStrategy } from '@angular/router';
+import {ApplicationConfig} from '@angular/core';
+import {provideRouter} from '@angular/router';
+import {UrlHandlingStrategy} from '@angular/router';
export const appConfig: ApplicationConfig = {
providers: [
provideRouter(routes),
- { provide: UrlHandlingStrategy, useClass: CustomUrlHandlingStrategy }
- ]
+ {provide: UrlHandlingStrategy, useClass: CustomUrlHandlingStrategy},
+ ],
};
```
@@ -392,20 +471,20 @@ export const appConfig: ApplicationConfig = {
カスタムマッチャーは、URLセグメントを受け取り、消費されたセグメントとパラメーターを含むマッチ結果、またはマッチしなかったことを示すnullを返す関数です。このマッチャー関数は、Angularがルートのpathプロパティを評価する前に実行されます:
```ts
-import { Route, UrlSegment, UrlSegmentGroup, UrlMatchResult } from '@angular/router';
+import {Route, UrlSegment, UrlSegmentGroup, UrlMatchResult} from '@angular/router';
export function customMatcher(
segments: UrlSegment[],
group: UrlSegmentGroup,
- route: Route
+ route: Route,
): UrlMatchResult | null {
// Matching logic here
if (matchSuccessful) {
return {
consumed: segments,
posParams: {
- paramName: new UrlSegment('paramValue', {})
- }
+ paramName: new UrlSegment('paramValue', {}),
+ },
};
}
return null;
@@ -417,17 +496,17 @@ export function customMatcher(
URL内のバージョン番号に基づいてルーティングする必要があるAPIドキュメントサイトを考えてみましょう。バージョンが異なれば、コンポーネントの構造や機能セットも異なる場合があります:
```ts
-import { Routes, UrlSegment, UrlMatchResult } from '@angular/router';
+import {Routes, UrlSegment, UrlMatchResult} from '@angular/router';
export function versionMatcher(segments: UrlSegment[]): UrlMatchResult | null {
// Match patterns like /v1/docs, /v2.1/docs, /v3.0.1/docs
if (segments.length >= 2 && segments[0].path.match(/^v\d+(\.\d+)*$/)) {
return {
- consumed: segments.slice(0, 2), // Consume version and 'docs'
+ consumed: segments.slice(0, 2), // Consume version and 'docs'
posParams: {
- version: segments[0], // Make version available as a parameter
- section: segments[1] // Make section available too
- }
+ version: segments[0], // Make version available as a parameter
+ section: segments[1], // Make section available too
+ },
};
}
return null;
@@ -437,12 +516,12 @@ export function versionMatcher(segments: UrlSegment[]): UrlMatchResult | null {
export const routes: Routes = [
{
matcher: versionMatcher,
- component: DocumentationComponent
+ component: DocumentationComponent,
},
{
path: 'latest/docs',
- redirectTo: 'v3/docs'
- }
+ redirectTo: 'v3/docs',
+ },
];
```
@@ -505,16 +584,16 @@ export function localeMatcher(segments: UrlSegment[]): UrlMatchResult | null {
return {
consumed: [segments[0]],
posParams: {
- locale: segments[0]
- }
+ locale: segments[0],
+ },
};
} else {
// No locale prefix, use default locale
return {
- consumed: [], // Don't consume any segments
+ consumed: [], // Don't consume any segments
posParams: {
- locale: new UrlSegment('en', {})
- }
+ locale: new UrlSegment('en', {}),
+ },
};
}
}
@@ -539,8 +618,8 @@ export function productMatcher(segments: UrlSegment[]): UrlMatchResult | null {
consumed: [segments[0]],
posParams: {
productType: new UrlSegment('book', {}),
- identifier: new UrlSegment(firstSegment.substring(5), {})
- }
+ identifier: new UrlSegment(firstSegment.substring(5), {}),
+ },
};
}
@@ -550,8 +629,8 @@ export function productMatcher(segments: UrlSegment[]): UrlMatchResult | null {
consumed: segments.slice(0, 2),
posParams: {
productType: new UrlSegment('electronics', {}),
- identifier: segments[1]
- }
+ identifier: segments[1],
+ },
};
}
@@ -562,8 +641,8 @@ export function productMatcher(segments: UrlSegment[]): UrlMatchResult | null {
posParams: {
productType: new UrlSegment('clothing', {}),
brand: segments[1],
- identifier: segments[2]
- }
+ identifier: segments[2],
+ },
};
}
diff --git a/adev-ja/src/content/guide/routing/data-resolvers.en.md b/adev-ja/src/content/guide/routing/data-resolvers.en.md
index da83b8b1b2..11eb4d8a95 100644
--- a/adev-ja/src/content/guide/routing/data-resolvers.en.md
+++ b/adev-ja/src/content/guide/routing/data-resolvers.en.md
@@ -24,18 +24,24 @@ It receives the `ActivatedRouteSnapshot` and `RouterStateSnapshot` as parameters
Here is a resolver that gets the user information before rendering a route using the [`inject`](api/core/inject) function:
```ts
-import { inject } from '@angular/core';
-import { UserStore, SettingsStore } from './user-store';
-import type { ActivatedRouteSnapshot, ResolveFn, RouterStateSnapshot } from '@angular/router';
-import type { User, Settings } from './types';
-
-export const userResolver: ResolveFn = (route: ActivatedRouteSnapshot, state: RouterStateSnapshot) => {
+import {inject} from '@angular/core';
+import {UserStore, SettingsStore} from './user-store';
+import type {ActivatedRouteSnapshot, ResolveFn, RouterStateSnapshot} from '@angular/router';
+import type {User, Settings} from './types';
+
+export const userResolver: ResolveFn = (
+ route: ActivatedRouteSnapshot,
+ state: RouterStateSnapshot,
+) => {
const userStore = inject(UserStore);
const userId = route.paramMap.get('id')!;
return userStore.getUser(userId);
};
-export const settingsResolver: ResolveFn = (route: ActivatedRouteSnapshot, state: RouterStateSnapshot) => {
+export const settingsResolver: ResolveFn = (
+ route: ActivatedRouteSnapshot,
+ state: RouterStateSnapshot,
+) => {
const settingsStore = inject(SettingsStore);
const userId = route.paramMap.get('id')!;
return settingsStore.getUserSettings(userId);
@@ -47,7 +53,7 @@ export const settingsResolver: ResolveFn = (route: ActivatedRouteSnaps
When you want to add one or more data resolvers to a route, you can add it under the `resolve` key in the route configuration. The `Routes` type defines the structure for route configurations:
```ts
-import { Routes } from '@angular/router';
+import {Routes} from '@angular/router';
export const routes: Routes = [
{
@@ -55,9 +61,9 @@ export const routes: Routes = [
component: UserDetail,
resolve: {
user: userResolver,
- settings: settingsResolver
- }
- }
+ settings: settingsResolver,
+ },
+ },
];
```
@@ -95,14 +101,12 @@ export class UserDetail {
A different approach to accessing the resolved data is to use `withComponentInputBinding()` when configuring your router with `provideRouter`. This allows resolved data to be passed directly as component inputs:
```ts
-import { bootstrapApplication } from '@angular/platform-browser';
-import { provideRouter, withComponentInputBinding } from '@angular/router';
-import { routes } from './app.routes';
+import {bootstrapApplication} from '@angular/platform-browser';
+import {provideRouter, withComponentInputBinding} from '@angular/router';
+import {routes} from './app.routes';
bootstrapApplication(App, {
- providers: [
- provideRouter(routes, withComponentInputBinding())
- ]
+ providers: [provideRouter(routes, withComponentInputBinding())],
});
```
@@ -142,24 +146,27 @@ There are three primary ways to handle errors with data resolvers:
The [`withNavigationErrorHandler`](api/router/withNavigationErrorHandler) feature provides a centralized way to handle all navigation errors, including those from failed data resolvers. This approach keeps error handling logic in one place and prevents duplicate error handling code across resolvers.
```ts
-import { bootstrapApplication } from '@angular/platform-browser';
-import { provideRouter, withNavigationErrorHandler } from '@angular/router';
-import { inject } from '@angular/core';
-import { Router } from '@angular/router';
-import { routes } from './app.routes';
+import {bootstrapApplication} from '@angular/platform-browser';
+import {provideRouter, withNavigationErrorHandler} from '@angular/router';
+import {inject} from '@angular/core';
+import {Router} from '@angular/router';
+import {routes} from './app.routes';
bootstrapApplication(App, {
providers: [
- provideRouter(routes, withNavigationErrorHandler((error) => {
- const router = inject(Router);
+ provideRouter(
+ routes,
+ withNavigationErrorHandler((error) => {
+ const router = inject(Router);
- if (error?.message) {
- console.error('Navigation error occurred:', error.message)
- }
+ if (error?.message) {
+ console.error('Navigation error occurred:', error.message);
+ }
- router.navigate(['/error']);
- }))
- ]
+ router.navigate(['/error']);
+ }),
+ ),
+ ],
});
```
@@ -205,11 +212,11 @@ export class App {
map(event => {
if (event instanceof NavigationError) {
this.lastFailedUrl.set(event.url);
-
+
if (event.error) {
console.error('Navigation error', event.error)
}
-
+
return 'Navigation failed. Please try again.';
}
return '';
@@ -239,11 +246,11 @@ This approach is particularly useful when you need to:
Here's an updated example of the `userResolver` that logs the error and navigates back to the generic `/users` page using the `Router` service:
```ts
-import { inject } from '@angular/core';
-import { ResolveFn, RedirectCommand, Router } from '@angular/router';
-import { catchError, of, EMPTY } from 'rxjs';
-import { UserStore } from './user-store';
-import type { User } from './types';
+import {inject} from '@angular/core';
+import {ResolveFn, RedirectCommand, Router} from '@angular/router';
+import {catchError, of, EMPTY} from 'rxjs';
+import {UserStore} from './user-store';
+import type {User} from './types';
export const userResolver: ResolveFn = (route) => {
const userStore = inject(UserStore);
@@ -251,10 +258,10 @@ export const userResolver: ResolveFn = (route) => {
const userId = route.paramMap.get('id')!;
return userStore.getUser(userId).pipe(
- catchError(error => {
+ catchError((error) => {
console.error('Failed to load user:', error);
return of(new RedirectCommand(router.parseUrl('/users')));
- })
+ }),
);
};
```
@@ -270,8 +277,6 @@ To improve user experience during resolver execution, you can listen to router e
```angular-ts
import { Component, inject } from '@angular/core';
import { Router } from '@angular/router';
-import { toSignal } from '@angular/core/rxjs-interop';
-import { map } from 'rxjs';
@Component({
selector: 'app-root',
@@ -323,7 +328,7 @@ provideRouter([
resolve: {
posts: (route: ActivatedRouteSnapshot) => {
const postService = inject(PostService);
- const user = route.data['user'] as User; // parent data
+ const user = route.parent?.data['user'] as User; // parent data
const userId = user.id;
return postService.getPostByUser(userId);
},
diff --git a/adev-ja/src/content/guide/routing/data-resolvers.md b/adev-ja/src/content/guide/routing/data-resolvers.md
index c8bbddcad9..2ef9791434 100644
--- a/adev-ja/src/content/guide/routing/data-resolvers.md
+++ b/adev-ja/src/content/guide/routing/data-resolvers.md
@@ -24,18 +24,24 @@
以下は、[`inject`](api/core/inject)関数を使用してルートをレンダリングする前にユーザー情報を取得するリゾルバです。
```ts
-import { inject } from '@angular/core';
-import { UserStore, SettingsStore } from './user-store';
-import type { ActivatedRouteSnapshot, ResolveFn, RouterStateSnapshot } from '@angular/router';
-import type { User, Settings } from './types';
-
-export const userResolver: ResolveFn = (route: ActivatedRouteSnapshot, state: RouterStateSnapshot) => {
+import {inject} from '@angular/core';
+import {UserStore, SettingsStore} from './user-store';
+import type {ActivatedRouteSnapshot, ResolveFn, RouterStateSnapshot} from '@angular/router';
+import type {User, Settings} from './types';
+
+export const userResolver: ResolveFn = (
+ route: ActivatedRouteSnapshot,
+ state: RouterStateSnapshot,
+) => {
const userStore = inject(UserStore);
const userId = route.paramMap.get('id')!;
return userStore.getUser(userId);
};
-export const settingsResolver: ResolveFn = (route: ActivatedRouteSnapshot, state: RouterStateSnapshot) => {
+export const settingsResolver: ResolveFn = (
+ route: ActivatedRouteSnapshot,
+ state: RouterStateSnapshot,
+) => {
const settingsStore = inject(SettingsStore);
const userId = route.paramMap.get('id')!;
return settingsStore.getUserSettings(userId);
@@ -47,7 +53,7 @@ export const settingsResolver: ResolveFn = (route: ActivatedRouteSnaps
ルートに1つ以上のデータリゾルバーを追加したい場合は、ルート設定の`resolve`キーの下に追加できます。`Routes`型は、ルート設定の構造を定義します。
```ts
-import { Routes } from '@angular/router';
+import {Routes} from '@angular/router';
export const routes: Routes = [
{
@@ -55,9 +61,9 @@ export const routes: Routes = [
component: UserDetail,
resolve: {
user: userResolver,
- settings: settingsResolver
- }
- }
+ settings: settingsResolver,
+ },
+ },
];
```
@@ -95,14 +101,12 @@ export class UserDetail {
解決済みデータにアクセスする別のアプローチは、`provideRouter`でルーターを設定する際に`withComponentInputBinding()`を使用することです。これにより、解決済みデータをコンポーネントの入力として直接渡すことができます。
```ts
-import { bootstrapApplication } from '@angular/platform-browser';
-import { provideRouter, withComponentInputBinding } from '@angular/router';
-import { routes } from './app.routes';
+import {bootstrapApplication} from '@angular/platform-browser';
+import {provideRouter, withComponentInputBinding} from '@angular/router';
+import {routes} from './app.routes';
bootstrapApplication(App, {
- providers: [
- provideRouter(routes, withComponentInputBinding())
- ]
+ providers: [provideRouter(routes, withComponentInputBinding())],
});
```
@@ -142,24 +146,27 @@ export class UserDetail {
`withNavigationErrorHandler`機能は、失敗したデータリゾルバーからのエラーを含む、すべてのナビゲーションエラーを処理する一元的な方法を提供します。このアプローチにより、エラー処理ロジックが一箇所に保持され、リゾルバー間での重複したエラー処理コードが防止されます。
```ts
-import { bootstrapApplication } from '@angular/platform-browser';
-import { provideRouter, withNavigationErrorHandler } from '@angular/router';
-import { inject } from '@angular/core';
-import { Router } from '@angular/router';
-import { routes } from './app.routes';
+import {bootstrapApplication} from '@angular/platform-browser';
+import {provideRouter, withNavigationErrorHandler} from '@angular/router';
+import {inject} from '@angular/core';
+import {Router} from '@angular/router';
+import {routes} from './app.routes';
bootstrapApplication(App, {
providers: [
- provideRouter(routes, withNavigationErrorHandler((error) => {
- const router = inject(Router);
+ provideRouter(
+ routes,
+ withNavigationErrorHandler((error) => {
+ const router = inject(Router);
- if (error?.message) {
- console.error('Navigation error occurred:', error.message)
- }
+ if (error?.message) {
+ console.error('Navigation error occurred:', error.message);
+ }
- router.navigate(['/error']);
- }))
- ]
+ router.navigate(['/error']);
+ }),
+ ),
+ ],
});
```
@@ -239,11 +246,11 @@ export class App {
以下は、エラーをログに記録し、`Router`サービスを使用して汎用の`/users`ページにナビゲートし直す`userResolver`の更新された例です。
```ts
-import { inject } from '@angular/core';
-import { ResolveFn, RedirectCommand, Router } from '@angular/router';
-import { catchError, of, EMPTY } from 'rxjs';
-import { UserStore } from './user-store';
-import type { User } from './types';
+import {inject} from '@angular/core';
+import {ResolveFn, RedirectCommand, Router} from '@angular/router';
+import {catchError, of, EMPTY} from 'rxjs';
+import {UserStore} from './user-store';
+import type {User} from './types';
export const userResolver: ResolveFn = (route) => {
const userStore = inject(UserStore);
@@ -251,10 +258,10 @@ export const userResolver: ResolveFn = (route) => {
const userId = route.paramMap.get('id')!;
return userStore.getUser(userId).pipe(
- catchError(error => {
+ catchError((error) => {
console.error('Failed to load user:', error);
return of(new RedirectCommand(router.parseUrl('/users')));
- })
+ }),
);
};
```
@@ -270,8 +277,6 @@ export const userResolver: ResolveFn = (route) => {
```angular-ts
import { Component, inject } from '@angular/core';
import { Router } from '@angular/router';
-import { toSignal } from '@angular/core/rxjs-interop';
-import { map } from 'rxjs';
@Component({
selector: 'app-root',
@@ -323,7 +328,7 @@ provideRouter([
resolve: {
posts: (route: ActivatedRouteSnapshot) => {
const postService = inject(PostService);
- const user = route.data['user'] as User; // parent data
+ const user = route.parent?.data['user'] as User; // parent data
const userId = user.id;
return postService.getPostByUser(userId);
},
diff --git a/adev-ja/src/content/guide/routing/define-routes.en.md b/adev-ja/src/content/guide/routing/define-routes.en.md
index 1570aeb1fc..420e73976a 100644
--- a/adev-ja/src/content/guide/routing/define-routes.en.md
+++ b/adev-ja/src/content/guide/routing/define-routes.en.md
@@ -9,12 +9,12 @@ In Angular, a **route** is an object that defines which component should render
Here is a basic example of a route:
```ts
-import { AdminPage } from './app-admin/app-admin.component';
+import {AdminPage} from './app-admin/app-admin.component';
const adminPage = {
path: 'admin',
- component: AdminPage
-}
+ component: AdminPage,
+};
```
For this route, when a user visits the `/admin` path, the app will display the `AdminPage` component.
@@ -26,9 +26,9 @@ Most projects define routes in a separate file that contains `routes` in the fil
A collection of routes looks like this:
```ts
-import { Routes } from '@angular/router';
-import { HomePage } from './home-page/home-page.component';
-import { AdminPage } from './about-page/admin-page.component';
+import {Routes} from '@angular/router';
+import {HomePage} from './home-page/home-page.component';
+import {AdminPage} from './about-page/admin-page.component';
export const routes: Routes = [
{
@@ -51,16 +51,16 @@ When bootstrapping an Angular application without the Angular CLI, you can pass
Inside of the `providers` array, you can add the Angular router to your application by adding a `provideRouter` function call with your routes.
```ts
-import { ApplicationConfig } from '@angular/core';
-import { provideRouter } from '@angular/router';
+import {ApplicationConfig} from '@angular/core';
+import {provideRouter} from '@angular/router';
-import { routes } from './app.routes';
+import {routes} from './app.routes';
export const appConfig: ApplicationConfig = {
providers: [
provideRouter(routes),
// ...
- ]
+ ],
};
```
@@ -88,12 +88,10 @@ Learn more about [query parameters in Angular in this guide](/guide/routing/read
The following example displays a user profile component based on the user id passed in through the URL.
```ts
-import { Routes } from '@angular/router';
-import { UserProfile } from './user-profile/user-profile';
+import {Routes} from '@angular/router';
+import {UserProfile} from './user-profile/user-profile';
-const routes: Routes = [
- { path: 'user/:id', component: UserProfile }
-];
+const routes: Routes = [{path: 'user/:id', component: UserProfile}];
```
In this example, URLs such as `/user/leeroy` and `/user/jenkins` render the `UserProfile` component. This component can then read the `id` parameter and use it to perform additional work, such as fetching data. See [reading route state guide](/guide/routing/read-route-state) for details on reading route parameters.
@@ -108,13 +106,13 @@ Valid route parameter names must start with a letter (a-z, A-Z) and can only con
You can also define paths with multiple parameters:
```ts
-import { Routes } from '@angular/router';
-import { UserProfile } from './user-profile/user-profile.component';
-import { SocialMediaFeed } from './user-profile/social–media-feed.component';
+import {Routes} from '@angular/router';
+import {UserProfile} from './user-profile/user-profile.component';
+import {SocialMediaFeed} from './user-profile/social–media-feed.component';
const routes: Routes = [
- { path: 'user/:id/:social-media', component: SocialMediaFeed },
- { path: 'user/:id/', component: UserProfile },
+ {path: 'user/:id/:social-media', component: SocialMediaFeed},
+ {path: 'user/:id/', component: UserProfile},
];
```
@@ -129,14 +127,14 @@ When you need to catch all routes for a specific path, the solution is a wildcar
A common example is defining a Page Not Found component.
```ts
-import { Home } from './home/home.component';
-import { UserProfile } from './user-profile/user-profile.component';
-import { NotFound } from './not-found/not-found.component';
+import {Home} from './home/home.component';
+import {UserProfile} from './user-profile/user-profile.component';
+import {NotFound} from './not-found/not-found.component';
const routes: Routes = [
- { path: 'home', component: Home },
- { path: 'user/:id', component: UserProfile },
- { path: '**', component: NotFound }
+ {path: 'home', component: Home},
+ {path: 'user/:id', component: UserProfile},
+ {path: '**', component: NotFound},
];
```
@@ -152,11 +150,11 @@ The following example shows routes defined from most-specific to least specific:
```ts
const routes: Routes = [
- { path: '', component: HomeComponent }, // Empty path
- { path: 'users/new', component: NewUserComponent }, // Static, most specific
- { path: 'users/:id', component: UserDetailComponent }, // Dynamic
- { path: 'users', component: UsersComponent }, // Static, less specific
- { path: '**', component: NotFoundComponent } // Wildcard - always last
+ {path: '', component: HomeComponent}, // Empty path
+ {path: 'users/new', component: NewUserComponent}, // Static, most specific
+ {path: 'users/:id', component: UserDetailComponent}, // Dynamic
+ {path: 'users', component: UsersComponent}, // Static, less specific
+ {path: '**', component: NotFoundComponent}, // Wildcard - always last
];
```
@@ -168,12 +166,12 @@ If a user visits `/users/new`, Angular router would go through the following ste
1. Never reaches `users`
1. Never reaches `**`
-## Loading Route Component Strategies
+## Route Loading Strategies
-Understanding how and when components load in Angular routing is crucial for building responsive web applications. Angular offers two primary strategies to control component loading behavior:
+Understanding how and when routes and components load in Angular routing is crucial for building responsive web applications. Angular offers two primary strategies to control loading behavior:
-1. **Eagerly loaded**: Components that are loaded immediately
-2. **Lazily loaded**: Components loaded only when needed
+1. **Eagerly loaded**: Routes and components that are loaded immediately
+2. **Lazily loaded**: Routes and components loaded only when needed
Each approach offers distinct advantages for different scenarios.
@@ -182,50 +180,51 @@ Each approach offers distinct advantages for different scenarios.
When you define a route with the `component` property, the referenced component is eagerly loaded as part of the same JavaScript bundle as the route configuration.
```ts
-import { Routes } from "@angular/router";
-import { HomePage } from "./components/home/home-page"
-import { LoginPage } from "./components/auth/login-page"
+import {Routes} from '@angular/router';
+import {HomePage} from './components/home/home-page';
+import {LoginPage} from './components/auth/login-page';
export const routes: Routes = [
// HomePage and LoginPage are both directly referenced in this config,
// so their code is eagerly included in the same JavaScript bundle as this file.
{
- path: "",
- component: HomePage
+ path: '',
+ component: HomePage,
},
{
- path: "login",
- component: LoginPage
- }
-]
+ path: 'login',
+ component: LoginPage,
+ },
+];
```
Eagerly loading route components like this means that the browser has to download and parse all of the JavaScript for these components as part of your initial page load, but the components are available to Angular immediately.
While including more JavaScript in your initial page load leads to slower initial load times, this can lead to more seamless transitions as the user navigates through an application.
-### Lazily loaded components
+### Lazily loaded components and routes
-You can use the `loadComponent` property to lazily load the JavaScript for a route only at the point at which that route would become active.
+You can use the `loadComponent` property to lazily load the JavaScript for a component at the point at which that route would become active. The `loadChildren` property lazily loads child routes during route matching.
```ts
-import { Routes } from "@angular/router";
+import {Routes} from '@angular/router';
export const routes: Routes = [
- // The HomePage and LoginPage components are loaded lazily at the point at which
- // their corresponding routes become active.
{
path: 'login',
- loadComponent: () => import('./components/auth/login-page').then(m => m.LoginPage)
+ loadComponent: () => import('./components/auth/login-page'),
},
{
- path: '',
- loadComponent: () => import('./components/home/home-page').then(m => m.HomePage)
- }
-]
+ path: 'admin',
+ loadComponent: () => import('./admin/admin.component'),
+ loadChildren: () => import('./admin/admin.routes'),
+ },
+];
```
-The `loadComponent` property accepts a loader function that returns a Promise that resolves to an Angular component. In most cases, this function uses the standard [JavaScript dynamic import API](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import). You can, however, use any arbitrary async loader function.
+The `loadComponent` and `loadChildren` properties accept a loader function that returns a Promise that resolves to an Angular component or a set of routes respectively. In most cases, this function uses the standard [JavaScript dynamic import API](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import). You can, however, use any arbitrary async loader function.
+
+If the lazily loaded file uses a `default` export, you can return the `import()` promise directly without an additional `.then` call to select the exported class.
Lazily loading routes can significantly improve the load speed of your Angular application by removing large portions of JavaScript from the initial bundle. These portions of your code compile into separate JavaScript "chunks" that the router requests only when the user visits the corresponding route.
@@ -234,9 +233,9 @@ Lazily loading routes can significantly improve the load speed of your Angular a
The Router executes `loadComponent` and `loadChildren` within the **injection context of the current route**, allowing you to call [`inject`](/api/core/inject)inside these loader functions to access providers declared on that route, inherited from parent routes through hierarchical dependency injection, or available globally. This enables context-aware lazy loading.
```ts
-import { Routes } from '@angular/router';
-import { inject } from '@angular/core';
-import { FeatureFlags } from './feature-flags';
+import {Routes} from '@angular/router';
+import {inject} from '@angular/core';
+import {FeatureFlags} from './feature-flags';
export const routes: Routes = [
{
@@ -245,8 +244,8 @@ export const routes: Routes = [
loadComponent: () => {
const flags = inject(FeatureFlags);
return flags.isPremium
- ? import('./dashboard/premium-dashboard').then(m => m.PremiumDashboard)
- : import('./dashboard/basic-dashboard').then(m => m.BasicDashboard);
+ ? import('./dashboard/premium-dashboard')
+ : import('./dashboard/basic-dashboard');
},
},
];
@@ -265,7 +264,7 @@ NOTE: While lazy routes have the upfront performance benefit of reducing the amo
You can define a route that redirects to another route instead of rendering a component:
```ts
-import { BlogComponent } from './home/blog.component';
+import {BlogComponent} from './home/blog.component';
const routes: Routes = [
{
@@ -274,7 +273,7 @@ const routes: Routes = [
},
{
path: 'blog',
- component: BlogComponent
+ component: BlogComponent,
},
];
```
@@ -286,21 +285,21 @@ If you modify or remove a route, some users may still click on out-of-date links
You can associate a **title** with each route. Angular automatically updates the [page title](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/title) when a route activates. Always define appropriate page titles for your application, as these titles are necessary to create an accessible experience.
```ts
-import { Routes } from '@angular/router';
-import { HomeComponent } from './home/home.component';
-import { AboutComponent } from './about/about.component';
-import { ProductsComponent } from './products/products.component';
+import {Routes} from '@angular/router';
+import {HomeComponent} from './home/home.component';
+import {AboutComponent} from './about/about.component';
+import {ProductsComponent} from './products/products.component';
const routes: Routes = [
{
path: '',
component: HomeComponent,
- title: 'Home Page'
+ title: 'Home Page',
},
{
path: 'about',
component: AboutComponent,
- title: 'About Us'
+ title: 'About Us',
},
];
```
@@ -310,14 +309,12 @@ The page `title` property can be set dynamincally to a resolver function using [
```ts
const titleResolver: ResolveFn = (route) => route.queryParams['id'];
const routes: Routes = [
- ...
- {
+ ...{
path: 'products',
component: ProductsComponent,
title: titleResolver,
- }
+ },
];
-
```
Route titles can also be set via a service extending the [`TitleStrategy`](/api/router/TitleStrategy) abstract class. By default, Angular uses the [`DefaultTitleStrategy`](/api/router/DefaultTitleStrategy).
@@ -329,9 +326,9 @@ For advanced scenarios where you need centralized control over how the document
`TitleStrategy` is a token you can provide to override the default title strategy used by Angular. You can supply a custom `TitleStrategy` to implement conventions such as adding an application suffix, formatting titles from breadcrumbs, or generating titles dynamically from route data.
```ts
-import { Injectable } from '@angular/core';
-import { Title } from '@angular/platform-browser';
-import { TitleStrategy, RouterStateSnapshot } from '@angular/router';
+import {inject, Injectable} from '@angular/core';
+import {Title} from '@angular/platform-browser';
+import {TitleStrategy, RouterStateSnapshot} from '@angular/router';
@Injectable()
export class AppTitleStrategy extends TitleStrategy {
@@ -349,14 +346,11 @@ export class AppTitleStrategy extends TitleStrategy {
To use the custom strategy, provide it with the `TitleStrategy` token at the application level:
```ts
-import { provideRouter, TitleStrategy } from '@angular/router';
-import { AppTitleStrategy } from './app-title.strategy';
+import {provideRouter, TitleStrategy} from '@angular/router';
+import {AppTitleStrategy} from './app-title.strategy';
export const appConfig = {
- providers: [
- provideRouter(routes),
- { provide: TitleStrategy, useClass: AppTitleStrategy },
- ],
+ providers: [provideRouter(routes), {provide: TitleStrategy, useClass: AppTitleStrategy}],
};
```
@@ -370,10 +364,7 @@ Common scenarios where this can be helpful include applications that have differ
export const ROUTES: Route[] = [
{
path: 'admin',
- providers: [
- AdminService,
- {provide: ADMIN_API_KEY, useValue: '12345'},
- ],
+ providers: [AdminService, {provide: ADMIN_API_KEY, useValue: '12345'}],
children: [
{path: 'users', component: AdminUsersComponent},
{path: 'teams', component: AdminTeamsComponent},
@@ -399,22 +390,22 @@ There are two ways to work with route data: static data that remains constant, a
You can associate arbitrary static data with a route via the `data` property in order to centralize things like route-specific metadata (e.g., analytics tracking, permissions, etc.):
```ts
-import { Routes } from '@angular/router';
-import { HomeComponent } from './home/home.component';
-import { AboutComponent } from './about/about.component';
-import { ProductsComponent } from './products/products.component';
+import {Routes} from '@angular/router';
+import {HomeComponent} from './home/home.component';
+import {AboutComponent} from './about/about.component';
+import {ProductsComponent} from './products/products.component';
const routes: Routes = [
{
path: 'about',
component: AboutComponent,
- data: { analyticsId: '456' }
+ data: {analyticsId: '456'},
},
{
path: '',
component: HomeComponent,
- data: { analyticsId: '123' }
- }
+ data: {analyticsId: '123'},
+ },
];
```
@@ -442,15 +433,15 @@ const routes: Routes = [
children: [
{
path: 'info',
- component: ProductInfoComponent
+ component: ProductInfoComponent,
},
{
path: 'reviews',
- component: ProductReviewsComponent
- }
- ]
- }
-]
+ component: ProductReviewsComponent,
+ },
+ ],
+ },
+];
```
The above example defines a route for a product page that allows a user to change whether the product info or reviews are displayed based on the url.
diff --git a/adev-ja/src/content/guide/routing/define-routes.md b/adev-ja/src/content/guide/routing/define-routes.md
index 205820e646..8ac32f2718 100644
--- a/adev-ja/src/content/guide/routing/define-routes.md
+++ b/adev-ja/src/content/guide/routing/define-routes.md
@@ -9,12 +9,12 @@ Angularでは、**ルート**は特定のURLパスまたはパターンに対し
次にルートの基本的な例を示します。
```ts
-import { AdminPage } from './app-admin/app-admin.component';
+import {AdminPage} from './app-admin/app-admin.component';
const adminPage = {
path: 'admin',
- component: AdminPage
-}
+ component: AdminPage,
+};
```
このルートの場合、ユーザーが`/admin`パスにアクセスすると、アプリケーションは`AdminPage`コンポーネントを表示します。
@@ -26,9 +26,9 @@ const adminPage = {
ルートのコレクションは次のようになります。
```ts
-import { Routes } from '@angular/router';
-import { HomePage } from './home-page/home-page.component';
-import { AdminPage } from './about-page/admin-page.component';
+import {Routes} from '@angular/router';
+import {HomePage} from './home-page/home-page.component';
+import {AdminPage} from './about-page/admin-page.component';
export const routes: Routes = [
{
@@ -51,16 +51,16 @@ Angular CLIなしでAngularアプリケーションをブートストラップ
`providers`配列内で、`provideRouter`関数呼び出しとルートを追加することで、Angularルーターをアプリケーションに追加できます。
```ts
-import { ApplicationConfig } from '@angular/core';
-import { provideRouter } from '@angular/router';
+import {ApplicationConfig} from '@angular/core';
+import {provideRouter} from '@angular/router';
-import { routes } from './app.routes';
+import {routes} from './app.routes';
export const appConfig: ApplicationConfig = {
providers: [
provideRouter(routes),
// ...
- ]
+ ],
};
```
@@ -88,12 +88,10 @@ IMPORTANT: パラメーターは、URLの[クエリ文字列](https://en.wikiped
次の例は、URLを介して渡されたユーザーIDに基づいてユーザープロファイルコンポーネントを表示します。
```ts
-import { Routes } from '@angular/router';
-import { UserProfile } from './user-profile/user-profile';
+import {Routes} from '@angular/router';
+import {UserProfile} from './user-profile/user-profile';
-const routes: Routes = [
- { path: 'user/:id', component: UserProfile }
-];
+const routes: Routes = [{path: 'user/:id', component: UserProfile}];
```
この例では、`/user/leeroy`や`/user/jenkins`などのURLは`UserProfile`コンポーネントをレンダリングします。このコンポーネントは、`id`パラメーターを読み取り、それを使用してデータの取得などの追加作業を実行できます。[ルートパラメーターの読み取りの詳細については、ルート状態の読み取りガイドを参照してください](/guide/routing/read-route-state)。
@@ -108,13 +106,13 @@ const routes: Routes = [
複数のパラメーターを持つパスを定義できます。
```ts
-import { Routes } from '@angular/router';
-import { UserProfile } from './user-profile/user-profile.component';
-import { SocialMediaFeed } from './user-profile/social–media-feed.component';
+import {Routes} from '@angular/router';
+import {UserProfile} from './user-profile/user-profile.component';
+import {SocialMediaFeed} from './user-profile/social–media-feed.component';
const routes: Routes = [
- { path: 'user/:id/:social-media', component: SocialMediaFeed },
- { path: 'user/:id/', component: UserProfile },
+ {path: 'user/:id/:social-media', component: SocialMediaFeed},
+ {path: 'user/:id/', component: UserProfile},
];
```
@@ -129,14 +127,14 @@ const routes: Routes = [
一般的な例は、ページが見つかりませんコンポーネントの定義です。
```ts
-import { Home } from './home/home.component';
-import { UserProfile } from './user-profile/user-profile.component';
-import { NotFound } from './not-found/not-found.component';
+import {Home} from './home/home.component';
+import {UserProfile} from './user-profile/user-profile.component';
+import {NotFound} from './not-found/not-found.component';
const routes: Routes = [
- { path: 'home', component: Home },
- { path: 'user/:id', component: UserProfile },
- { path: '**', component: NotFound }
+ {path: 'home', component: Home},
+ {path: 'user/:id', component: UserProfile},
+ {path: '**', component: NotFound},
];
```
@@ -152,11 +150,11 @@ Tip: ワイルドカードルートは通常、ルート配列の最後に配置
```ts
const routes: Routes = [
- { path: '', component: HomeComponent }, // 空のパス
- { path: 'users/new', component: NewUserComponent }, // 静的、最も具体的
- { path: 'users/:id', component: UserDetailComponent }, // 動的
- { path: 'users', component: UsersComponent }, // 静的、具体的でない
- { path: '**', component: NotFoundComponent } // ワイルドカード - 常に最後
+ {path: '', component: HomeComponent}, // 空のパス
+ {path: 'users/new', component: NewUserComponent}, // 静的、最も具体的
+ {path: 'users/:id', component: UserDetailComponent}, // 動的
+ {path: 'users', component: UsersComponent}, // 静的、具体的でない
+ {path: '**', component: NotFoundComponent}, // ワイルドカード - 常に最後
];
```
@@ -168,12 +166,12 @@ const routes: Routes = [
1. `users`には到達しません
1. `**`には到達しません
-## ルートコンポーネントの読み込み戦略 {#loading-route-component-strategies}
+## ルートの読み込み戦略 {#route-loading-strategies}
-Angularルーティングでコンポーネントがどのように、いつ読み込まれるかを理解することは、応答性の高いWebアプリケーションを構築するために不可欠です。Angularは、コンポーネントの読み込み動作を制御するための2つの主要な戦略を提供します。
+Angularルーティングでルートとコンポーネントがどのように、いつ読み込まれるかを理解することは、応答性の高いWebアプリケーションを構築するために不可欠です。Angularは、読み込み動作を制御するための2つの主要な戦略を提供します。
-1. **即時読み込み (Eagerly loaded)**: すぐに読み込まれるコンポーネント
-2. **遅延読み込み (Lazily loaded)**: 必要になったときにのみ読み込まれるコンポーネント
+1. **即時読み込み (Eagerly loaded)**: すぐに読み込まれるルートとコンポーネント
+2. **遅延読み込み (Lazily loaded)**: 必要になったときにのみ読み込まれるルートとコンポーネント
それぞれのアプローチは、異なるシナリオに対して明確な利点を提供します。
@@ -182,50 +180,51 @@ Angularルーティングでコンポーネントがどのように、いつ読
`component`プロパティでルートを定義すると、参照されるコンポーネントは、ルート構成と同じJavaScriptバンドルの一部として即時読み込みされます。
```ts
-import { Routes } from "@angular/router";
-import { HomePage } from "./components/home/home-page"
-import { LoginPage } from "./components/auth/login-page"
+import {Routes} from '@angular/router';
+import {HomePage} from './components/home/home-page';
+import {LoginPage} from './components/auth/login-page';
export const routes: Routes = [
// HomePageとLoginPageはどちらもこの設定で直接参照されているため、
// そのコードはこのファイルと同じJavaScriptバンドルに即時含まれます。
{
- path: "",
- component: HomePage
+ path: '',
+ component: HomePage,
},
{
- path: "login",
- component: LoginPage
- }
-]
+ path: 'login',
+ component: LoginPage,
+ },
+];
```
このようにルートコンポーネントを即時読み込みすることは、ブラウザが初期ページ読み込みの一部としてこれらのコンポーネントのすべてのJavaScriptをダウンロードして解析する必要があることを意味しますが、コンポーネントはAngularですぐに利用できます。
初期ページ読み込みに多くのJavaScriptを含めると初期読み込み時間は遅くなりますが、ユーザーがアプリケーション内を移動する際のよりシームレスな遷移につながる可能性があります。
-### 遅延読み込みされるコンポーネント {#lazily-loaded-components}
+### 遅延読み込みされるコンポーネントとルート {#lazily-loaded-components-and-routes}
-`loadComponent`プロパティを使用すると、そのルートがアクティブになる時点でのみ、ルートのJavaScriptを遅延読み込みできます。
+`loadComponent`プロパティを使用すると、そのルートがアクティブになる時点でのみ、コンポーネントのJavaScriptを遅延読み込みできます。`loadChildren`プロパティは、ルートマッチング時に子ルートを遅延読み込みします。
```ts
-import { Routes } from "@angular/router";
+import {Routes} from '@angular/router';
export const routes: Routes = [
- // HomePageとLoginPageコンポーネントは、
- // 対応するルートがアクティブになった時点で遅延読み込みされます。
{
path: 'login',
- loadComponent: () => import('./components/auth/login-page').then(m => m.LoginPage)
+ loadComponent: () => import('./components/auth/login-page'),
},
{
- path: '',
- loadComponent: () => import('./components/home/home-page').then(m => m.HomePage)
- }
-]
+ path: 'admin',
+ loadComponent: () => import('./admin/admin.component'),
+ loadChildren: () => import('./admin/admin.routes'),
+ },
+];
```
-`loadComponent`プロパティは、Angularコンポーネントに解決されるPromiseを返すローダー関数を受け入れます。ほとんどの場合、この関数は標準の[JavaScript動的インポートAPI](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import)を使用します。ただし、任意の非同期ローダー関数も使用できます。
+`loadComponent`と`loadChildren`プロパティは、それぞれAngularコンポーネントまたはルートのセットに解決されるPromiseを返すローダー関数を受け入れます。ほとんどの場合、この関数は標準の[JavaScript動的インポートAPI](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import)を使用します。ただし、任意の非同期ローダー関数も使用できます。
+
+遅延読み込みされるファイルが`default`エクスポートを使用している場合、エクスポートされたクラスを選択するための追加の`.then`呼び出しなしで、`import()`Promiseを直接返すことができます。
遅延読み込みルートは、初期バンドルからJavaScriptの大部分を削除することで、Angularアプリケーションの読み込み速度を大幅に向上させることができます。これらのコード部分は、ユーザーが対応するルートにアクセスしたときにのみルーターが要求する個別のJavaScript「チャンク」にコンパイルされます。
@@ -234,9 +233,9 @@ export const routes: Routes = [
ルーターは`loadComponent`と`loadChildren`を**現在のルートの注入コンテキスト**内で実行します。これにより、これらのローダー関数内で[`inject`](/api/core/inject)を呼び出して、そのルートで宣言されたプロバイダー、階層的な依存性の注入を介して親ルートから継承されたプロバイダー、またはグローバルに利用可能なプロバイダーにアクセスできます。これにより、コンテキストを認識した遅延読み込みが可能になります。
```ts
-import { Routes } from '@angular/router';
-import { inject } from '@angular/core';
-import { FeatureFlags } from './feature-flags';
+import {Routes} from '@angular/router';
+import {inject} from '@angular/core';
+import {FeatureFlags} from './feature-flags';
export const routes: Routes = [
{
@@ -245,8 +244,8 @@ export const routes: Routes = [
loadComponent: () => {
const flags = inject(FeatureFlags);
return flags.isPremium
- ? import('./dashboard/premium-dashboard').then(m => m.PremiumDashboard)
- : import('./dashboard/basic-dashboard').then(m => m.BasicDashboard);
+ ? import('./dashboard/premium-dashboard')
+ : import('./dashboard/basic-dashboard');
},
},
];
@@ -265,7 +264,7 @@ NOTE: 遅延ルートは、ユーザーが要求する初期データの量を
コンポーネントをレンダリングする代わりに、別のルートにリダイレクトするルートを定義できます。
```ts
-import { BlogComponent } from './home/blog.component';
+import {BlogComponent} from './home/blog.component';
const routes: Routes = [
{
@@ -274,7 +273,7 @@ const routes: Routes = [
},
{
path: 'blog',
- component: BlogComponent
+ component: BlogComponent,
},
];
```
@@ -286,20 +285,20 @@ const routes: Routes = [
各ルートには**タイトル**を関連付けることができます。ルートがアクティブになると、Angularは[ページタイトル](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/title)を自動的に更新します。アクセシブルな体験を作成するためにこれらのタイトルが必要となるため、アプリケーションに適切なページタイトルを常に定義してください。
```ts
-import { Routes } from '@angular/router';
-import { HomeComponent } from './home/home.component';
-import { AboutComponent } from './about/about.component';
+import {Routes} from '@angular/router';
+import {HomeComponent} from './home/home.component';
+import {AboutComponent} from './about/about.component';
const routes: Routes = [
{
path: '',
component: HomeComponent,
- title: 'Home Page'
+ title: 'Home Page',
},
{
path: 'about',
component: AboutComponent,
- title: 'About Us'
+ title: 'About Us',
},
];
```
@@ -309,14 +308,12 @@ const routes: Routes = [
```ts
const titleResolver: ResolveFn = (route) => route.queryParams['id'];
const routes: Routes = [
- ...
- {
+ ...{
path: 'products',
component: ProductsComponent,
title: titleResolver,
- }
+ },
];
-
```
ルートタイトルは、[`TitleStrategy`](/api/router/TitleStrategy) 抽象クラスを継承するサービスを介しても設定できます。デフォルトでは、Angularは[`DefaultTitleStrategy`](/api/router/DefaultTitleStrategy)を使用します。
@@ -328,9 +325,9 @@ const routes: Routes = [
`TitleStrategy`は、Angularが使用するデフォルトのタイトル戦略をオーバーライドするために提供できるトークンです。カスタムの`TitleStrategy`を提供して、アプリケーションのサフィックスの追加、パンくずリストからのタイトルのフォーマット、ルートデータからのタイトルの動的生成などの規約を実装できます。
```ts
-import { Injectable } from '@angular/core';
-import { Title } from '@angular/platform-browser';
-import { TitleStrategy, RouterStateSnapshot } from '@angular/router';
+import {inject, Injectable} from '@angular/core';
+import {Title} from '@angular/platform-browser';
+import {TitleStrategy, RouterStateSnapshot} from '@angular/router';
@Injectable()
export class AppTitleStrategy extends TitleStrategy {
@@ -348,14 +345,11 @@ export class AppTitleStrategy extends TitleStrategy {
カスタム戦略を使用するには、アプリケーションレベルで`TitleStrategy`トークンを使用してそれを提供します。
```ts
-import { provideRouter, TitleStrategy } from '@angular/router';
-import { AppTitleStrategy } from './app-title.strategy';
+import {provideRouter, TitleStrategy} from '@angular/router';
+import {AppTitleStrategy} from './app-title.strategy';
export const appConfig = {
- providers: [
- provideRouter(routes),
- { provide: TitleStrategy, useClass: AppTitleStrategy },
- ],
+ providers: [provideRouter(routes), {provide: TitleStrategy, useClass: AppTitleStrategy}],
};
```
@@ -369,10 +363,7 @@ export const appConfig = {
export const ROUTES: Route[] = [
{
path: 'admin',
- providers: [
- AdminService,
- {provide: ADMIN_API_KEY, useValue: '12345'},
- ],
+ providers: [AdminService, {provide: ADMIN_API_KEY, useValue: '12345'}],
children: [
{path: 'users', component: AdminUsersComponent},
{path: 'teams', component: AdminTeamsComponent},
@@ -398,22 +389,22 @@ Angularのプロバイダーと注入に関する詳細については、[依存
`data`プロパティを介して任意の静的データをルートに関連付けることで、ルート固有のメタデータ（例: 分析トラッキング、権限など）を一元化できます。
```ts
-import { Routes } from '@angular/router';
-import { HomeComponent } from './home/home.component';
-import { AboutComponent } from './about/about.component';
-import { ProductsComponent } from './products/products.component';
+import {Routes} from '@angular/router';
+import {HomeComponent} from './home/home.component';
+import {AboutComponent} from './about/about.component';
+import {ProductsComponent} from './products/products.component';
const routes: Routes = [
{
path: 'about',
component: AboutComponent,
- data: { analyticsId: '456' }
+ data: {analyticsId: '456'},
},
{
path: '',
component: HomeComponent,
- data: { analyticsId: '123' }
- }
+ data: {analyticsId: '123'},
+ },
];
```
@@ -441,15 +432,15 @@ const routes: Routes = [
children: [
{
path: 'info',
- component: ProductInfoComponent
+ component: ProductInfoComponent,
},
{
path: 'reviews',
- component: ProductReviewsComponent
- }
- ]
- }
-]
+ component: ProductReviewsComponent,
+ },
+ ],
+ },
+];
```
上記の例では、ユーザーがURLに基づいて製品情報またはレビューのどちらを表示するかを変更できる製品ページのルートを定義しています。
diff --git a/adev-ja/src/content/guide/routing/lifecycle-and-events.en.md b/adev-ja/src/content/guide/routing/lifecycle-and-events.en.md
index 1d998ac28b..c4f7132309 100644
--- a/adev-ja/src/content/guide/routing/lifecycle-and-events.en.md
+++ b/adev-ja/src/content/guide/routing/lifecycle-and-events.en.md
@@ -64,16 +64,12 @@ Debugging router navigation issues can be challenging without visibility into th
When you need to inspect a Router event sequence, you can enable logging for internal navigation events for debugging. You can configure this by passing a configuration option (`withDebugTracing()`) that enables detailed console logging of all routing events.
```ts
-import { provideRouter, withDebugTracing } from '@angular/router';
+import {provideRouter, withDebugTracing} from '@angular/router';
const appRoutes: Routes = [];
-bootstrapApplication(AppComponent,
- {
- providers: [
- provideRouter(appRoutes, withDebugTracing())
- ]
- }
-);
+bootstrapApplication(AppComponent, {
+ providers: [provideRouter(appRoutes, withDebugTracing())],
+});
```
For more information, check out the official docs on [`withDebugTracing`](api/router/withDebugTracing).
@@ -89,26 +85,19 @@ Show loading indicators during navigation:
```angular-ts
import { Component, inject } from '@angular/core';
import { Router } from '@angular/router';
-import { toSignal } from '@angular/core/rxjs-interop';
-import { map } from 'rxjs/operators';
@Component({
- selector: 'app-loading',
+ selector: 'app-root',
template: `
- @if (loading()) {
- = (component: FormComponent, currentRoute: ActivatedRouteSnapshot, currentState: RouterStateSnapshot, nextState: RouterStateSnapshot) => {
+export const unsavedChangesGuard: CanDeactivateFn = (
+ component: FormComponent,
+ currentRoute: ActivatedRouteSnapshot,
+ currentState: RouterStateSnapshot,
+ nextState: RouterStateSnapshot,
+) => {
return component.hasUnsavedChanges()
? confirm('You have unsaved changes. Are you sure you want to leave?')
: true;
@@ -130,14 +141,14 @@ const routes: Routes = [
{
path: 'dashboard',
component: AdminDashboard,
- canMatch: [adminGuard]
+ canMatch: [adminGuard],
},
{
path: 'dashboard',
component: UserDashboard,
- canMatch: [userGuard]
- }
-]
+ canMatch: [userGuard],
+ },
+];
```
In this example, when the user visits `/dashboard`, the first one that matches the correct guard will be used.
@@ -151,25 +162,25 @@ Once you've created your route guards, you need to configure them in your route
Guards are specified as arrays in the route configuration in order to allow you to apply multiple guards to a single route. They are executed in the order they appear in the array.
```ts
-import { Routes } from '@angular/router';
-import { authGuard } from './guards/auth.guard';
-import { adminGuard } from './guards/admin.guard';
-import { canDeactivateGuard } from './guards/can-deactivate.guard';
-import { featureToggleGuard } from './guards/feature-toggle.guard';
+import {Routes} from '@angular/router';
+import {authGuard} from './guards/auth.guard';
+import {adminGuard} from './guards/admin.guard';
+import {canDeactivateGuard} from './guards/can-deactivate.guard';
+import {featureToggleGuard} from './guards/feature-toggle.guard';
const routes: Routes = [
// Basic CanActivate - requires authentication
{
path: 'dashboard',
component: DashboardComponent,
- canActivate: [authGuard]
+ canActivate: [authGuard],
},
// Multiple CanActivate guards - requires authentication AND admin role
{
path: 'admin',
component: AdminComponent,
- canActivate: [authGuard, adminGuard]
+ canActivate: [authGuard, adminGuard],
},
// CanActivate + CanDeactivate - protected route with unsaved changes check
@@ -177,7 +188,7 @@ const routes: Routes = [
path: 'profile',
component: ProfileComponent,
canActivate: [authGuard],
- canDeactivate: [canDeactivateGuard]
+ canDeactivate: [canDeactivateGuard],
},
// CanActivateChild - protects all child routes
@@ -186,23 +197,23 @@ const routes: Routes = [
canActivateChild: [authGuard],
children: [
// /users/list - PROTECTED
- { path: 'list', component: UserListComponent },
+ {path: 'list', component: UserListComponent},
// /users/detail/:id - PROTECTED
- { path: 'detail/:id', component: UserDetailComponent }
- ]
+ {path: 'detail/:id', component: UserDetailComponent},
+ ],
},
// CanMatch - conditionally matches route based on feature flag
{
path: 'beta-feature',
component: BetaFeatureComponent,
- canMatch: [featureToggleGuard]
+ canMatch: [featureToggleGuard],
},
// Fallback route if beta feature is disabled
{
path: 'beta-feature',
- component: ComingSoonComponent
- }
+ component: ComingSoonComponent,
+ },
];
```
diff --git a/adev-ja/src/content/guide/routing/route-guards.md b/adev-ja/src/content/guide/routing/route-guards.md
index c4d690202c..b42818a654 100644
--- a/adev-ja/src/content/guide/routing/route-guards.md
+++ b/adev-ja/src/content/guide/routing/route-guards.md
@@ -51,7 +51,10 @@ Angularは、それぞれ異なる目的を持つ4種類のルートガードを
[標準のガード戻り値の型](#route-guard-return-types)を返すことができます。
```ts
-export const authGuard: CanActivateFn = (route: ActivatedRouteSnapshot, state: RouterStateSnapshot) => {
+export const authGuard: CanActivateFn = (
+ route: ActivatedRouteSnapshot,
+ state: RouterStateSnapshot,
+) => {
const authService = inject(AuthService);
return authService.isAuthenticated();
};
@@ -73,7 +76,10 @@ Tip: ユーザーをリダイレクトする必要がある場合は、[`URLTree
[標準のガード戻り値の型](#route-guard-return-types)を返すことができます。
```ts
-export const adminChildGuard: CanActivateChildFn = (childRoute: ActivatedRouteSnapshot, state: RouterStateSnapshot) => {
+export const adminChildGuard: CanActivateChildFn = (
+ childRoute: ActivatedRouteSnapshot,
+ state: RouterStateSnapshot,
+) => {
const authService = inject(AuthService);
return authService.hasRole('admin');
};
@@ -95,7 +101,12 @@ export const adminChildGuard: CanActivateChildFn = (childRoute: ActivatedRouteSn
[標準のガード戻り値の型](#route-guard-return-types)を返すことができます。
```ts
-export const unsavedChangesGuard: CanDeactivateFn = (component: FormComponent, currentRoute: ActivatedRouteSnapshot, currentState: RouterStateSnapshot, nextState: RouterStateSnapshot) => {
+export const unsavedChangesGuard: CanDeactivateFn = (
+ component: FormComponent,
+ currentRoute: ActivatedRouteSnapshot,
+ currentState: RouterStateSnapshot,
+ nextState: RouterStateSnapshot,
+) => {
return component.hasUnsavedChanges()
? confirm('You have unsaved changes. Are you sure you want to leave?')
: true;
@@ -130,14 +141,14 @@ const routes: Routes = [
{
path: 'dashboard',
component: AdminDashboard,
- canMatch: [adminGuard]
+ canMatch: [adminGuard],
},
{
path: 'dashboard',
component: UserDashboard,
- canMatch: [userGuard]
- }
-]
+ canMatch: [userGuard],
+ },
+];
```
この例では、ユーザーが`/dashboard`にアクセスすると、正しいガードにマッチする最初のものが使用されます。
@@ -151,25 +162,25 @@ const routes: Routes = [
ガードは、単一のルートに複数のガードを適用できるように、ルート設定で配列として指定されます。それらは配列に現れる順序で実行されます。
```ts
-import { Routes } from '@angular/router';
-import { authGuard } from './guards/auth.guard';
-import { adminGuard } from './guards/admin.guard';
-import { canDeactivateGuard } from './guards/can-deactivate.guard';
-import { featureToggleGuard } from './guards/feature-toggle.guard';
+import {Routes} from '@angular/router';
+import {authGuard} from './guards/auth.guard';
+import {adminGuard} from './guards/admin.guard';
+import {canDeactivateGuard} from './guards/can-deactivate.guard';
+import {featureToggleGuard} from './guards/feature-toggle.guard';
const routes: Routes = [
// Basic CanActivate - 認証が必要
{
path: 'dashboard',
component: DashboardComponent,
- canActivate: [authGuard]
+ canActivate: [authGuard],
},
// 複数のCanActivateガード - 認証と管理者ロールが必要
{
path: 'admin',
component: AdminComponent,
- canActivate: [authGuard, adminGuard]
+ canActivate: [authGuard, adminGuard],
},
// CanActivate + CanDeactivate - 未保存の変更チェック付き保護ルート
@@ -177,7 +188,7 @@ const routes: Routes = [
path: 'profile',
component: ProfileComponent,
canActivate: [authGuard],
- canDeactivate: [canDeactivateGuard]
+ canDeactivate: [canDeactivateGuard],
},
// CanActivateChild - すべての子ルートを保護
@@ -186,23 +197,23 @@ const routes: Routes = [
canActivateChild: [authGuard],
children: [
// /users/list - 保護されている
- { path: 'list', component: UserListComponent },
+ {path: 'list', component: UserListComponent},
// /users/detail/:id - 保護されている
- { path: 'detail/:id', component: UserDetailComponent }
- ]
+ {path: 'detail/:id', component: UserDetailComponent},
+ ],
},
// CanMatch - 機能フラグに基づいてルートを条件付きでマッチング
{
path: 'beta-feature',
component: BetaFeatureComponent,
- canMatch: [featureToggleGuard]
+ canMatch: [featureToggleGuard],
},
// ベータ機能が無効な場合のフォールバックルート
{
path: 'beta-feature',
- component: ComingSoonComponent
- }
+ component: ComingSoonComponent,
+ },
];
```
diff --git a/adev-ja/src/content/guide/routing/route-transition-animations.en.md b/adev-ja/src/content/guide/routing/route-transition-animations.en.md
index a9aa290a1c..bacb0b8e12 100644
--- a/adev-ja/src/content/guide/routing/route-transition-animations.en.md
+++ b/adev-ja/src/content/guide/routing/route-transition-animations.en.md
@@ -41,25 +41,23 @@ Enable view transitions by adding the `withViewTransitions` feature to your [rou
### Standalone bootstrap
```ts
-import { bootstrapApplication } from '@angular/platform-browser';
-import { provideRouter, withViewTransitions } from '@angular/router';
-import { routes } from './app.routes';
+import {bootstrapApplication} from '@angular/platform-browser';
+import {provideRouter, withViewTransitions} from '@angular/router';
+import {routes} from './app.routes';
bootstrapApplication(MyApp, {
- providers: [
- provideRouter(routes, withViewTransitions()),
- ]
+ providers: [provideRouter(routes, withViewTransitions())],
});
```
### NgModule bootstrap
```ts
-import { NgModule } from '@angular/core';
-import { RouterModule } from '@angular/router';
+import {NgModule} from '@angular/core';
+import {RouterModule} from '@angular/router';
@NgModule({
- imports: [RouterModule.forRoot(routes, {enableViewTransitions: true})]
+ imports: [RouterModule.forRoot(routes, {enableViewTransitions: true})],
})
export class AppRouting {}
```
@@ -123,13 +121,13 @@ The `withViewTransitions` feature accepts an options object with an `onViewTrans
Use this callback to customize transition behavior based on navigation context. For example, you can skip transitions for specific navigation types:
```ts
-import { inject } from '@angular/core';
-import { Router, withViewTransitions } from '@angular/router';
+import {inject} from '@angular/core';
+import {Router, withViewTransitions} from '@angular/router';
withViewTransitions({
onViewTransitionCreated: ({transition}) => {
const router = inject(Router);
- const targetUrl = router.getCurrentNavigation()!.finalUrl!;
+ const targetUrl = router.currentNavigation()!.finalUrl!;
// Skip transition if only fragment or query params change
const config = {
@@ -143,7 +141,7 @@ withViewTransitions({
transition.skipTransition();
}
},
-})
+});
```
This example skips the view transition when navigation only changes the [URL fragment or query parameters](/guide/routing/read-route-state#query-parameters) (such as anchor links within the same page). The `skipTransition()` method prevents the animation while still allowing the navigation to complete.
diff --git a/adev-ja/src/content/guide/routing/route-transition-animations.md b/adev-ja/src/content/guide/routing/route-transition-animations.md
index 910a72b8b9..4eace74818 100644
--- a/adev-ja/src/content/guide/routing/route-transition-animations.md
+++ b/adev-ja/src/content/guide/routing/route-transition-animations.md
@@ -41,25 +41,23 @@ Routerのビュー遷移統合は[プログレッシブエンハンスメント]
### スタンドアロンブートストラップ {#standalone-bootstrap}
```ts
-import { bootstrapApplication } from '@angular/platform-browser';
-import { provideRouter, withViewTransitions } from '@angular/router';
-import { routes } from './app.routes';
+import {bootstrapApplication} from '@angular/platform-browser';
+import {provideRouter, withViewTransitions} from '@angular/router';
+import {routes} from './app.routes';
bootstrapApplication(MyApp, {
- providers: [
- provideRouter(routes, withViewTransitions()),
- ]
+ providers: [provideRouter(routes, withViewTransitions())],
});
```
### NgModuleブートストラップ {#ngmodule-bootstrap}
```ts
-import { NgModule } from '@angular/core';
-import { RouterModule } from '@angular/router';
+import {NgModule} from '@angular/core';
+import {RouterModule} from '@angular/router';
@NgModule({
- imports: [RouterModule.forRoot(routes, {enableViewTransitions: true})]
+ imports: [RouterModule.forRoot(routes, {enableViewTransitions: true})],
})
export class AppRouting {}
```
@@ -123,13 +121,13 @@ IMPORTANT: ビューのトランジションアニメーションは、コンポ
このコールバックを使用して、ナビゲーションコンテキストに基づいてトランジション動作をカスタマイズできます。たとえば、特定のナビゲーションタイプではトランジションをスキップできます。
```ts
-import { inject } from '@angular/core';
-import { Router, withViewTransitions } from '@angular/router';
+import {inject} from '@angular/core';
+import {Router, withViewTransitions} from '@angular/router';
withViewTransitions({
onViewTransitionCreated: ({transition}) => {
const router = inject(Router);
- const targetUrl = router.getCurrentNavigation()!.finalUrl!;
+ const targetUrl = router.currentNavigation()!.finalUrl!;
// Skip transition if only fragment or query params change
const config = {
@@ -143,7 +141,7 @@ withViewTransitions({
transition.skipTransition();
}
},
-})
+});
```
この例では、ナビゲーションが[URLフラグメントまたはクエリパラメータ](/guide/routing/read-route-state#query-parameters)のみを変更する場合（同じページ内のアンカーリンクなど）にビュー遷移をスキップします。`skipTransition()`メソッドは、ナビゲーションの完了を許可しながらアニメーションを防止します。
@@ -201,4 +199,3 @@ NOTE: Angular Routerはビュー遷移を遅延させる方法を提供してい
- [Chrome Explainer](https://developer.chrome.com/docs/web-platform/view-transitions/same-document#animating-with-javascript)
- [Angular Example on StackBlitz](https://stackblitz.com/edit/stackblitz-starters-cklnkm)
-
diff --git a/adev-ja/src/content/guide/routing/router-reference.en.md b/adev-ja/src/content/guide/routing/router-reference.en.md
index 7454068a96..2038c2c4c4 100644
--- a/adev-ja/src/content/guide/routing/router-reference.en.md
+++ b/adev-ja/src/content/guide/routing/router-reference.en.md
@@ -110,9 +110,7 @@ For more complete information on how `
A "Root Effect" is created in the context of a root provided service instantiation. -The execution of both kind of `effect` are tied to the change detection process. +The execution of both kinds of `effect` are tied to the change detection process. -- "View effects" are executed _before_ there corresponding component is checked the change detection process. +- "View effects" are executed _before_ their corresponding component is checked by the change detection process. - "Root effects" are executed prior to all components being checked by the change detection process. -In both cases, if at least one of the effect dependency changed during the effect execution, the effect will re-run before moving ahead on the change detection process, +In both cases, if at least one of the effect dependencies changed during the effect execution, the effect will re-run before moving ahead on the change detection process, ### Destroying effects When a component or directive is destroyed, Angular automatically cleans up any associated effects. -An `effect` can be created two different context that will affect when it's destroyed: +An `effect` can be created in two different contexts that will affect when it's destroyed: - A "View effect" is destroyed when the component is destroyed. - A "Root effect" is destroyed when the application is destroyed. @@ -114,7 +116,9 @@ The `effect` function is a general-purpose tool for running code in reaction to For these situations, you can use `afterRenderEffect`. It functions like `effect`, but runs after Angular has finished rendering and committed its changes to the DOM. ```ts -@Component({/* ... */}) +@Component({ + /* ... */ +}) export class MyFancyChart { chartData = input.required();
canvas = viewChild.required>('canvas');
@@ -124,8 +128,8 @@ export class MyFancyChart {
// Run a single time to create the chart instance
afterNextRender({
write: () => {
- this.chart = initializeChart(this.nativeElement(), this.charData());
- }
+ this.chart = initializeChart(this.canvas().nativeElement(), this.charData());
+ },
});
// Re-run after DOM has been updated whenever `chartData` changes
@@ -161,10 +165,18 @@ You can specify the phase by passing an object with a `phase` property to `after
```ts
afterRenderEffect({
- earlyRead: (cleanupFn) => { /* ... */ },
- write: (previousPhaseValue, cleanupFn) => { /* ... */ },
- mixedReadWrite: (previousPhaseValue, cleanupFn) => { /* ... */ },
- read: (previousPhaseValue, cleanupFn) => { /* ... */ },
+ earlyRead: (cleanupFn) => {
+ /* ... */
+ },
+ write: (previousPhaseValue, cleanupFn) => {
+ /* ... */
+ },
+ mixedReadWrite: (previousPhaseValue, cleanupFn) => {
+ /* ... */
+ },
+ read: (previousPhaseValue, cleanupFn) => {
+ /* ... */
+ },
});
```
diff --git a/adev-ja/src/content/guide/signals/linked-signal.en.md b/adev-ja/src/content/guide/signals/linked-signal.en.md
index c2c84a55f4..4743057a59 100644
--- a/adev-ja/src/content/guide/signals/linked-signal.en.md
+++ b/adev-ja/src/content/guide/signals/linked-signal.en.md
@@ -3,7 +3,9 @@
You can use the `signal` function to hold some state in your Angular code. Sometimes, this state depends on some _other_ state. For example, imagine a component that lets the user select a shipping method for an order:
```typescript
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
export class ShippingMethodPicker {
shippingOptions: Signal = getShippingOptions();
@@ -21,7 +23,9 @@ In this example, the `selectedOption` defaults to the first option, but changes
**The `linkedSignal` function lets you create a signal to hold some state that is intrinsically _linked_ to some other state.** Revisiting the example above, `linkedSignal` can replace `signal`:
```typescript
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
export class ShippingMethodPicker {
shippingOptions: Signal = getShippingOptions();
@@ -62,7 +66,9 @@ interface ShippingMethod {
name: string;
}
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
export class ShippingMethodPicker {
constructor() {
this.changeShipping(2);
@@ -71,9 +77,9 @@ export class ShippingMethodPicker {
}
shippingOptions = signal([
- { id: 0, name: 'Ground' },
- { id: 1, name: 'Air' },
- { id: 2, name: 'Sea' },
+ {id: 0, name: 'Ground'},
+ {id: 1, name: 'Air'},
+ {id: 2, name: 'Sea'},
]);
selectedOption = linkedSignal({
@@ -82,9 +88,7 @@ export class ShippingMethodPicker {
computation: (newOptions, previous) => {
// If the newOptions contain the previously selected option, preserve that selection.
// Otherwise, default to the first option.
- return (
- newOptions.find((opt) => opt.id === previous?.value.id) ?? newOptions[0]
- );
+ return newOptions.find((opt) => opt.id === previous?.value.id) ?? newOptions[0];
},
});
@@ -94,9 +98,9 @@ export class ShippingMethodPicker {
changeShippingOptions() {
this.shippingOptions.set([
- { id: 0, name: 'Email' },
- { id: 1, name: 'Sea' },
- { id: 2, name: 'Postal Service' },
+ {id: 0, name: 'Email'},
+ {id: 1, name: 'Sea'},
+ {id: 2, name: 'Postal Service'},
]);
}
}
@@ -125,7 +129,7 @@ const activeUserEditCopy = linkedSignal(() => activeUser(), {
// Or, if separating `source` and `computation`
const activeUserEditCopy = linkedSignal({
source: activeUser,
- computation: user => user,
+ computation: (user) => user,
equal: (a, b) => a.id === b.id,
});
```
diff --git a/adev-ja/src/content/guide/signals/linked-signal.md b/adev-ja/src/content/guide/signals/linked-signal.md
index 3bfcba3672..8840ce4112 100644
--- a/adev-ja/src/content/guide/signals/linked-signal.md
+++ b/adev-ja/src/content/guide/signals/linked-signal.md
@@ -3,7 +3,9 @@
`signal`関数は、Angularコードで状態を保持するために使用できます。この状態は、他の状態に依存することがあります。例えば、ユーザーが注文の配送方法を選択できるコンポーネントを考えてみましょう。
```typescript
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
export class ShippingMethodPicker {
shippingOptions: Signal = getShippingOptions();
@@ -21,7 +23,9 @@ export class ShippingMethodPicker {
**`linkedSignal`関数は、本質的に他の状態に_リンク_された状態を保持するシグナルを作成できます。**上記の例を再考すると、`linkedSignal`は`signal`を置き換えることができます。
```typescript
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
export class ShippingMethodPicker {
shippingOptions: Signal = getShippingOptions();
@@ -62,7 +66,9 @@ interface ShippingMethod {
name: string;
}
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
export class ShippingMethodPicker {
constructor() {
this.changeShipping(2);
@@ -71,9 +77,9 @@ export class ShippingMethodPicker {
}
shippingOptions = signal([
- { id: 0, name: 'Ground' },
- { id: 1, name: 'Air' },
- { id: 2, name: 'Sea' },
+ {id: 0, name: 'Ground'},
+ {id: 1, name: 'Air'},
+ {id: 2, name: 'Sea'},
]);
selectedOption = linkedSignal({
@@ -82,9 +88,7 @@ export class ShippingMethodPicker {
computation: (newOptions, previous) => {
// If the newOptions contain the previously selected option, preserve that selection.
// Otherwise, default to the first option.
- return (
- newOptions.find((opt) => opt.id === previous?.value.id) ?? newOptions[0]
- );
+ return newOptions.find((opt) => opt.id === previous?.value.id) ?? newOptions[0];
},
});
@@ -94,9 +98,9 @@ export class ShippingMethodPicker {
changeShippingOptions() {
this.shippingOptions.set([
- { id: 0, name: 'Email' },
- { id: 1, name: 'Sea' },
- { id: 2, name: 'Postal Service' },
+ {id: 0, name: 'Email'},
+ {id: 1, name: 'Sea'},
+ {id: 2, name: 'Postal Service'},
]);
}
}
@@ -125,7 +129,7 @@ const activeUserEditCopy = linkedSignal(() => activeUser(), {
// または、`source`と`computation`を分ける場合
const activeUserEditCopy = linkedSignal({
source: activeUser,
- computation: user => user,
+ computation: (user) => user,
equal: (a, b) => a.id === b.id,
});
```
diff --git a/adev-ja/src/content/guide/signals/overview.en.md b/adev-ja/src/content/guide/signals/overview.en.md
index 8bbd01158f..cffc092485 100644
--- a/adev-ja/src/content/guide/signals/overview.en.md
+++ b/adev-ja/src/content/guide/signals/overview.en.md
@@ -33,11 +33,46 @@ or use the `.update()` operation to compute a new value from the previous one:
```ts
// Increment the count by 1.
-count.update(value => value + 1);
+count.update((value) => value + 1);
```
Writable signals have the type `WritableSignal`.
+#### Converting writable signals to readonly
+
+`WritableSignal` provide a `asReadonly()` method that returns a readonly version of the signal. This is useful when you want to expose a signal's value to consumers without allowing them to modify it directly:
+
+```ts
+@Injectable({providedIn: 'root'})
+export class CounterState {
+ // Private writable state
+ private readonly _count = signal(0);
+
+ readonly count = this._count.asReadonly(); // public readonly
+
+ increment() {
+ this._count.update((v) => v + 1);
+ }
+}
+
+@Component({
+ /* ... */
+})
+export class AwesomeCounter {
+ state = inject(CounterState);
+
+ count = this.state.count; // can read but not modify
+
+ increment() {
+ this.state.increment();
+ }
+}
+```
+
+The readonly signal reflects any changes made to the original writable signal, but cannot be modified using `set()` or `update()` methods.
+
+IMPORTANT: The readonly signals do **not** have any built-in mechanism that would prevent deep-mutation of their value.
+
### Computed signals
**Computed signal** are read-only signals that derive their value from other signals. You define computed signals using the `computed` function and specifying a derivation:
@@ -89,6 +124,68 @@ If you set `showCount` to `true` and then read `conditionalCount` again, the der
Note that dependencies can be removed during a derivation as well as added. If you later set `showCount` back to `false`, then `count` will no longer be considered a dependency of `conditionalCount`.
+## Reactive contexts
+
+A **reactive context** is a runtime state where Angular monitors signal reads to establish a dependency. The code reading the signal is the _consumer_, and the signal being read is the _producer_.
+
+Angular automatically enters a reactive context when:
+
+- Executing an `effect`, `afterRenderEffect` callback.
+- Evaluating a `computed` signal.
+- Evaluating a `linkedSignal`.
+- Evaluating a `resource`'s params or loader function.
+- Rendering a component template (including bindings in the [host property](guide/components/host-elements#binding-to-the-host-element)).
+
+During these operations, Angular creates a _live_ connection. If a tracked signal changes, Angular will _eventually_ re-run the consumer.
+
+### Asserts the reactive context
+
+Angular provides the `assertNotInReactiveContext` helper function to assert that code is not executing within a reactive context. Pass a reference to the calling function so the error message points to the correct API entry point if the assertion fails. This produces a clearer, more actionable error message than a generic reactive context error.
+
+```ts
+import {assertNotInReactiveContext} from '@angular/core';
+
+function subscribeToEvents() {
+ assertNotInReactiveContext(subscribeToEvents);
+ // Safe to proceed - subscription logic here
+}
+```
+
+### Reading without tracking dependencies
+
+Rarely, you may want to execute code which may read signals within a reactive function such as `computed` or `effect` _without_ creating a dependency.
+
+For example, suppose that when `currentUser` changes, the value of a `counter` should be logged. You could create an `effect` which reads both signals:
+
+```ts
+effect(() => {
+ console.log(`User set to ${currentUser()} and the counter is ${counter()}`);
+});
+```
+
+This example will log a message when _either_ `currentUser` or `counter` changes. However, if the effect should only run when `currentUser` changes, then the read of `counter` is only incidental and changes to `counter` shouldn't log a new message.
+
+You can prevent a signal read from being tracked by calling its getter with `untracked`:
+
+```ts
+effect(() => {
+ console.log(`User set to ${currentUser()} and the counter is ${untracked(counter)}`);
+});
+```
+
+`untracked` is also useful when an effect needs to invoke some external code which shouldn't be treated as a dependency:
+
+```ts
+effect(() => {
+ const user = currentUser();
+ untracked(() => {
+ // If the `loggingService` reads signals, they won't be counted as
+ // dependencies of this effect.
+ this.loggingService.log(`User set to ${user}`);
+ });
+});
+```
+
## Advanced derivations
While `computed` handles simple readonly derivations, you might find youself needing a writable state that is dependant on other signals.
@@ -98,7 +195,7 @@ All signal APIs are synchronous— `signal`, `computed`, `input`, etc. However,
## Executing side effects on non-reactive APIs
-Synchronous or asynchronous derivations are recommended when we want to react to state changes. However this doesn't cover all the usecase and you'll sometime find yourself in a situation where you need to react on signal changes on non-reactive apis. Use `effect` or `afterRenderEffect` for those specific usecases. For more information see [Side effects for non-reactives APIs](/guide/effect) guide.
+Synchronous or asynchronous derivations are recommended when we want to react to state changes. However, this doesn't cover all the possible use cases, and you'll sometimes find yourself in a situation where you need to react to signal changes on non-reactive apis. Use `effect` or `afterRenderEffect` for those specific usecases. For more information see [Side effects for non-reactive APIs](/guide/signals/effect) guide.
## Reading signals in `OnPush` components
@@ -148,41 +245,6 @@ isWritableSignal(count); // true
isWritableSignal(doubled); // false
```
-### Reading without tracking dependencies
-
-Rarely, you may want to execute code which may read signals within a reactive function such as `computed` or `effect` _without_ creating a dependency.
-
-For example, suppose that when `currentUser` changes, the value of a `counter` should be logged. You could create an `effect` which reads both signals:
-
-```ts
-effect(() => {
- console.log(`User set to ${currentUser()} and the counter is ${counter()}`);
-});
-```
-
-This example will log a message when _either_ `currentUser` or `counter` changes. However, if the effect should only run when `currentUser` changes, then the read of `counter` is only incidental and changes to `counter` shouldn't log a new message.
-
-You can prevent a signal read from being tracked by calling its getter with `untracked`:
-
-```ts
-effect(() => {
- console.log(`User set to ${currentUser()} and the counter is ${untracked(counter)}`);
-});
-```
-
-`untracked` is also useful when an effect needs to invoke some external code which shouldn't be treated as a dependency:
-
-```ts
-effect(() => {
- const user = currentUser();
- untracked(() => {
- // If the `loggingService` reads signals, they won't be counted as
- // dependencies of this effect.
- this.loggingService.log(`User set to ${user}`);
- });
-});
-```
-
## Using signals with RxJS
See [RxJS interop with Angular signals](ecosystem/rxjs-interop) for details on interoperability between signals and RxJS.
diff --git a/adev-ja/src/content/guide/signals/overview.md b/adev-ja/src/content/guide/signals/overview.md
index 1430db45b6..c52065d0e4 100644
--- a/adev-ja/src/content/guide/signals/overview.md
+++ b/adev-ja/src/content/guide/signals/overview.md
@@ -33,11 +33,46 @@ count.set(3);
```ts
// カウントを1増やす。
-count.update(value => value + 1);
+count.update((value) => value + 1);
```
書き込み可能なシグナルは、`WritableSignal`という型になります。
+#### 書き込み可能なシグナルを読み取り専用に変換する
+
+`WritableSignal`は、シグナルの読み取り専用バージョンを返す`asReadonly()`メソッドを提供します。これは、シグナルの値をコンシューマーに公開したいが、直接変更できないようにしたい場合に便利です。
+
+```ts
+@Injectable({providedIn: 'root'})
+export class CounterState {
+ // プライベートな書き込み可能な状態
+ private readonly _count = signal(0);
+
+ readonly count = this._count.asReadonly(); // パブリックな読み取り専用
+
+ increment() {
+ this._count.update((v) => v + 1);
+ }
+}
+
+@Component({
+ /* ... */
+})
+export class AwesomeCounter {
+ state = inject(CounterState);
+
+ count = this.state.count; // 読み取りはできるが変更はできない
+
+ increment() {
+ this.state.increment();
+ }
+}
+```
+
+読み取り専用のシグナルは、元の書き込み可能なシグナルへの変更を反映しますが、`set()`または`update()`メソッドを使用して変更できません。
+
+IMPORTANT: 読み取り専用のシグナルには、その値の深い変更を防ぐ組み込みのメカニズムは**ありません**。
+
### 算出シグナル
**算出シグナル**は、他のシグナルから値を派生させる読み取り専用のシグナルです。算出シグナルは、`computed`関数を使用して、派生を指定することで定義します。
@@ -89,6 +124,68 @@ const conditionalCount = computed(() => {
依存関係は、派生中に追加されるだけでなく、削除されることもできます。後で`showCount`を再び偽に設定すると、`count`は`conditionalCount`の依存関係として扱われなくなります。
+## リアクティブコンテキスト
+
+**リアクティブコンテキスト**は、Angularがシグナルの読み取りを監視して依存関係を確立する実行時の状態です。シグナルを読み取るコードは_コンシューマー_であり、読み取られるシグナルは_プロデューサー_です。
+
+Angularは次の場合に自動的にリアクティブコンテキストに入ります:
+
+- `effect`、`afterRenderEffect`のコールバックを実行する
+- `computed`シグナルを評価する
+- `linkedSignal`を評価する
+- `resource`のparamsまたはloader関数を評価する
+- コンポーネントテンプレートをレンダリングする([ホストプロパティ](guide/components/host-elements#binding-to-the-host-element)のバインディングを含む)
+
+これらの操作中、Angularは_ライブ_接続を作成します。追跡されたシグナルが変更されると、Angularは_最終的に_コンシューマーを再実行します。
+
+### リアクティブコンテキストをアサートする
+
+Angularは、コードがリアクティブコンテキスト内で実行されていないことをアサートするための`assertNotInReactiveContext`ヘルパー関数を提供します。呼び出し元の関数への参照を渡すことで、アサーションが失敗した場合、エラーメッセージが正しいAPIエントリポイントを指すようにします。これにより、一般的なリアクティブコンテキストエラーよりも明確でアクションにつながるエラーメッセージが生成されます。
+
+```ts
+import {assertNotInReactiveContext} from '@angular/core';
+
+function subscribeToEvents() {
+ assertNotInReactiveContext(subscribeToEvents);
+ // 安全に続行 - サブスクリプションロジックをここに
+}
+```
+
+### 依存関係を追跡せずに読み取る
+
+まれに、`computed`や`effect`などのリアクティブ関数内でシグナルを読み取るコードを実行する必要があり、依存関係を作成しない場合があります。
+
+たとえば、`currentUser`が変更されたときに、`counter`の値をログに記録する必要があるとします。両方のシグナルを読み取る`effect`を作成できます。
+
+```ts
+effect(() => {
+ console.log(`User set to ${currentUser()} and the counter is ${counter()}`);
+});
+```
+
+この例では、`currentUser`または`counter`のいずれかが変更されると、メッセージがログに記録されます。しかし、`currentUser`のみが変更されたときにエフェクトを実行する必要がある場合、`counter`の読み取りは単なる付随的なものであり、`counter`が変更されても新しいメッセージはログに記録されるべきではありません。
+
+シグナルのゲッターを`untracked`で呼び出すことで、シグナルの読み取りが追跡されないようにできます。
+
+```ts
+effect(() => {
+ console.log(`User set to ${currentUser()} and the counter is ${untracked(counter)}`);
+});
+```
+
+`untracked`は、エフェクトが、依存関係として扱われない外部のコードを呼び出す必要がある場合にも役立ちます。
+
+```ts
+effect(() => {
+ const user = currentUser();
+ untracked(() => {
+ // `loggingService`がSignalを読み取っても、
+ // このEffectの依存関係として扱われません。
+ this.loggingService.log(`User set to ${user}`);
+ });
+});
+```
+
## 高度な派生 {#advanced-derivations}
`computed`はシンプルな読み取り専用の派生を処理しますが、他のシグナルに依存する書き込み可能な状態が必要な場合があります。
@@ -98,7 +195,7 @@ const conditionalCount = computed(() => {
## 非リアクティブAPIでの副作用の実行 {#executing-side-effects-on-non-reactive-apis}
-状態の変更に反応したい場合、同期または非同期の派生が推奨されます。しかし、これがすべてのユースケースをカバーするわけではなく、非リアクティブAPIでシグナルの変更に反応する必要がある状況に遭遇することがあります。これらの特定のユースケースには、`effect`または`afterRenderEffect`を使用してください。詳細については、[非リアクティブAPIの副作用](/guide/effect)ガイドを参照してください。
+状態の変更に反応したい場合、同期または非同期の派生が推奨されます。しかし、これがすべての可能なユースケースをカバーするわけではなく、非リアクティブAPIでシグナルの変更に反応する必要がある状況に遭遇することがあります。これらの特定のユースケースには、`effect`または`afterRenderEffect`を使用してください。詳細については、[非リアクティブAPIの副作用](/guide/signals/effect)ガイドを参照してください。
## `OnPush`コンポーネントでのシグナルの読み取り {#reading-signals-in-onpush-components}
@@ -148,41 +245,6 @@ isWritableSignal(count); // true
isWritableSignal(doubled); // false
```
-### 依存関係を追跡せずに読み取る {#reading-without-tracking-dependencies}
-
-まれに、`computed`や`effect`などのリアクティブ関数内でシグナルを読み取るコードを実行する必要があり、依存関係を作成しない場合があります。
-
-たとえば、`currentUser`が変更されたときに、`counter`の値をログに記録する必要があるとします。両方のシグナルを読み取る`effect`を作成できます。
-
-```ts
-effect(() => {
- console.log(`User set to ${currentUser()} and the counter is ${counter()}`);
-});
-```
-
-この例では、`currentUser`または`counter`のいずれかが変更されると、メッセージがログに記録されます。しかし、`currentUser`のみが変更されたときにエフェクトを実行する必要がある場合、`counter`の読み取りは単なる付随的なものであり、`counter`が変更されても新しいメッセージはログに記録されるべきではありません。
-
-シグナルのゲッターを`untracked`で呼び出すことで、シグナルの読み取りが追跡されないようにできます。
-
-```ts
-effect(() => {
- console.log(`User set to ${currentUser()} and the counter is ${untracked(counter)}`);
-});
-```
-
-`untracked`は、エフェクトが、依存関係として扱われない外部のコードを呼び出す必要がある場合にも役立ちます。
-
-```ts
-effect(() => {
- const user = currentUser();
- untracked(() => {
- // `loggingService`がSignalを読み取っても、
- // このEffectの依存関係として扱われません。
- this.loggingService.log(`User set to ${user}`);
- });
-});
-```
-
## RxJSとシグナルを併用する
シグナルとRxJSの相互運用性の詳細については、[RxJSとAngularシグナルの相互運用](ecosystem/rxjs-interop) を参照してください。
diff --git a/adev-ja/src/content/guide/ssr.en.md b/adev-ja/src/content/guide/ssr.en.md
index 3a1b60185b..cb8265a8c8 100644
--- a/adev-ja/src/content/guide/ssr.en.md
+++ b/adev-ja/src/content/guide/ssr.en.md
@@ -30,7 +30,7 @@ You can create a server route config by declaring an array of [`ServerRoute`](ap
```typescript
// app.routes.server.ts
-import { RenderMode, ServerRoute } from '@angular/ssr';
+import {RenderMode, ServerRoute} from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
{
@@ -55,32 +55,29 @@ export const serverRoutes: ServerRoute[] = [
You can add this config to your application with [`provideServerRendering`](api/ssr/provideServerRendering 'API reference') using the [`withRoutes`](api/ssr/withRoutes 'API reference') function:
```typescript
-import { provideServerRendering, withRoutes } from '@angular/ssr';
-import { serverRoutes } from './app.routes.server';
+import {provideServerRendering, withRoutes} from '@angular/ssr';
+import {serverRoutes} from './app.routes.server';
// app.config.server.ts
const serverConfig: ApplicationConfig = {
providers: [
provideServerRendering(withRoutes(serverRoutes)),
// ... other providers ...
- ]
+ ],
};
```
When using the [App shell pattern](ecosystem/service-workers/app-shell), you must specify the component to be used as the app shell for client-side rendered routes. To do this, use the [`withAppShell`](api/ssr/withAppShell 'API reference') feature:
```typescript
-import { provideServerRendering, withRoutes, withAppShell } from '@angular/ssr';
-import { AppShellComponent } from './app-shell/app-shell.component';
+import {provideServerRendering, withRoutes, withAppShell} from '@angular/ssr';
+import {AppShellComponent} from './app-shell/app-shell.component';
const serverConfig: ApplicationConfig = {
providers: [
- provideServerRendering(
- withRoutes(serverRoutes),
- withAppShell(AppShellComponent),
- ),
+ provideServerRendering(withRoutes(serverRoutes), withAppShell(AppShellComponent)),
// ... other providers ...
- ]
+ ],
};
```
@@ -142,7 +139,7 @@ You can set custom headers and status codes for individual server routes using t
```typescript
// app.routes.server.ts
-import { RenderMode, ServerRoute } from '@angular/ssr';
+import {RenderMode, ServerRoute} from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
{
@@ -183,7 +180,7 @@ You can also use this function with catch-all routes (e.g., `/**`), where the pa
```ts
// app.routes.server.ts
-import { RenderMode, ServerRoute } from '@angular/ssr';
+import {RenderMode, ServerRoute} from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
{
@@ -193,7 +190,7 @@ export const serverRoutes: ServerRoute[] = [
const dataService = inject(PostService);
const ids = await dataService.getIds(); // Assuming this returns ['1', '2', '3']
- return ids.map(id => ({ id })); // Generates paths like: /post/1, /post/2, /post/3
+ return ids.map((id) => ({id})); // Generates paths like: /post/1, /post/2, /post/3
},
},
{
@@ -201,8 +198,8 @@ export const serverRoutes: ServerRoute[] = [
renderMode: RenderMode.Prerender,
async getPrerenderParams() {
return [
- { id: '1', '**': 'foo/3' },
- { id: '2', '**': 'bar/4' },
+ {id: '1', '**': 'foo/3'},
+ {id: '2', '**': 'bar/4'},
]; // Generates paths like: /post/1/foo/3, /post/2/bar/4
},
},
@@ -225,7 +222,7 @@ The available fallback strategies are:
```ts
// app.routes.server.ts
-import { RenderMode, PrerenderFallback, ServerRoute } from '@angular/ssr';
+import {RenderMode, PrerenderFallback, ServerRoute} from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
{
@@ -236,7 +233,7 @@ export const serverRoutes: ServerRoute[] = [
// This function returns an array of objects representing prerendered posts at the paths:
// `/post/1`, `/post/2`, and `/post/3`.
// The path `/post/4` will utilize the fallback behavior if it's requested.
- return [{ id: 1 }, { id: 2 }, { id: 3 }];
+ return [{id: 1}, {id: 2}, {id: 3}];
},
},
];
@@ -315,9 +312,7 @@ Register the browser implementation in your main application configuration:
```ts
// app.config.ts
export const appConfig: ApplicationConfig = {
- providers: [
- { provide: AnalyticsService, useClass: BrowserAnalyticsService },
- ]
+ providers: [{provide: AnalyticsService, useClass: BrowserAnalyticsService}],
};
```
@@ -326,16 +321,16 @@ Override with the server implementation in your server configuration:
```ts
// app.config.server.ts
const serverConfig: ApplicationConfig = {
- providers: [
- { provide: AnalyticsService, useClass: ServerAnalyticsService },
- ]
+ providers: [{provide: AnalyticsService, useClass: ServerAnalyticsService}],
};
```
Inject and use the service in your components:
```ts
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
export class Checkout {
private analytics = inject(AnalyticsService);
@@ -350,9 +345,9 @@ export class Checkout {
When working with server-side rendering, you should avoid directly referencing browser-specific globals like `document`. Instead, use the [`DOCUMENT`](api/core/DOCUMENT) token to access the document object in a platform-agnostic way.
```ts
-import { Injectable, inject, DOCUMENT } from '@angular/core';
+import {Injectable, inject, DOCUMENT} from '@angular/core';
-@Injectable({ providedIn: 'root' })
+@Injectable({providedIn: 'root'})
export class CanonicalLinkService {
private readonly document = inject(DOCUMENT);
@@ -365,7 +360,6 @@ export class CanonicalLinkService {
this.document.head.appendChild(link);
}
}
-
```
HELPFUL: For managing meta tags, Angular provides the `Meta` service.
@@ -436,8 +430,8 @@ This configuration is provided globally using `withHttpTransferCacheOptions` ins
By default, `HttpClient` caches all `HEAD` and `GET` requests which don't contain `Authorization` or `Proxy-Authorization` headers. You can override those settings by using `withHttpTransferCacheOptions` to the hydration configuration.
```ts
-import { bootstrapApplication } from '@angular/platform-browser';
-import { provideClientHydration, withHttpTransferCacheOptions } from '@angular/platform-browser';
+import {bootstrapApplication} from '@angular/platform-browser';
+import {provideClientHydration, withHttpTransferCacheOptions} from '@angular/platform-browser';
bootstrapApplication(AppComponent, {
providers: [
@@ -504,7 +498,7 @@ You can override caching behavior for a specific request using the `transferCach
```ts
// Include specific headers for this request
-http.get('/api/profile', { transferCache: { includeHeaders: ['CustomHeader'] } });
+http.get('/api/profile', {transferCache: {includeHeaders: ['CustomHeader']}});
```
### Disabling caching
@@ -516,12 +510,14 @@ You can disable HTTP caching of requests sent from the server either globally or
To disable caching for all requests in your application, use the `withNoHttpTransferCache` feature:
```ts
-import { bootstrapApplication, provideClientHydration, withNoHttpTransferCache } from '@angular/platform-browser';
+import {
+ bootstrapApplication,
+ provideClientHydration,
+ withNoHttpTransferCache,
+} from '@angular/platform-browser';
bootstrapApplication(AppComponent, {
- providers: [
- provideClientHydration(withNoHttpTransferCache())
- ]
+ providers: [provideClientHydration(withNoHttpTransferCache())],
});
```
@@ -530,14 +526,20 @@ bootstrapApplication(AppComponent, {
You can also selectively disable caching for certain requests using the [`filter`](api/common/http/HttpTransferCacheOptions) option in `withHttpTransferCacheOptions`. For example, you can disable caching for a specific API endpoint:
```ts
-import { bootstrapApplication, provideClientHydration, withHttpTransferCacheOptions } from '@angular/platform-browser';
+import {
+ bootstrapApplication,
+ provideClientHydration,
+ withHttpTransferCacheOptions,
+} from '@angular/platform-browser';
bootstrapApplication(AppComponent, {
providers: [
- provideClientHydration(withHttpTransferCacheOptions({
- filter: (req) => !req.url.includes('/api/sensitive-data')
- }))
- ]
+ provideClientHydration(
+ withHttpTransferCacheOptions({
+ filter: (req) => !req.url.includes('/api/sensitive-data'),
+ }),
+ ),
+ ],
});
```
@@ -548,7 +550,7 @@ Use this option to exclude endpoints with user‑specific or dynamic data (for e
To disable caching for an individual request, you can specify the [`transferCache`](api/common/http/HttpRequest#transferCache) option in an `HttpRequest`.
```ts
-httpClient.get('/api/sensitive-data', { transferCache: false });
+httpClient.get('/api/sensitive-data', {transferCache: false});
```
NOTE: If your application uses different HTTP origins to make API calls on the server and on the client, the `HTTP_TRANSFER_CACHE_ORIGIN_MAP` token allows you to establish a mapping between those origins, so that `HttpTransferCache` feature can recognize those requests as the same ones and reuse the data cached on the server during hydration on the client.
@@ -561,7 +563,11 @@ The `@angular/ssr/node` extends `@angular/ssr` specifically for Node.js environm
```ts
// server.ts
-import { AngularNodeAppEngine, createNodeRequestHandler, writeResponseToNodeResponse } from '@angular/ssr/node';
+import {
+ AngularNodeAppEngine,
+ createNodeRequestHandler,
+ writeResponseToNodeResponse,
+} from '@angular/ssr/node';
import express from 'express';
const app = express();
@@ -570,7 +576,7 @@ const angularApp = new AngularNodeAppEngine();
app.use('*', (req, res, next) => {
angularApp
.handle(req)
- .then(response => {
+ .then((response) => {
if (response) {
writeResponseToNodeResponse(response, res);
} else {
@@ -592,7 +598,7 @@ The `@angular/ssr` provides essential APIs for server-side rendering your Angula
```ts
// server.ts
-import { AngularAppEngine, createRequestHandler } from '@angular/ssr';
+import {AngularAppEngine, createRequestHandler} from '@angular/ssr';
const angularApp = new AngularAppEngine();
@@ -600,7 +606,7 @@ const angularApp = new AngularAppEngine();
* This is a request handler used by the Angular CLI (dev-server and during build).
*/
export const reqHandler = createRequestHandler(async (req: Request) => {
- const res: Response|null = await angularApp.render(req);
+ const res: Response | null = await angularApp.render(req);
// ...
});
diff --git a/adev-ja/src/content/guide/ssr.md b/adev-ja/src/content/guide/ssr.md
index c2fb3c83dc..ec5c41c6ad 100644
--- a/adev-ja/src/content/guide/ssr.md
+++ b/adev-ja/src/content/guide/ssr.md
@@ -30,7 +30,7 @@ NOTE: デフォルトでは、Angularはアプリケーション全体をプリ
```typescript
// app.routes.server.ts
-import { RenderMode, ServerRoute } from '@angular/ssr';
+import {RenderMode, ServerRoute} from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
{
@@ -55,32 +55,29 @@ export const serverRoutes: ServerRoute[] = [
この設定は、[`withRoutes`](api/ssr/withRoutes 'API reference') 関数を使用して [`provideServerRendering`](api/ssr/provideServerRendering 'API reference') でアプリケーションに追加できます。
```typescript
-import { provideServerRendering, withRoutes } from '@angular/ssr';
-import { serverRoutes } from './app.routes.server';
+import {provideServerRendering, withRoutes} from '@angular/ssr';
+import {serverRoutes} from './app.routes.server';
// app.config.server.ts
const serverConfig: ApplicationConfig = {
providers: [
provideServerRendering(withRoutes(serverRoutes)),
// ... その他のプロバイダー ...
- ]
+ ],
};
```
[App shellパターン](ecosystem/service-workers/app-shell)を使用する場合、クライアントサイドレンダリングされたルートのApp shellとして使用するコンポーネントを指定する必要があります。これを行うには、[`withAppShell`](api/ssr/withAppShell 'API reference') 機能を使用します。
```typescript
-import { provideServerRendering, withRoutes, withAppShell } from '@angular/ssr';
-import { AppShellComponent } from './app-shell/app-shell.component';
+import {provideServerRendering, withRoutes, withAppShell} from '@angular/ssr';
+import {AppShellComponent} from './app-shell/app-shell.component';
const serverConfig: ApplicationConfig = {
providers: [
- provideServerRendering(
- withRoutes(serverRoutes),
- withAppShell(AppShellComponent),
- ),
+ provideServerRendering(withRoutes(serverRoutes), withAppShell(AppShellComponent)),
// ... その他のプロバイダー ...
- ]
+ ],
};
```
@@ -142,7 +139,7 @@ NOTE: Angular Service Workerを使用する場合、最初のリクエストは
```typescript
// app.routes.server.ts
-import { RenderMode, ServerRoute } from '@angular/ssr';
+import {RenderMode, ServerRoute} from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
{
@@ -183,7 +180,7 @@ Angularは、ルート設定の [`redirectTo`](api/router/Route#redirectTo 'API
```ts
// app.routes.server.ts
-import { RenderMode, ServerRoute } from '@angular/ssr';
+import {RenderMode, ServerRoute} from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
{
@@ -193,7 +190,7 @@ export const serverRoutes: ServerRoute[] = [
const dataService = inject(PostService);
const ids = await dataService.getIds(); // これは ['1', '2', '3'] を返すと仮定します
- return ids.map(id => ({ id })); // /post/1, /post/2, /post/3 のようなパスを生成します
+ return ids.map((id) => ({id})); // /post/1, /post/2, /post/3 のようなパスを生成します
},
},
{
@@ -201,8 +198,8 @@ export const serverRoutes: ServerRoute[] = [
renderMode: RenderMode.Prerender,
async getPrerenderParams() {
return [
- { id: '1', '**': 'foo/3' },
- { id: '2', '**': 'bar/4' },
+ {id: '1', '**': 'foo/3'},
+ {id: '2', '**': 'bar/4'},
]; // /post/1/foo/3, /post/2/bar/4 のようなパスを生成します
},
},
@@ -225,7 +222,7 @@ IMPORTANT: `getPrerenderParams` 内で [`inject`](api/core/inject 'API reference
```ts
// app.routes.server.ts
-import { RenderMode, PrerenderFallback, ServerRoute } from '@angular/ssr';
+import {RenderMode, PrerenderFallback, ServerRoute} from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
{
@@ -236,7 +233,7 @@ export const serverRoutes: ServerRoute[] = [
// この関数は、/post/1、/post/2、/post/3 のパスで
// プリレンダリングされた投稿を表すオブジェクトの配列を返します。
// /post/4 のパスがリクエストされた場合、フォールバック動作が利用されます。
- return [{ id: 1 }, { id: 2 }, { id: 3 }];
+ return [{id: 1}, {id: 2}, {id: 3}];
},
},
];
@@ -315,9 +312,7 @@ export class ServerAnalyticsService implements AnalyticsService {
```ts
// app.config.ts
export const appConfig: ApplicationConfig = {
- providers: [
- { provide: AnalyticsService, useClass: BrowserAnalyticsService },
- ]
+ providers: [{provide: AnalyticsService, useClass: BrowserAnalyticsService}],
};
```
@@ -326,16 +321,16 @@ export const appConfig: ApplicationConfig = {
```ts
// app.config.server.ts
const serverConfig: ApplicationConfig = {
- providers: [
- { provide: AnalyticsService, useClass: ServerAnalyticsService },
- ]
+ providers: [{provide: AnalyticsService, useClass: ServerAnalyticsService}],
};
```
コンポーネントでサービスを注入して使用します。
```ts
-@Component({/* ... */})
+@Component({
+ /* ... */
+})
export class Checkout {
private analytics = inject(AnalyticsService);
@@ -350,9 +345,9 @@ export class Checkout {
サーバーサイドレンダリングを使用する場合、`document` のようなブラウザ固有のグローバルを直接参照することは避けるべきです。代わりに、[`DOCUMENT`](api/core/DOCUMENT) トークンを使用して、プラットフォームに依存しない方法でdocumentオブジェクトにアクセスします。
```ts
-import { Injectable, inject, DOCUMENT } from '@angular/core';
+import {Injectable, inject, DOCUMENT} from '@angular/core';
-@Injectable({ providedIn: 'root' })
+@Injectable({providedIn: 'root'})
export class CanonicalLinkService {
private readonly document = inject(DOCUMENT);
@@ -365,7 +360,6 @@ export class CanonicalLinkService {
this.document.head.appendChild(link);
}
}
-
```
HELPFUL: メタタグの管理には、Angularは `Meta` サービスを提供しています。
@@ -436,8 +430,8 @@ IMPORTANT: 上記のトークンは、次のシナリオでは `null` になり
デフォルトでは、`HttpClient` は `Authorization` または `Proxy-Authorization` ヘッダーを含まないすべての `HEAD` および `GET` リクエストをキャッシュします。ハイドレーション設定に `withHttpTransferCacheOptions` を使用することで、これらの設定をオーバーライドできます。
```ts
-import { bootstrapApplication } from '@angular/platform-browser';
-import { provideClientHydration, withHttpTransferCacheOptions } from '@angular/platform-browser';
+import {bootstrapApplication} from '@angular/platform-browser';
+import {provideClientHydration, withHttpTransferCacheOptions} from '@angular/platform-browser';
bootstrapApplication(AppComponent, {
providers: [
@@ -504,7 +498,7 @@ withHttpTransferCacheOptions({
```ts
// このリクエストに特定のヘッダーを含める
-http.get('/api/profile', { transferCache: { includeHeaders: ['CustomHeader'] } });
+http.get('/api/profile', {transferCache: {includeHeaders: ['CustomHeader']}});
```
### キャッシュの無効化 {#disabling-caching}
@@ -516,12 +510,14 @@ http.get('/api/profile', { transferCache: { includeHeaders: ['CustomHeader'] } }
アプリケーション内のすべてのリクエストのキャッシュを無効にするには、`withNoHttpTransferCache` 機能を使用します。
```ts
-import { bootstrapApplication, provideClientHydration, withNoHttpTransferCache } from '@angular/platform-browser';
+import {
+ bootstrapApplication,
+ provideClientHydration,
+ withNoHttpTransferCache,
+} from '@angular/platform-browser';
bootstrapApplication(AppComponent, {
- providers: [
- provideClientHydration(withNoHttpTransferCache())
- ]
+ providers: [provideClientHydration(withNoHttpTransferCache())],
});
```
@@ -530,14 +526,20 @@ bootstrapApplication(AppComponent, {
`withHttpTransferCacheOptions` の [`filter`](api/common/http/HttpTransferCacheOptions) オプションを使用して、特定のリクエストのキャッシュを選択的に無効にできます。たとえば、特定のAPIエンドポイントのキャッシュを無効にできます。
```ts
-import { bootstrapApplication, provideClientHydration, withHttpTransferCacheOptions } from '@angular/platform-browser';
+import {
+ bootstrapApplication,
+ provideClientHydration,
+ withHttpTransferCacheOptions,
+} from '@angular/platform-browser';
bootstrapApplication(AppComponent, {
providers: [
- provideClientHydration(withHttpTransferCacheOptions({
- filter: (req) => !req.url.includes('/api/sensitive-data')
- }))
- ]
+ provideClientHydration(
+ withHttpTransferCacheOptions({
+ filter: (req) => !req.url.includes('/api/sensitive-data'),
+ }),
+ ),
+ ],
});
```
@@ -548,7 +550,7 @@ bootstrapApplication(AppComponent, {
個々のリクエストのキャッシュを無効にするには、`HttpRequest` で [`transferCache`](api/common/http/HttpRequest#transferCache) オプションを指定できます。
```ts
-httpClient.get('/api/sensitive-data', { transferCache: false });
+httpClient.get('/api/sensitive-data', {transferCache: false});
```
NOTE: アプリケーションがサーバーとクライアントで異なるHTTPオリジンを使用してAPIコールを行う場合、`HTTP_TRANSFER_CACHE_ORIGIN_MAP`トークンを使用してそれらのオリジン間のマッピングを確立できます。これにより、`HttpTransferCache`機能がそれらのリクエストを同じものとして認識し、クライアントでのハイドレーション中にサーバーでキャッシュされたデータを再利用できます。
@@ -561,7 +563,11 @@ NOTE: アプリケーションがサーバーとクライアントで異なるHT
```ts
// server.ts
-import { AngularNodeAppEngine, createNodeRequestHandler, writeResponseToNodeResponse } from '@angular/ssr/node';
+import {
+ AngularNodeAppEngine,
+ createNodeRequestHandler,
+ writeResponseToNodeResponse,
+} from '@angular/ssr/node';
import express from 'express';
const app = express();
@@ -570,7 +576,7 @@ const angularApp = new AngularNodeAppEngine();
app.use('*', (req, res, next) => {
angularApp
.handle(req)
- .then(response => {
+ .then((response) => {
if (response) {
writeResponseToNodeResponse(response, res);
} else {
@@ -592,7 +598,7 @@ export const reqHandler = createNodeRequestHandler(app);
```ts
// server.ts
-import { AngularAppEngine, createRequestHandler } from '@angular/ssr';
+import {AngularAppEngine, createRequestHandler} from '@angular/ssr';
const angularApp = new AngularAppEngine();
@@ -600,7 +606,7 @@ const angularApp = new AngularAppEngine();
* これは、Angular CLI (開発サーバーおよびビルド時) で使用されるリクエストハンドラーです。
*/
export const reqHandler = createRequestHandler(async (req: Request) => {
- const res: Response|null = await angularApp.render(req);
+ const res: Response | null = await angularApp.render(req);
// ...
});
diff --git a/adev-ja/src/content/guide/tailwind.en.md b/adev-ja/src/content/guide/tailwind.en.md
index b0b6e85ba1..36cd034d9f 100644
--- a/adev-ja/src/content/guide/tailwind.en.md
+++ b/adev-ja/src/content/guide/tailwind.en.md
@@ -58,7 +58,6 @@ Next, add a `.postcssrc.json` file in the file root of the project.
Add the `@tailwindcss/postcss` plugin into your PostCSS configuration.
```json {header: '.postcssrc.json'}
-
{
"plugins": {
"@tailwindcss/postcss": {}
@@ -70,15 +69,15 @@ Add the `@tailwindcss/postcss` plugin into your PostCSS configuration.
Add an `@import` to `./src/styles.css` that imports Tailwind CSS.
-
-@import "tailwindcss";
-
+```css {header: "src/styles.css"}
+@import 'tailwindcss';
+```
If you're using SCSS, add `@use` to `./src/styles.scss`.
-
-@use "tailwindcss";
-
+```scss {header: "src/styles.scss"}
+@use 'tailwindcss';
+```
### 5. Start using Tailwind in your project
@@ -87,9 +86,7 @@ You can now start using Tailwind's utility classes in your component templates t
For example, you can add the following to your `app.html` file:
```html
-
-@import "tailwindcss";
-
+```css {header: "src/styles.css"}
+@import 'tailwindcss';
+```
SCSSを使用している場合は、`@use`を`./src/styles.scss`に追加します。
-
-@use "tailwindcss";
-
+```scss {header: "src/styles.scss"}
+@use 'tailwindcss';
+```
### 5. プロジェクトでTailwindを使い始める {#start-using-tailwind-in-your-project}
@@ -87,9 +86,7 @@ SCSSを使用している場合は、`@use`を`./src/styles.scss`に追加しま
たとえば、次の内容を`app.html`ファイルに追加できます:
```html
-` element with `NgTemplateOutlet`:
diff --git a/adev-ja/src/content/guide/templates/ng-template.md b/adev-ja/src/content/guide/templates/ng-template.md
index 2fd16ce5f3..34586b0ea1 100644
--- a/adev-ja/src/content/guide/templates/ng-template.md
+++ b/adev-ja/src/content/guide/templates/ng-template.md
@@ -137,7 +137,7 @@ export class MyDirective {
まず、`NgTemplateOutlet` をインポートします:
```typescript
-import { NgTemplateOutlet } from '@angular/common';
+import {NgTemplateOutlet} from '@angular/common';
```
次の例では、テンプレートフラグメントを宣言し、そのフラグメントを `NgTemplateOutlet` を使用して `` 要素にレンダリングします。
diff --git a/adev-ja/src/content/guide/testing/attribute-directives.en.md b/adev-ja/src/content/guide/testing/attribute-directives.en.md
index d3b4e91735..1613929010 100644
--- a/adev-ja/src/content/guide/testing/attribute-directives.en.md
+++ b/adev-ja/src/content/guide/testing/attribute-directives.en.md
@@ -3,20 +3,65 @@
An _attribute directive_ modifies the behavior of an element, component or another directive.
Its name reflects the way the directive is applied: as an attribute on a host element.
-## Testing the `HighlightDirective`
+## Testing the `Highlight` directive
-The sample application's `HighlightDirective` sets the background color of an element based on either a data bound color or a default color \(lightgray\).
+The sample application's `Highlight` directive sets the background color of an element based on either a data bound color or a default color \(lightgray\).
It also sets a custom property of the element \(`customProperty`\) to `true` for no reason other than to show that it can.
-;
+
+beforeEach(async () => {
+ TestBed.configureTestingModule({
+ providers: [TwainService, UserService],
+ schemas: [CUSTOM_ELEMENTS_SCHEMA],
+ });
+ fixture = TestBed.createComponent(About);
+ await fixture.whenStable();
+});
+
+it('should have skyblue ', () => {
+ const h2: HTMLElement = fixture.nativeElement.querySelector('h2');
+ const bgColor = h2.style.backgroundColor;
+ expect(bgColor).toBe('skyblue');
+});
+```
However, testing a single use case is unlikely to explore the full range of a directive's capabilities.
Finding and testing all components that use the directive is tedious, brittle, and almost as unlikely to afford full coverage.
@@ -26,16 +71,75 @@ Isolated unit tests don't touch the DOM and, therefore, do not inspire confidenc
A better solution is to create an artificial test component that demonstrates all ways to apply the directive.
-
Version: {{ config.version }}
` + template: `Version: {{ config.version }}
`, }) export class HeaderComponent { config = inject(APP_CONFIG); // Automatically available @@ -77,8 +77,8 @@ InjectionToken with factory functions is ideal when you can't use a class but ne ```ts // 📁 /app/logger.token.ts -import { InjectionToken, inject } from '@angular/core'; -import { APP_CONFIG } from './config.token'; +import {InjectionToken, inject} from '@angular/core'; +import {APP_CONFIG} from './config.token'; // Logger function type export type LoggerFn = (level: string, message: string) => void; @@ -94,19 +94,19 @@ export const LOGGER_FN = new InjectionToken{{ title }}
` + template: `{{ title }}
`, }) export class HeaderComponent { private config = inject(APP_CONFIG); @@ -512,15 +504,15 @@ providers: [ { provide: LoggerService, useFactory: loggerFactory, - deps: [APP_CONFIG] // Dependencies for the factory function - } -] + deps: [APP_CONFIG], // Dependencies for the factory function + }, +]; ``` You can mark factory dependencies as optional: ```ts -import { Optional } from '@angular/core'; +import {Optional} from '@angular/core'; providers: [ { @@ -528,9 +520,9 @@ providers: [ useFactory: (required: RequiredService, optional?: OptionalService) => { return new MyService(required, optional || new DefaultService()); }, - deps: [RequiredService, [new Optional(), OptionalService]] - } -] + deps: [RequiredService, [new Optional(), OptionalService]], + }, +]; ``` #### Practical example: Configuration-based API client @@ -543,7 +535,7 @@ class ApiClient { constructor( private http: HttpClient, private baseUrl: string, - private rateLimitMs: number + private rateLimitMs: number, ) {} async fetchData(endpoint: string) { @@ -554,13 +546,13 @@ class ApiClient { private async applyRateLimit() { // Simplified example - real implementation would track request timing - return new Promise(resolve => setTimeout(resolve, this.rateLimitMs)); + return new Promise((resolve) => setTimeout(resolve, this.rateLimitMs)); } } // Factory function that configures based on user tier -import { inject } from '@angular/core'; -import { HttpClient } from '@angular/common/http'; +import {inject} from '@angular/core'; +import {HttpClient} from '@angular/common/http'; const apiClientFactory = () => { const http = inject(HttpClient); const userService = inject(UserService); @@ -575,13 +567,13 @@ const apiClientFactory = () => { // Provider configuration export const apiClientProvider = { provide: ApiClient, - useFactory: apiClientFactory + useFactory: apiClientFactory, }; // Usage in component @Component({ selector: 'app-dashboard', - providers: [apiClientProvider] + providers: [apiClientProvider], }) export class DashboardComponent { private apiClient = inject(ApiClient); @@ -594,9 +586,9 @@ export class DashboardComponent { ```ts providers: [ - NewLogger, // The actual service - { provide: OldLogger, useExisting: NewLogger } // The alias -] + NewLogger, // The actual service + {provide: OldLogger, useExisting: NewLogger}, // The alias +]; ``` IMPORTANT: Don't confuse `useExisting` with `useClass`. `useClass` creates separate instances, while `useExisting` ensures you get the same singleton instance. @@ -609,10 +601,10 @@ Use the `multi: true` flag when multiple providers contribute values to the same export const INTERCEPTOR_TOKEN = new InjectionTokenEmoji from AnimalService: {{animal.emoji}}
s +Emoji from AnimalService: {{animal.emoji}}
+s ``` Now you should see both values in the browser: @@ -757,7 +754,7 @@ To alter where the injector starts looking for `FlowerService`, add `skipSelf` t This invocation is a property initializer the `Emoji from AnimalService: {{animal.emoji}}
s +Emoji from AnimalService: {{animal.emoji}}
+s ``` これで、ブラウザに両方の値が表示されます。 @@ -757,7 +754,7 @@ Emoji from AnimalService: 🐶 この呼び出しは、`child.component.ts` に示すように、`
@for (list of lists; track list) {
-
+
}
```
@@ -125,11 +125,11 @@ You can associate some arbitrary data with both `cdkDrag` and `cdkDropList` by s
```html
@for (list of lists; track list) {
-
- @for (item of list; track item) {
-
- }
-
+
+ @for (item of list; track item) {
+
+ }
+
}
```
diff --git a/adev-ja/src/content/guide/elements.en.md b/adev-ja/src/content/guide/elements.en.md
index 9b63ff0939..90bb9d2e34 100644
--- a/adev-ja/src/content/guide/elements.en.md
+++ b/adev-ja/src/content/guide/elements.en.md
@@ -39,9 +39,7 @@ The `createCustomElement()` function converts a component into a class that can
After you register your configured class with the browser's custom-element registry, use the new element just like a built-in HTML element in content that you add directly into the DOM:
```html
-
+
```
#### Responsive images
@@ -266,17 +238,13 @@ providers: [
If you would like to manually define a `srcset` attribute, you can provide your own using the `ngSrcset` attribute:
```html
-
-
+
```
#### レスポンシブ画像 {#responsive-images}
@@ -266,17 +238,13 @@ providers: [
`srcset`属性を手動で定義したい場合、`ngSrcset`属性を使用して独自のものを指定できます:
```html
-
-Loading...
+ @if (isNavigating()) {
+
}
+ Loading...
+ @if (isNavigating()) {
+
}
+ Protected Page
' }) +import {RouterTestingHarness} from '@angular/router/testing'; +import {provideRouter, Router} from '@angular/router'; +import {authGuard} from './auth.guard'; +import {AuthStore} from './auth-store'; +import {Component} from '@angular/core'; +import {TestBed} from '@angular/core/testing'; + +@Component({template: 'Protected Page
'}) class ProtectedComponent {} -@Component({ template: 'Login Page
' }) +@Component({template: 'Login Page
'}) class LoginComponent {} describe('authGuard', () => { @@ -91,10 +86,10 @@ describe('authGuard', () => { TestBed.configureTestingModule({ providers: [ - { provide: AuthStore, useValue: authStore }, + {provide: AuthStore, useValue: authStore}, provideRouter([ - { path: 'protected', component: ProtectedComponent, canActivate: [authGuard] }, - { path: 'login', component: LoginComponent }, + {path: 'protected', component: ProtectedComponent, canActivate: [authGuard]}, + {path: 'login', component: LoginComponent}, ]), ], }); @@ -120,9 +115,9 @@ describe('authGuard', () => { ```ts // auth.guard.ts -import { inject } from '@angular/core'; -import { CanActivateFn, Router } from '@angular/router'; -import { AuthStore } from './auth-store'; +import {inject} from '@angular/core'; +import {CanActivateFn, Router} from '@angular/router'; +import {AuthStore} from './auth-store'; export const authGuard: CanActivateFn = () => { const authStore = inject(AuthStore); @@ -139,19 +134,19 @@ Here's an example of how to set up a test that verifies different components are ```ts // app.component.spec.ts -import { TestBed } from '@angular/core/testing'; -import { RouterTestingHarness } from '@angular/router/testing'; -import { provideRouter } from '@angular/router'; -import { Component } from '@angular/core'; -import { App } from './app'; +import {TestBed} from '@angular/core/testing'; +import {RouterTestingHarness} from '@angular/router/testing'; +import {provideRouter} from '@angular/router'; +import {Component} from '@angular/core'; +import {App} from './app'; @Component({ - template: 'Home Page
' + template: 'Home Page
', }) class MockHome {} @Component({ - template: 'About Page
' + template: 'About Page
', }) class MockAbout {} @@ -163,10 +158,10 @@ describe('App Router Outlet', () => { imports: [App], providers: [ provideRouter([ - { path: '', component: MockHome }, - { path: 'about', component: MockAbout } - ]) - ] + {path: '', component: MockHome}, + {path: 'about', component: MockAbout}, + ]), + ], }); harness = await RouterTestingHarness.create(); @@ -218,10 +213,10 @@ Here's an example of testing a parent-child route structure: ```ts // nested-routes.spec.ts -import { TestBed } from '@angular/core/testing'; -import { RouterTestingHarness } from '@angular/router/testing'; -import { provideRouter } from '@angular/router'; -import { Parent, Child } from './nested-components'; +import {TestBed} from '@angular/core/testing'; +import {RouterTestingHarness} from '@angular/router/testing'; +import {provideRouter} from '@angular/router'; +import {Parent, Child} from './nested-components'; describe('Nested Routes', () => { let harness: RouterTestingHarness; @@ -234,12 +229,10 @@ describe('Nested Routes', () => { { path: 'parent', component: Parent, - children: [ - { path: 'child', component: Child } - ] - } - ]) - ] + children: [{path: 'child', component: Child}], + }, + ]), + ], }); harness = await RouterTestingHarness.create(); @@ -284,10 +277,10 @@ Here's an example of how to test query parameters and fragments: ```ts // search.component.spec.ts -import { TestBed } from '@angular/core/testing'; -import { Router, provideRouter } from '@angular/router'; -import { RouterTestingHarness } from '@angular/router/testing'; -import { Search } from './search'; +import {TestBed} from '@angular/core/testing'; +import {Router, provideRouter} from '@angular/router'; +import {RouterTestingHarness} from '@angular/router/testing'; +import {Search} from './search'; describe('Search', () => { let component: Search; @@ -296,11 +289,7 @@ describe('Search', () => { beforeEach(async () => { TestBed.configureTestingModule({ imports: [Search], - providers: [ - provideRouter([ - { path: 'search', component: Search } - ]) - ] + providers: [provideRouter([{path: 'search', component: Search}])], }); harness = await RouterTestingHarness.create(); @@ -336,6 +325,6 @@ export class Search { 1. **Use RouterTestingHarness** - For testing routed components, use [`RouterTestingHarness`](api/router/testing/RouterTestingHarness) which provides a cleaner API and eliminates the need for test host components. It offers direct component access, built-in navigation, and better type safety. However, it isn't as suitable for some scenarios, such as testing named outlets, where you may need to create custom host components. 2. **Handle external dependencies thoughtfully** - Prefer real implementations when possible for more realistic tests. If real implementations aren't feasible (e.g., external APIs), use fakes that approximate the real behavior. Use mocks or stubs only as a last resort, as they can make tests brittle and less reliable. 3. **Test navigation state** - Verify both the navigation action and the resulting application state, including URL changes and component rendering. -4. **Handle asynchronous operations** - Router navigation is asynchronous. Use `async/await` or [`fakeAsync`](api/core/testing/fakeAsync) to properly handle timing in your tests. +4. **Handle asynchronous operations** - Router navigation is asynchronous. Use `async/await` to properly handle timing in your tests. 5. **Test error scenarios** - Include tests for invalid routes, failed navigation, and guard rejections to ensure your application handles edge cases gracefully. 6. **Do not mock Angular Router** - Instead, provide real route configurations and use the harness to navigate. This makes your tests more robust and less likely to break on internal Angular updates, while also ensuring you catch real issues when the router updates since mocks can hide breaking changes. diff --git a/adev-ja/src/content/guide/routing/testing.md b/adev-ja/src/content/guide/routing/testing.md index 324c30c227..b3977de749 100644 --- a/adev-ja/src/content/guide/routing/testing.md +++ b/adev-ja/src/content/guide/routing/testing.md @@ -6,8 +6,7 @@ このガイドは、以下のツールとライブラリに精通していることを前提としています。 -- **[Jasmine](https://jasmine.github.io/)** - テスト構文（`describe`、`it`、`expect`）を提供するJavaScriptテストフレームワーク -- **[Karma](https://karma-runner.github.io/)** - ブラウザでテストを実行するテストランナー +- **[Vitest](https://vitest.dev/)** - テスト構文（`describe`、`it`、`expect`）を提供するJavaScriptテストフレームワーク - **[Angular Testing Utilities](guide/testing)** - Angularに組み込まれているテストツール（[`TestBed`](api/core/testing/TestBed)、[`ComponentFixture`](api/core/testing/ComponentFixture)） - **[`RouterTestingHarness`](api/router/testing/RouterTestingHarness)** - 組み込みのナビゲーションとコンポーネントテスト機能を備えた、ルーティングされたコンポーネントをテストするためのテストハーネス @@ -21,21 +20,17 @@ ```ts // user-profile.component.spec.ts -import { TestBed } from '@angular/core/testing'; -import { Router } from '@angular/router'; -import { RouterTestingHarness } from '@angular/router/testing'; -import { provideRouter } from '@angular/router'; -import { UserProfile } from './user-profile'; +import {TestBed} from '@angular/core/testing'; +import {Router} from '@angular/router'; +import {RouterTestingHarness} from '@angular/router/testing'; +import {provideRouter} from '@angular/router'; +import {UserProfile} from './user-profile'; describe('UserProfile', () => { it('should display user ID from route parameters', async () => { TestBed.configureTestingModule({ imports: [UserProfile], - providers: [ - provideRouter([ - { path: 'user/:id', component: UserProfile } - ]) - ] + providers: [provideRouter([{path: 'user/:id', component: UserProfile}])], }); const harness = await RouterTestingHarness.create(); @@ -68,17 +63,17 @@ export class UserProfile { ```ts // auth.guard.spec.ts -import { RouterTestingHarness } from '@angular/router/testing'; -import { provideRouter, Router } from '@angular/router'; -import { authGuard } from './auth.guard'; -import { AuthStore } from './auth-store'; -import { Component } from '@angular/core'; -import { TestBed } from '@angular/core/testing'; - -@Component({ template: 'Protected Page
' }) +import {RouterTestingHarness} from '@angular/router/testing'; +import {provideRouter, Router} from '@angular/router'; +import {authGuard} from './auth.guard'; +import {AuthStore} from './auth-store'; +import {Component} from '@angular/core'; +import {TestBed} from '@angular/core/testing'; + +@Component({template: 'Protected Page
'}) class ProtectedComponent {} -@Component({ template: 'Login Page
' }) +@Component({template: 'Login Page
'}) class LoginComponent {} describe('authGuard', () => { @@ -91,10 +86,10 @@ describe('authGuard', () => { TestBed.configureTestingModule({ providers: [ - { provide: AuthStore, useValue: authStore }, + {provide: AuthStore, useValue: authStore}, provideRouter([ - { path: 'protected', component: ProtectedComponent, canActivate: [authGuard] }, - { path: 'login', component: LoginComponent }, + {path: 'protected', component: ProtectedComponent, canActivate: [authGuard]}, + {path: 'login', component: LoginComponent}, ]), ], }); @@ -120,9 +115,9 @@ describe('authGuard', () => { ```ts // auth.guard.ts -import { inject } from '@angular/core'; -import { CanActivateFn, Router } from '@angular/router'; -import { AuthStore } from './auth-store'; +import {inject} from '@angular/core'; +import {CanActivateFn, Router} from '@angular/router'; +import {AuthStore} from './auth-store'; export const authGuard: CanActivateFn = () => { const authStore = inject(AuthStore); @@ -139,19 +134,19 @@ export const authGuard: CanActivateFn = () => { ```ts // app.component.spec.ts -import { TestBed } from '@angular/core/testing'; -import { RouterTestingHarness } from '@angular/router/testing'; -import { provideRouter } from '@angular/router'; -import { Component } from '@angular/core'; -import { App } from './app'; +import {TestBed} from '@angular/core/testing'; +import {RouterTestingHarness} from '@angular/router/testing'; +import {provideRouter} from '@angular/router'; +import {Component} from '@angular/core'; +import {App} from './app'; @Component({ - template: 'Home Page
' + template: 'Home Page
', }) class MockHome {} @Component({ - template: 'About Page
' + template: 'About Page
', }) class MockAbout {} @@ -163,10 +158,10 @@ describe('App Router Outlet', () => { imports: [App], providers: [ provideRouter([ - { path: '', component: MockHome }, - { path: 'about', component: MockAbout } - ]) - ] + {path: '', component: MockHome}, + {path: 'about', component: MockAbout}, + ]), + ], }); harness = await RouterTestingHarness.create(); @@ -218,10 +213,10 @@ export class App {} ```ts // nested-routes.spec.ts -import { TestBed } from '@angular/core/testing'; -import { RouterTestingHarness } from '@angular/router/testing'; -import { provideRouter } from '@angular/router'; -import { Parent, Child } from './nested-components'; +import {TestBed} from '@angular/core/testing'; +import {RouterTestingHarness} from '@angular/router/testing'; +import {provideRouter} from '@angular/router'; +import {Parent, Child} from './nested-components'; describe('Nested Routes', () => { let harness: RouterTestingHarness; @@ -234,12 +229,10 @@ describe('Nested Routes', () => { { path: 'parent', component: Parent, - children: [ - { path: 'child', component: Child } - ] - } - ]) - ] + children: [{path: 'child', component: Child}], + }, + ]), + ], }); harness = await RouterTestingHarness.create(); @@ -284,10 +277,10 @@ export class Child {} ```ts // search.component.spec.ts -import { TestBed } from '@angular/core/testing'; -import { Router, provideRouter } from '@angular/router'; -import { RouterTestingHarness } from '@angular/router/testing'; -import { Search } from './search'; +import {TestBed} from '@angular/core/testing'; +import {Router, provideRouter} from '@angular/router'; +import {RouterTestingHarness} from '@angular/router/testing'; +import {Search} from './search'; describe('Search', () => { let component: Search; @@ -296,11 +289,7 @@ describe('Search', () => { beforeEach(async () => { TestBed.configureTestingModule({ imports: [Search], - providers: [ - provideRouter([ - { path: 'search', component: Search } - ]) - ] + providers: [provideRouter([{path: 'search', component: Search}])], }); harness = await RouterTestingHarness.create(); @@ -333,9 +322,9 @@ export class Search { ## ルーターテストのベストプラクティス {#best-practices-for-router-testing} -1. **RouterTestingHarnessを使用する** - ルーティングされたコンポーネントをテストするには、よりクリーンなAPIを提供し、テストホストコンポーネントの必要性を排除する[`RouterTestingHarness`](api/router/testing/RouterTestingHarness)を使用してください。これは、直接的なコンポーネントアクセス、組み込みのナビゲーション、およびより優れた型安全性を提供します。ただし、名前付きアウトレットのテストなど、カスタムホストコンポーネントを作成する必要がある一部のシナリオには適していません。 -2. **外部の依存関係を慎重に処理する** - より現実的なテストのために、可能な場合は実際の実装を優先してください。実際の実装が実現不可能な場合（例：外部API）は、実際の動作を近似するフェイクを使用してください。モックやスタブは、テストを脆弱にし、信頼性を低下させる可能性があるため、最後の手段としてのみ使用してください。 -3. **ナビゲーション状態をテストする** - URLの変更やコンポーネントのレンダリングを含む、ナビゲーションアクションと結果として生じるアプリケーション状態の両方を検証してください。 -4. **非同期操作を処理する** - ルーターのナビゲーションは非同期です。テストでのタイミングを適切に処理するために、`async/await` または [`fakeAsync`](api/core/testing/fakeAsync) を使用してください。 -5. **エラーシナリオをテストする** - アプリケーションがエッジケースを適切に処理することを確認するために、無効なルート、失敗したナビゲーション、およびガードによる拒否のテストを含めてください。 -6. **Angularルーターをモックしない** - 代わりに、実際のルート設定を提供し、ハーネスを使用してナビゲートしてください。これにより、テストがより堅牢になり、Angularの内部更新で壊れる可能性が低くなります。また、モックは破壊的変更を隠す可能性があるため、ルーターが更新されたときに実際の問題を確実に捕捉できます。 +1. **RouterTestingHarnessを使用する** - ルーティングされたコンポーネントをテストするには、よりクリーンなAPIを提供し、テストホストコンポーネントの必要性を排除する[`RouterTestingHarness`](api/router/testing/RouterTestingHarness)を使用してください。これは、直接的なコンポーネントアクセス、組み込みのナビゲーション、およびより優れた型安全性を提供します。ただし、名前付きアウトレットのテストなど、カスタムホストコンポーネントを作成する必要がある一部のシナリオには適していません。 +2. **外部の依存関係を慎重に処理する** - より現実的なテストのために、可能な場合は実際の実装を優先してください。実際の実装が実現不可能な場合（例：外部API）は、実際の動作を近似するフェイクを使用してください。モックやスタブは、テストを脆弱にし、信頼性を低下させる可能性があるため、最後の手段としてのみ使用してください。 +3. **ナビゲーション状態をテストする** - URLの変更やコンポーネントのレンダリングを含む、ナビゲーションアクションと結果として生じるアプリケーション状態の両方を検証してください。 +4. **非同期操作を処理する** - ルーターのナビゲーションは非同期です。テストでのタイミングを適切に処理するために、`async/await`を使用してください。 +5. **エラーシナリオをテストする** - アプリケーションがエッジケースを適切に処理することを確認するために、無効なルート、失敗したナビゲーション、およびガードによる拒否のテストを含めてください。 +6. **Angularルーターをモックしない** - 代わりに、実際のルート設定を提供し、ハーネスを使用してナビゲートしてください。これにより、テストがより堅牢になり、Angularの内部更新で壊れる可能性が低くなります。また、モックは破壊的変更を隠す可能性があるため、ルーターが更新されたときに実際の問題を確実に捕捉できます。 diff --git a/adev-ja/src/content/guide/security.en.md b/adev-ja/src/content/guide/security.en.md index c0ca220f57..ecee243eea 100644 --- a/adev-ja/src/content/guide/security.en.md +++ b/adev-ja/src/content/guide/security.en.md @@ -159,10 +159,12 @@ import {bootstrapApplication, CSP_NONCE} from '@angular/core'; import {AppComponent} from './app/app.component'; bootstrapApplication(AppComponent, { - providers: [{ - provide: CSP_NONCE, - useValue: globalThis.myRandomNonceValue - }] + providers: [ + { + provide: CSP_NONCE, + useValue: globalThis.myRandomNonceValue, + }, + ], }); ``` @@ -225,13 +227,15 @@ Content-Security-Policy: trusted-types angular; require-trusted-types-for 'scrip An example of a header specifically configured for Trusted Types and Angular applications that use any of Angular's methods in [DomSanitizer](api/platform-browser/DomSanitizer) that bypasses security: ```html -Content-Security-Policy: trusted-types angular angular#unsafe-bypass; require-trusted-types-for 'script'; +Content-Security-Policy: trusted-types angular angular#unsafe-bypass; require-trusted-types-for +'script'; ``` The following is an example of a header specifically configured for Trusted Types and Angular applications using JIT: ```html -Content-Security-Policy: trusted-types angular angular#unsafe-jit; require-trusted-types-for 'script'; +Content-Security-Policy: trusted-types angular angular#unsafe-jit; require-trusted-types-for +'script'; ``` The following is an example of a header specifically configured for Trusted Types and Angular applications that use lazy loading of modules: @@ -328,7 +332,7 @@ export const appConfig: ApplicationConfig = { headerName: 'X-Custom-Xsrf-Header', }), ), - ] + ], }; ``` @@ -338,11 +342,7 @@ If the built-in XSRF protection mechanism doesn't work for your application, you ```ts export const appConfig: ApplicationConfig = { - providers: [ - provideHttpClient( - withNoXsrfProtection(), - ), - ] + providers: [provideHttpClient(withNoXsrfProtection())], }; ``` diff --git a/adev-ja/src/content/guide/security.md b/adev-ja/src/content/guide/security.md index a70b1fc655..7882d9a201 100644 --- a/adev-ja/src/content/guide/security.md +++ b/adev-ja/src/content/guide/security.md @@ -159,10 +159,12 @@ import {bootstrapApplication, CSP_NONCE} from '@angular/core'; import {AppComponent} from './app/app.component'; bootstrapApplication(AppComponent, { - providers: [{ - provide: CSP_NONCE, - useValue: globalThis.myRandomNonceValue - }] + providers: [ + { + provide: CSP_NONCE, + useValue: globalThis.myRandomNonceValue, + }, + ], }); ``` @@ -225,13 +227,15 @@ Content-Security-Policy: trusted-types angular; require-trusted-types-for 'scrip Trusted TypesとAngularアプリケーション用に構成されたヘッダーの例で、Angularの[DomSanitizer](api/platform-browser/DomSanitizer)でセキュリティをバイパスするメソッドをいずれか使用しています。 ```html -Content-Security-Policy: trusted-types angular angular#unsafe-bypass; require-trusted-types-for 'script'; +Content-Security-Policy: trusted-types angular angular#unsafe-bypass; require-trusted-types-for ++'script'; ``` Trusted TypesとJITを使用するAngularアプリケーション用に構成されたヘッダーの例を以下に示します。 ```html -Content-Security-Policy: trusted-types angular angular#unsafe-jit; require-trusted-types-for 'script'; +Content-Security-Policy: trusted-types angular angular#unsafe-jit; require-trusted-types-for ++'script'; ``` 遅延読み込みモジュールを使用するAngularアプリケーション用に構成されたヘッダーの例を以下に示します。 @@ -328,7 +332,7 @@ export const appConfig: ApplicationConfig = { headerName: 'X-Custom-Xsrf-Header', }), ), - ] + ], }; ``` @@ -338,11 +342,7 @@ export const appConfig: ApplicationConfig = { ```ts export const appConfig: ApplicationConfig = { - providers: [ - provideHttpClient( - withNoXsrfProtection(), - ), - ] + providers: [provideHttpClient(withNoXsrfProtection())], }; ``` diff --git a/adev-ja/src/content/guide/signals/effect.md b/adev-ja/src/content/guide/signals/effect.md index 9b5fcd79a6..211f7d7631 100644 --- a/adev-ja/src/content/guide/signals/effect.md +++ b/adev-ja/src/content/guide/signals/effect.md @@ -34,7 +34,9 @@ Instead, use `computed` signals to model state that depends on other state. By default, you can only create an `effect()` within an [injection context](guide/di/dependency-injection-context) (where you have access to the `inject` function). The easiest way to satisfy this requirement is to call `effect` within a component, directive, or service `constructor`: ```ts -@Component({/* ... */}) +@Component({ + /* ... */ +}) export class EffectiveCounter { readonly count = signal(0); @@ -70,18 +72,18 @@ Angular implicitly defines two implicit behaviors for its effects depending on t A "View Effect" is an `effect` created in the context of a component instantiation. This includes effects created by services that are tied to component injectors.A "Root Effect" is created in the context of a root provided service instantiation. -The execution of both kind of `effect` are tied to the change detection process. +The execution of both kinds of `effect` are tied to the change detection process. -- "View effects" are executed _before_ there corresponding component is checked the change detection process. +- "View effects" are executed _before_ their corresponding component is checked by the change detection process. - "Root effects" are executed prior to all components being checked by the change detection process. -In both cases, if at least one of the effect dependency changed during the effect execution, the effect will re-run before moving ahead on the change detection process, +In both cases, if at least one of the effect dependencies changed during the effect execution, the effect will re-run before moving ahead on the change detection process, ### Destroying effects When a component or directive is destroyed, Angular automatically cleans up any associated effects. -An `effect` can be created two different context that will affect when it's destroyed: +An `effect` can be created in two different contexts that will affect when it's destroyed: - A "View effect" is destroyed when the component is destroyed. - A "Root effect" is destroyed when the application is destroyed. @@ -114,7 +116,9 @@ The `effect` function is a general-purpose tool for running code in reaction to For these situations, you can use `afterRenderEffect`. It functions like `effect`, but runs after Angular has finished rendering and committed its changes to the DOM. ```ts -@Component({/* ... */}) +@Component({ + /* ... */ +}) export class MyFancyChart { chartData = input.required
- Hello world! -
+Hello world!
``` ## Additional Resources diff --git a/adev-ja/src/content/guide/tailwind.md b/adev-ja/src/content/guide/tailwind.md index 879fddc693..ea92cb7a0a 100644 --- a/adev-ja/src/content/guide/tailwind.md +++ b/adev-ja/src/content/guide/tailwind.md @@ -58,7 +58,6 @@ cd my-project PostCSSの設定に`@tailwindcss/postcss`プラグインを追加します。 ```json {header: '.postcssrc.json'} - { "plugins": { "@tailwindcss/postcss": {} @@ -70,15 +69,15 @@ PostCSSの設定に`@tailwindcss/postcss`プラグインを追加します。 Tailwind CSSをインポートする`@import`を`./src/styles.css`に追加します。 -- Hello world! -
+Hello world!
``` ## その他のリソース {#additional-resources} diff --git a/adev-ja/src/content/guide/templates/event-listeners.en.md b/adev-ja/src/content/guide/templates/event-listeners.en.md index de0d54cafc..344d29b94a 100644 --- a/adev-ja/src/content/guide/templates/event-listeners.en.md +++ b/adev-ja/src/content/guide/templates/event-listeners.en.md @@ -128,8 +128,8 @@ Angular’s event system is extensible via custom event plugins registered with To create a custom event plugin, extend the `EventManagerPlugin` class and implement the required methods. ```ts -import { Injectable } from '@angular/core'; -import { EventManagerPlugin } from '@angular/platform-browser'; +import {Injectable} from '@angular/core'; +import {EventManagerPlugin} from '@angular/platform-browser'; @Injectable() export class DebounceEventPlugin extends EventManagerPlugin { @@ -143,21 +143,17 @@ export class DebounceEventPlugin extends EventManagerPlugin { } // Handle the event registration - override addEventListener( - element: HTMLElement, - eventName: string, - handler: Function - ) { + override addEventListener(element: HTMLElement, eventName: string, handler: Function) { // Parse the event: e.g., "click.debounce.500" // event: "click", delay: 500 - const [event, method , delay = 300 ] = eventName.split('.'); + const [event, method, delay = 300] = eventName.split('.'); let timeoutId: number; const listener = (event: Event) => { clearTimeout(timeoutId); timeoutId = setTimeout(() => { - handler(event); + handler(event); }, delay); }; @@ -175,19 +171,19 @@ export class DebounceEventPlugin extends EventManagerPlugin { Register your custom plugin using the `EVENT_MANAGER_PLUGINS` token in your application's providers: ```ts -import { bootstrapApplication } from '@angular/platform-browser'; -import { EVENT_MANAGER_PLUGINS } from '@angular/platform-browser'; -import { AppComponent } from './app/app.component'; -import { DebounceEventPlugin } from './debounce-event-plugin'; +import {bootstrapApplication} from '@angular/platform-browser'; +import {EVENT_MANAGER_PLUGINS} from '@angular/platform-browser'; +import {AppComponent} from './app/app.component'; +import {DebounceEventPlugin} from './debounce-event-plugin'; bootstrapApplication(AppComponent, { providers: [ { provide: EVENT_MANAGER_PLUGINS, useClass: DebounceEventPlugin, - multi: true - } - ] + multi: true, + }, + ], }); ``` diff --git a/adev-ja/src/content/guide/templates/event-listeners.md b/adev-ja/src/content/guide/templates/event-listeners.md index ee99e07c55..6ee264ab38 100644 --- a/adev-ja/src/content/guide/templates/event-listeners.md +++ b/adev-ja/src/content/guide/templates/event-listeners.md @@ -128,8 +128,8 @@ Angularのイベントシステムは、`EVENT_MANAGER_PLUGINS` インジェク カスタムイベントプラグインを作成するには、`EventManagerPlugin` クラスを拡張し、必要なメソッドを実装します。 ```ts -import { Injectable } from '@angular/core'; -import { EventManagerPlugin } from '@angular/platform-browser'; +import {Injectable} from '@angular/core'; +import {EventManagerPlugin} from '@angular/platform-browser'; @Injectable() export class DebounceEventPlugin extends EventManagerPlugin { @@ -143,21 +143,17 @@ export class DebounceEventPlugin extends EventManagerPlugin { } // Handle the event registration - override addEventListener( - element: HTMLElement, - eventName: string, - handler: Function - ) { + override addEventListener(element: HTMLElement, eventName: string, handler: Function) { // Parse the event: e.g., "click.debounce.500" // event: "click", delay: 500 - const [event, method , delay = 300 ] = eventName.split('.'); + const [event, method, delay = 300] = eventName.split('.'); let timeoutId: number; const listener = (event: Event) => { clearTimeout(timeoutId); timeoutId = setTimeout(() => { - handler(event); + handler(event); }, delay); }; @@ -175,19 +171,19 @@ export class DebounceEventPlugin extends EventManagerPlugin { アプリケーションのプロバイダーで `EVENT_MANAGER_PLUGINS` トークンを使用してカスタムプラグインを登録します。 ```ts -import { bootstrapApplication } from '@angular/platform-browser'; -import { EVENT_MANAGER_PLUGINS } from '@angular/platform-browser'; -import { AppComponent } from './app/app.component'; -import { DebounceEventPlugin } from './debounce-event-plugin'; +import {bootstrapApplication} from '@angular/platform-browser'; +import {EVENT_MANAGER_PLUGINS} from '@angular/platform-browser'; +import {AppComponent} from './app/app.component'; +import {DebounceEventPlugin} from './debounce-event-plugin'; bootstrapApplication(AppComponent, { providers: [ { provide: EVENT_MANAGER_PLUGINS, useClass: DebounceEventPlugin, - multi: true - } - ] + multi: true, + }, + ], }); ``` diff --git a/adev-ja/src/content/guide/templates/ng-template.en.md b/adev-ja/src/content/guide/templates/ng-template.en.md index b3118b5054..a2e10d15e4 100644 --- a/adev-ja/src/content/guide/templates/ng-template.en.md +++ b/adev-ja/src/content/guide/templates/ng-template.en.md @@ -137,7 +137,7 @@ The `NgTemplateOutlet` directive from `@angular/common` accepts a `TemplateRef` First, import `NgTemplateOutlet`: ```typescript -import { NgTemplateOutlet } from '@angular/common'; +import {NgTemplateOutlet} from '@angular/common'; ``` The following example declares a template fragment and renders that fragment to a `About
+Quote of the day:
+', () => {
+ const h2: HTMLElement = fixture.nativeElement.querySelector('h2');
+ const bgColor = h2.style.backgroundColor;
+ expect(bgColor).toBe('skyblue');
+});
+```
However, testing a single use case is unlikely to explore the full range of a directive's capabilities.
Finding and testing all components that use the directive is tedious, brittle, and almost as unlikely to afford full coverage.
@@ -26,16 +71,75 @@ Isolated unit tests don't touch the DOM and, therefore, do not inspire confidenc
A better solution is to create an artificial test component that demonstrates all ways to apply the directive.
-Something Yellow
+ The Default (Gray)
+ No Highlight
+
+ `,
+})
+class Test {}
+```
-HELPFUL: The `` case binds the `HighlightDirective` to the name of a color value in the input box.
+HELPFUL: The `` case binds the `Highlight` to the name of a color value in the input box.
The initial value is the word "cyan" which should be the background color of the input box.
Here are some tests of this component:
-;
+let des: DebugElement[]; // the three elements w/ the directive
+
+beforeEach(async () => {
+ fixture = TestBed.createComponent(Test);
+ await fixture.whenStable();
+
+ // all elements with an attached Highlight
+ des = fixture.debugElement.queryAll(By.directive(Highlight));
+});
+
+// color tests
+it('should have three highlighted elements', () => {
+ expect(des.length).toBe(3);
+});
+
+it('should color 1st background "yellow"', () => {
+ const bgColor = des[0].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe('yellow');
+});
+
+it('should color 2nd background w/ default color', () => {
+ const dir = des[1].injector.get(Highlight);
+ const bgColor = des[1].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe(dir.defaultColor);
+});
+
+it('should bind background to value color', async () => {
+ // easier to work with nativeElement
+ const input = des[2].nativeElement as HTMLInputElement;
+ expect(input.style.backgroundColor, 'initial backgroundColor').toBe('cyan');
+
+ input.value = 'green';
+
+ // Dispatch a DOM event so that Angular responds to the input value change.
+ input.dispatchEvent(new Event('input'));
+ await fixture.whenStable();
+
+ expect(input.style.backgroundColor, 'changed backgroundColor').toBe('green');
+});
+
+it('bare should not have a backgroundColor', () => {
+ // the h2 without the Highlight directive
+ const bareH2 = fixture.debugElement.query(By.css('h2:not([highlight])'));
+
+ expect(bareH2.styles.backgroundColor).toBeUndefined();
+});
+```
A few techniques are noteworthy:
@@ -47,6 +151,6 @@ A few techniques are noteworthy:
But feel free to exploit the `nativeElement` when that seems easier or more clear than the abstraction.
- Angular adds a directive to the injector of the element to which it is applied.
- The test for the default color uses the injector of the second `` to get its `HighlightDirective` instance and its `defaultColor`.
+ The test for the default color uses the injector of the second `` to get its `Highlight` instance and its `defaultColor`.
- `DebugElement.properties` affords access to the artificial custom property that is set by the directive
diff --git a/adev-ja/src/content/guide/testing/attribute-directives.md b/adev-ja/src/content/guide/testing/attribute-directives.md
index bc98b74b49..5b2ac20ccd 100644
--- a/adev-ja/src/content/guide/testing/attribute-directives.md
+++ b/adev-ja/src/content/guide/testing/attribute-directives.md
@@ -3,20 +3,64 @@
_属性ディレクティブ_は、要素、コンポーネント、または他のディレクティブの動作を変更します。
その名前は、ディレクティブが適用される方法、つまりホスト要素の属性として適用される方法を反映しています。
-## `HighlightDirective`のテスト
+## `Highlight`ディレクティブのテスト
-サンプルアプリケーションの`HighlightDirective`は、データバインドされた色またはデフォルトの色（ライトグレー）に基づいて、要素の背景色を設定します。
+サンプルアプリケーションの`Highlight`ディレクティブは、データバインドされた色またはデフォルトの色（ライトグレー）に基づいて、要素の背景色を設定します。
また、要素のカスタムプロパティ（`customProperty`）を`true`に設定しますが、これは単に設定できることを示すためです。
-About
+ Quote of the day:
+ ;
+
+beforeEach(async () => {
+ TestBed.configureTestingModule({
+ providers: [TwainService, UserService],
+ schemas: [CUSTOM_ELEMENTS_SCHEMA],
+ });
+ fixture = TestBed.createComponent(About);
+ await fixture.whenStable();
+});
+
+it('should have skyblue ', () => {
+ const h2: HTMLElement = fixture.nativeElement.querySelector('h2');
+ const bgColor = h2.style.backgroundColor;
+ expect(bgColor).toBe('skyblue');
+});
しかし、単一のユースケースをテストしても、ディレクティブの機能のすべてを調べられるとは限りません。
ディレクティブを使用するすべてのコンポーネントを見つけてテストすることは、面倒で壊れやすく、完全なカバレッジを実現する可能性もほとんどありません。
@@ -26,16 +70,75 @@ _クラスのみのテスト_は役立つ場合がありますが、このディ
より良い解決策は、ディレクティブのすべての適用方法を示す人工的なテストコンポーネントを作成することです。
-Something Yellow
+ The Default (Gray)
+ No Highlight
+
+ `,
+})
+class Test {}
+```
-HELPFUL: ``のケースでは、`HighlightDirective`を、入力ボックス内の色の値の名前とバインドしています。
+HELPFUL: ``のケースでは、`Highlight`を、入力ボックス内の色の値の名前とバインドしています。
初期値は単語"cyan"であり、これは入力ボックスの背景色になります。
このコンポーネントのテストをいくつか紹介します。
-;
+let des: DebugElement[]; // the three elements w/ the directive
+
+beforeEach(async () => {
+ fixture = TestBed.createComponent(Test);
+ await fixture.whenStable();
+
+ // all elements with an attached Highlight
+ des = fixture.debugElement.queryAll(By.directive(Highlight));
+});
+
+// color tests
+it('should have three highlighted elements', () => {
+ expect(des.length).toBe(3);
+});
+
+it('should color 1st background "yellow"', () => {
+ const bgColor = des[0].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe('yellow');
+});
+
+it('should color 2nd background w/ default color', () => {
+ const dir = des[1].injector.get(Highlight);
+ const bgColor = des[1].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe(dir.defaultColor);
+});
+
+it('should bind background to value color', async () => {
+ // easier to work with nativeElement
+ const input = des[2].nativeElement as HTMLInputElement;
+ expect(input.style.backgroundColor, 'initial backgroundColor').toBe('cyan');
+
+ input.value = 'green';
+
+ // Dispatch a DOM event so that Angular responds to the input value change.
+ input.dispatchEvent(new Event('input'));
+ await fixture.whenStable();
+
+ expect(input.style.backgroundColor, 'changed backgroundColor').toBe('green');
+});
+
+it('bare should not have a backgroundColor', () => {
+ // the h2 without the Highlight directive
+ const bareH2 = fixture.debugElement.query(By.css('h2:not([highlight])'));
+
+ expect(bareH2.styles.backgroundColor).toBeUndefined();
+});
+```
いくつかのテクニックが注目に値します。
@@ -47,6 +150,7 @@ HELPFUL: ``のケースでは、`HighlightDirective`を、入力ボック
しかし、抽象化よりも簡単で明確な場合は、`nativeElement`を利用してください。
- Angularは、適用された要素のインジェクターにディレクティブを追加します。
- デフォルトの色に対するテストでは、2番目の``のインジェクターを使用して、その`HighlightDirective`インスタンスとその`defaultColor`を取得します。
+ デフォルトの色に対するテストでは、2番目の``のインジェクターを使用して、その`Highlight`インスタンスとその`defaultColor`を取得します。
- `DebugElement.properties`は、ディレクティブによって設定された人工的なカスタムプロパティにアクセスできます。
+
diff --git a/adev-ja/src/content/guide/testing/components-basics.en.md b/adev-ja/src/content/guide/testing/components-basics.en.md
index 4341bdd006..82dce45e08 100644
--- a/adev-ja/src/content/guide/testing/components-basics.en.md
+++ b/adev-ja/src/content/guide/testing/components-basics.en.md
@@ -17,9 +17,9 @@ Classes alone cannot tell you if the component is going to render properly, resp
- Is `Lightswitch.clicked()` bound to anything such that the user can invoke it?
- Is the `Lightswitch.message` displayed?
-- Can the user actually select the hero displayed by `DashboardHeroComponent`?
+- Can the user actually select the hero displayed by the `DashboardHero` component?
- Is the hero name displayed as expected \(such as uppercase\)?
-- Is the welcome message displayed by the template of `WelcomeComponent`?
+- Is the welcome message displayed by the template of the `Welcome` component?
These might not be troubling questions for the preceding simple components illustrated.
But many components have complex interactions with the DOM elements described in their templates, causing HTML to appear and disappear as the component state changes.
@@ -32,19 +32,37 @@ To write these kinds of test, you'll use additional features of the `TestBed` as
The CLI creates an initial test file for you by default when you ask it to generate a new component.
-For example, the following CLI command generates a `BannerComponent` in the `app/banner` folder \(with inline template and styles\):
+For example, the following CLI command generates a `Banner` component in the `app/banner` folder \(with inline template and styles\):
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-It also generates an initial test file for the component, `banner-external.component.spec.ts`, that looks like this:
+It also generates an initial test file for the component, `banner.spec.ts`, that looks like this:
-;
-Refer to the [waitForAsync](guide/testing/components-scenarios#waitForAsync) section for more details.
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### Reduce the setup
@@ -55,25 +73,30 @@ The rest of the file is boilerplate setup code anticipating more advanced tests
You'll learn about these advanced test features in the following sections.
For now, you can radically reduce this test file to a more manageable size:
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ The value of `ComponentFixture.nativeElement` has the `any` type.
Later you'll encounter the `DebugElement.nativeElement` and it too has the `any` type.
Angular can't know at compile time what kind of HTML element the `nativeElement` is or if it even is an HTML element.
-The application might be running on a _non-browser platform_, such as the server or a [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API), where the element might have a diminished API or not exist at all.
+The application might be running on a _non-browser platform_, such as the server or a node environment, where the element might have a diminished API or not exist at all.
The tests in this guide are designed to run in a browser so a `nativeElement` value will always be an `HTMLElement` or one of its derived classes.
@@ -115,17 +178,28 @@ Knowing that it is an `HTMLElement` of some sort, use the standard HTML `querySe
Here's another test that calls `HTMLElement.querySelector` to get the paragraph element and look for the banner text:
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
The Angular _fixture_ provides the component's element directly through the `fixture.nativeElement`.
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
The `DebugElement` has other methods and properties that are useful in tests, as you'll see elsewhere in this guide.
You import the `DebugElement` symbol from the Angular core library.
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
Some noteworthy observations:
diff --git a/adev-ja/src/content/guide/testing/components-basics.md b/adev-ja/src/content/guide/testing/components-basics.md
index 833d620f05..550c14cf83 100644
--- a/adev-ja/src/content/guide/testing/components-basics.md
+++ b/adev-ja/src/content/guide/testing/components-basics.md
@@ -17,9 +17,9 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
- `Lightswitch.clicked()` はユーザーが呼び出せるように何かとバインドされていますか？
- `Lightswitch.message` は表示されますか？
-- ユーザーは `DashboardHeroComponent` によって表示されるヒーローを実際に選択できますか？
+- ユーザーは `DashboardHero` コンポーネントによって表示されるヒーローを実際に選択できますか？
- ヒーローの名前は期待通り（たとえば、大文字）に表示されますか？
-- `WelcomeComponent` のテンプレートによってウェルカムメッセージは表示されますか？
+- `Welcome` コンポーネントのテンプレートによってウェルカムメッセージは表示されますか？
これらの質問は、説明した前の簡単なコンポーネントにとっては問題ないかもしれません。
しかし、多くのコンポーネントは、そのテンプレートで記述されているDOM要素との複雑な対話を持ち、コンポーネントの状態が変わるとHTMLが表示および非表示になります。
@@ -32,19 +32,37 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
CLIは、新しいコンポーネントの生成を要求するときに、デフォルトで初期テストファイルを自動的に生成します。
-たとえば、次のCLIコマンドは `app/banner` フォルダーに `BannerComponent` を生成します（インラインテンプレートとスタイル付き）。
+たとえば、次のCLIコマンドは `app/banner` フォルダーに `Banner` コンポーネントを生成します（インラインテンプレートとスタイル付き）。
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-また、コンポーネントの初期テストファイル `banner-external.component.spec.ts` も生成し、次のようになります。
+また、コンポーネントの初期テストファイル `banner.spec.ts` も生成し、次のようになります。
-;
-詳細については、[waitForAsync](guide/testing/components-scenarios#waitForAsync) セクションを参照してください。
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### セットアップの削減
@@ -55,25 +73,30 @@ HELPFUL: `compileComponents` は非同期であるため、`@angular/core/testin
これらの高度なテスト機能については、次のセクションで説明します。
今のところ、このテストファイルをより管理しやすいサイズに大幅に縮小できます。
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ fixtureを介してコンポーネントインスタンスにアクセスし、J
後で `DebugElement.nativeElement` に遭遇しますが、これも `any` 型です。
Angularは、コンパイル時に `nativeElement` がどのようなHTML要素であるか、あるいはHTML要素であるかどうかすらを知ることができません。
-アプリケーションは、サーバーや [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API) などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
+アプリケーションは、サーバーやNode環境などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
このガイドのテストはブラウザで実行されるように設計されているため、`nativeElement` の値は常に `HTMLElement` またはその派生クラスのいずれかになります。
@@ -115,17 +178,28 @@ Angularは、コンパイル時に `nativeElement` がどのようなHTML要素
次に、`HTMLElement.querySelector` を呼び出して段落要素を取得し、バナーテキストを探すテストを示します。
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
Angularの _fixture_ は、`fixture.nativeElement` を介してコンポーネントの要素を直接提供します。
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
`DebugElement` には、このガイドの他の場所で説明されているように、テストで役立つ他のメソッドとプロパティがあります。
Angularコアライブラリから `DebugElement` シンボルをインポートします。
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
注目すべき観察結果をいくつか紹介します。
diff --git a/adev-ja/src/content/guide/testing/components-scenarios.en.md b/adev-ja/src/content/guide/testing/components-scenarios.en.md
index 8cc4023f01..a2699bd4b3 100644
--- a/adev-ja/src/content/guide/testing/components-scenarios.en.md
+++ b/adev-ja/src/content/guide/testing/components-scenarios.en.md
@@ -4,11 +4,22 @@ This guide explores common component testing use cases.
## Component binding
-In the example application, the `BannerComponent` presents static title text in the HTML template.
+In the example application, the `Banner` component presents static title text in the HTML template.
-After a few changes, the `BannerComponent` presents a dynamic title by binding to the component's `title` property like this.
+After a few changes, the `Banner` component presents a dynamic title by binding to the component's `title` property like this.
-
{{ title() }}
',
+ styles: ['h1 { color: green; font-size: 350%}'],
+})
+export class Banner {
+ title = signal('Test Tour of Heroes');
+}
+```
As minimal as this is, you decide to add a test to confirm that component actually displays the right content where you think it should.
@@ -18,75 +29,86 @@ You'll write a sequence of tests that inspect the value of the `` element th
You update the `beforeEach` to find that element with a standard HTML `querySelector` and assign it to the `h1` variable.
-;
+let h1: HTMLElement;
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance; // Banner test instance
+ h1 = fixture.nativeElement.querySelector('h1');
+});
+```
### `createComponent()` does not bind data
For your first test you'd like to see that the screen displays the default `title`.
Your instinct is to write a test that immediately inspects the `` like this:
-
-
+```shell {hideCopy}
expected '' to contain 'Test Tour of Heroes'.
-
-
+```
Binding happens when Angular performs **change detection**.
In production, change detection kicks in automatically when Angular creates a component or the user enters a keystroke, for example.
-The `TestBed.createComponent` does not trigger change detection by default; a fact confirmed in the revised test:
+The `TestBed.createComponent` does not trigger change detection synchronously; a fact confirmed in the revised test:
-` have the expected title.
-{{ welcome() }}
',
+})
+export class Welcome {
+ private userAuth = inject(UserAuthentication);
+ welcome = signal(
+ this.userAuth.isLoggedIn() ? `Welcome, ${this.userAuth.user().name}` : 'Please log in.',
+ );
+}
+```
-The `WelcomeComponent` has decision logic that interacts with the service, logic that makes this component worth testing.
+The `Welcome` component has decision logic that interacts with the service, logic that makes this component worth testing.
### Provide service test doubles
A _component-under-test_ doesn't have to be provided with real services.
-Injecting the real `UserService` could be difficult.
+Injecting the real `UserAuthentication` could be difficult.
The real service might ask the user for login credentials and attempt to reach an authentication server.
These behaviors can be hard to intercept. Be aware that using test doubles makes the test behave differently from production so use them sparingly.
### Get injected services
-The tests need access to the `UserService` injected into the `WelcomeComponent`.
+The tests need access to the `UserAuthentication` injected into the `Welcome` component.
Angular has a hierarchical injection system.
There can be injectors at multiple levels, from the root injector created by the `TestBed` down through the component tree.
@@ -158,7 +184,10 @@ The safest way to get the injected service, the way that **_always works_**,
is to **get it from the injector of the _component-under-test_**.
The component injector is a property of the fixture's `DebugElement`.
-;
+let comp: Welcome;
+let userAuth: UserAuthentication; // the TestBed injected service
+let el: HTMLElement; // the DOM element with the welcome message
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Welcome);
+ comp = fixture.componentInstance;
+
+ // UserAuthentication from the root injector
+ userAuth = TestBed.inject(UserAuthentication);
+
+ // get the "welcome" element by CSS selector (e.g., by class name)
+ el = fixture.nativeElement.querySelector('.welcome');
+});
+```
And here are some tests:
-
+ {{ quote | async }}
+
+
+@if (errorMessage()) {
+ {{ errorMessage() }}
+}
+```
HELPFUL: The value of the component's `quote` property passes through an `AsyncPipe`.
That means the property returns either a `Promise` or an `Observable`.
-In this example, the `TwainComponent.getQuote()` method tells you that the `quote` property returns an `Observable`.
+In this example, the `TwainQuotes.getQuote()` method tells you that the `quote` property returns an `Observable`.
-
-
-fakeAsync(() => { /_test body_/ })
-
-
-
-The `fakeAsync()` function enables a linear coding style by running the test body in a special `fakeAsync test zone`.
-The test body appears to be synchronous.
-There is no nested syntax \(like a `Promise.then()`\) to disrupt the flow of control.
-
-HELPFUL: Limitation: The `fakeAsync()` function won't work if the test body makes an `XMLHttpRequest` \(XHR\) call.
-XHR calls within a test are rare, but if you need to call XHR, use `waitForAsync()`.
-
-IMPORTANT: Be aware that asynchronous tasks that happen inside the `fakeAsync` zone need to be manually executed with `flush` or `tick`. If you attempt to
-wait for them to complete (i.e. using `fixture.whenStable`) without using the
-`fakeAsync` test helpers to advance time, your test will likely fail. See below for more information.
-
-### The `tick()` function
-
-You do have to call [tick()](api/core/testing/tick) to advance the virtual clock.
-
-Calling [tick()](api/core/testing/tick) simulates the passage of time until all pending asynchronous activities finish.
-In this case, it waits for the observable's `setTimeout()`.
-The [tick()](api/core/testing/tick) function accepts `millis` and `tickOptions` as parameters. The `millis` parameter specifies how much the virtual clock advances and defaults to `0` if not provided.
-For example, if you have a `setTimeout(fn, 100)` in a `fakeAsync()` test, you need to use `tick(100)` to trigger the fn callback.
-The optional `tickOptions` parameter has a property named `processNewMacroTasksSynchronously`. The `processNewMacroTasksSynchronously` property represents whether to invoke new generated macro tasks when ticking and defaults to `true`.
+In the case your async service relies on the `HttpClient` to load remote data, it is recommended to return mock responses at the HTTP level with the `HttpTestingController`.
-
-
+The stub is designed in such a way that any component or service that injects it will receive the stubbed implementation.
+It means that any call to `getQuote` receives an observable with a test quote.
-If you want to support such a case, you need to define the macro task you want to support in `beforeEach()`.
-For example:
-
-
background "yellow"', () => {
+ const bgColor = des[0].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe('yellow');
+});
+
+it('should color 2nd background w/ default color', () => {
+ const dir = des[1].injector.get(Highlight);
+ const bgColor = des[1].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe(dir.defaultColor);
+});
+
+it('should bind background to value color', async () => {
+ // easier to work with nativeElement
+ const input = des[2].nativeElement as HTMLInputElement;
+ expect(input.style.backgroundColor, 'initial backgroundColor').toBe('cyan');
+
+ input.value = 'green';
+
+ // Dispatch a DOM event so that Angular responds to the input value change.
+ input.dispatchEvent(new Event('input'));
+ await fixture.whenStable();
+
+ expect(input.style.backgroundColor, 'changed backgroundColor').toBe('green');
+});
+
+it('bare should not have a backgroundColor', () => {
+ // the h2 without the Highlight directive
+ const bareH2 = fixture.debugElement.query(By.css('h2:not([highlight])'));
+
+ expect(bareH2.styles.backgroundColor).toBeUndefined();
+});
+```
A few techniques are noteworthy:
@@ -47,6 +151,6 @@ A few techniques are noteworthy:
But feel free to exploit the `nativeElement` when that seems easier or more clear than the abstraction.
- Angular adds a directive to the injector of the element to which it is applied.
- The test for the default color uses the injector of the second `` to get its `HighlightDirective` instance and its `defaultColor`.
+ The test for the default color uses the injector of the second `` to get its `Highlight` instance and its `defaultColor`.
- `DebugElement.properties` affords access to the artificial custom property that is set by the directive
diff --git a/adev-ja/src/content/guide/testing/attribute-directives.md b/adev-ja/src/content/guide/testing/attribute-directives.md
index bc98b74b49..5b2ac20ccd 100644
--- a/adev-ja/src/content/guide/testing/attribute-directives.md
+++ b/adev-ja/src/content/guide/testing/attribute-directives.md
@@ -3,20 +3,64 @@
_属性ディレクティブ_は、要素、コンポーネント、または他のディレクティブの動作を変更します。
その名前は、ディレクティブが適用される方法、つまりホスト要素の属性として適用される方法を反映しています。
-## `HighlightDirective`のテスト
+## `Highlight`ディレクティブのテスト
-サンプルアプリケーションの`HighlightDirective`は、データバインドされた色またはデフォルトの色（ライトグレー）に基づいて、要素の背景色を設定します。
+サンプルアプリケーションの`Highlight`ディレクティブは、データバインドされた色またはデフォルトの色（ライトグレー）に基づいて、要素の背景色を設定します。
また、要素のカスタムプロパティ（`customProperty`）を`true`に設定しますが、これは単に設定できることを示すためです。
-About
+ Quote of the day:
+ ;
+
+beforeEach(async () => {
+ TestBed.configureTestingModule({
+ providers: [TwainService, UserService],
+ schemas: [CUSTOM_ELEMENTS_SCHEMA],
+ });
+ fixture = TestBed.createComponent(About);
+ await fixture.whenStable();
+});
+
+it('should have skyblue ', () => {
+ const h2: HTMLElement = fixture.nativeElement.querySelector('h2');
+ const bgColor = h2.style.backgroundColor;
+ expect(bgColor).toBe('skyblue');
+});
しかし、単一のユースケースをテストしても、ディレクティブの機能のすべてを調べられるとは限りません。
ディレクティブを使用するすべてのコンポーネントを見つけてテストすることは、面倒で壊れやすく、完全なカバレッジを実現する可能性もほとんどありません。
@@ -26,16 +70,75 @@ _クラスのみのテスト_は役立つ場合がありますが、このディ
より良い解決策は、ディレクティブのすべての適用方法を示す人工的なテストコンポーネントを作成することです。
-Something Yellow
+ The Default (Gray)
+ No Highlight
+
+ `,
+})
+class Test {}
+```
-HELPFUL: ``のケースでは、`HighlightDirective`を、入力ボックス内の色の値の名前とバインドしています。
+HELPFUL: ``のケースでは、`Highlight`を、入力ボックス内の色の値の名前とバインドしています。
初期値は単語"cyan"であり、これは入力ボックスの背景色になります。
このコンポーネントのテストをいくつか紹介します。
-;
+let des: DebugElement[]; // the three elements w/ the directive
+
+beforeEach(async () => {
+ fixture = TestBed.createComponent(Test);
+ await fixture.whenStable();
+
+ // all elements with an attached Highlight
+ des = fixture.debugElement.queryAll(By.directive(Highlight));
+});
+
+// color tests
+it('should have three highlighted elements', () => {
+ expect(des.length).toBe(3);
+});
+
+it('should color 1st background "yellow"', () => {
+ const bgColor = des[0].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe('yellow');
+});
+
+it('should color 2nd background w/ default color', () => {
+ const dir = des[1].injector.get(Highlight);
+ const bgColor = des[1].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe(dir.defaultColor);
+});
+
+it('should bind background to value color', async () => {
+ // easier to work with nativeElement
+ const input = des[2].nativeElement as HTMLInputElement;
+ expect(input.style.backgroundColor, 'initial backgroundColor').toBe('cyan');
+
+ input.value = 'green';
+
+ // Dispatch a DOM event so that Angular responds to the input value change.
+ input.dispatchEvent(new Event('input'));
+ await fixture.whenStable();
+
+ expect(input.style.backgroundColor, 'changed backgroundColor').toBe('green');
+});
+
+it('bare should not have a backgroundColor', () => {
+ // the h2 without the Highlight directive
+ const bareH2 = fixture.debugElement.query(By.css('h2:not([highlight])'));
+
+ expect(bareH2.styles.backgroundColor).toBeUndefined();
+});
+```
いくつかのテクニックが注目に値します。
@@ -47,6 +150,7 @@ HELPFUL: ``のケースでは、`HighlightDirective`を、入力ボック
しかし、抽象化よりも簡単で明確な場合は、`nativeElement`を利用してください。
- Angularは、適用された要素のインジェクターにディレクティブを追加します。
- デフォルトの色に対するテストでは、2番目の``のインジェクターを使用して、その`HighlightDirective`インスタンスとその`defaultColor`を取得します。
+ デフォルトの色に対するテストでは、2番目の``のインジェクターを使用して、その`Highlight`インスタンスとその`defaultColor`を取得します。
- `DebugElement.properties`は、ディレクティブによって設定された人工的なカスタムプロパティにアクセスできます。
+
diff --git a/adev-ja/src/content/guide/testing/components-basics.en.md b/adev-ja/src/content/guide/testing/components-basics.en.md
index 4341bdd006..82dce45e08 100644
--- a/adev-ja/src/content/guide/testing/components-basics.en.md
+++ b/adev-ja/src/content/guide/testing/components-basics.en.md
@@ -17,9 +17,9 @@ Classes alone cannot tell you if the component is going to render properly, resp
- Is `Lightswitch.clicked()` bound to anything such that the user can invoke it?
- Is the `Lightswitch.message` displayed?
-- Can the user actually select the hero displayed by `DashboardHeroComponent`?
+- Can the user actually select the hero displayed by the `DashboardHero` component?
- Is the hero name displayed as expected \(such as uppercase\)?
-- Is the welcome message displayed by the template of `WelcomeComponent`?
+- Is the welcome message displayed by the template of the `Welcome` component?
These might not be troubling questions for the preceding simple components illustrated.
But many components have complex interactions with the DOM elements described in their templates, causing HTML to appear and disappear as the component state changes.
@@ -32,19 +32,37 @@ To write these kinds of test, you'll use additional features of the `TestBed` as
The CLI creates an initial test file for you by default when you ask it to generate a new component.
-For example, the following CLI command generates a `BannerComponent` in the `app/banner` folder \(with inline template and styles\):
+For example, the following CLI command generates a `Banner` component in the `app/banner` folder \(with inline template and styles\):
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-It also generates an initial test file for the component, `banner-external.component.spec.ts`, that looks like this:
+It also generates an initial test file for the component, `banner.spec.ts`, that looks like this:
-;
-Refer to the [waitForAsync](guide/testing/components-scenarios#waitForAsync) section for more details.
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### Reduce the setup
@@ -55,25 +73,30 @@ The rest of the file is boilerplate setup code anticipating more advanced tests
You'll learn about these advanced test features in the following sections.
For now, you can radically reduce this test file to a more manageable size:
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ The value of `ComponentFixture.nativeElement` has the `any` type.
Later you'll encounter the `DebugElement.nativeElement` and it too has the `any` type.
Angular can't know at compile time what kind of HTML element the `nativeElement` is or if it even is an HTML element.
-The application might be running on a _non-browser platform_, such as the server or a [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API), where the element might have a diminished API or not exist at all.
+The application might be running on a _non-browser platform_, such as the server or a node environment, where the element might have a diminished API or not exist at all.
The tests in this guide are designed to run in a browser so a `nativeElement` value will always be an `HTMLElement` or one of its derived classes.
@@ -115,17 +178,28 @@ Knowing that it is an `HTMLElement` of some sort, use the standard HTML `querySe
Here's another test that calls `HTMLElement.querySelector` to get the paragraph element and look for the banner text:
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
The Angular _fixture_ provides the component's element directly through the `fixture.nativeElement`.
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
The `DebugElement` has other methods and properties that are useful in tests, as you'll see elsewhere in this guide.
You import the `DebugElement` symbol from the Angular core library.
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
Some noteworthy observations:
diff --git a/adev-ja/src/content/guide/testing/components-basics.md b/adev-ja/src/content/guide/testing/components-basics.md
index 833d620f05..550c14cf83 100644
--- a/adev-ja/src/content/guide/testing/components-basics.md
+++ b/adev-ja/src/content/guide/testing/components-basics.md
@@ -17,9 +17,9 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
- `Lightswitch.clicked()` はユーザーが呼び出せるように何かとバインドされていますか？
- `Lightswitch.message` は表示されますか？
-- ユーザーは `DashboardHeroComponent` によって表示されるヒーローを実際に選択できますか？
+- ユーザーは `DashboardHero` コンポーネントによって表示されるヒーローを実際に選択できますか？
- ヒーローの名前は期待通り（たとえば、大文字）に表示されますか？
-- `WelcomeComponent` のテンプレートによってウェルカムメッセージは表示されますか？
+- `Welcome` コンポーネントのテンプレートによってウェルカムメッセージは表示されますか？
これらの質問は、説明した前の簡単なコンポーネントにとっては問題ないかもしれません。
しかし、多くのコンポーネントは、そのテンプレートで記述されているDOM要素との複雑な対話を持ち、コンポーネントの状態が変わるとHTMLが表示および非表示になります。
@@ -32,19 +32,37 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
CLIは、新しいコンポーネントの生成を要求するときに、デフォルトで初期テストファイルを自動的に生成します。
-たとえば、次のCLIコマンドは `app/banner` フォルダーに `BannerComponent` を生成します（インラインテンプレートとスタイル付き）。
+たとえば、次のCLIコマンドは `app/banner` フォルダーに `Banner` コンポーネントを生成します（インラインテンプレートとスタイル付き）。
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-また、コンポーネントの初期テストファイル `banner-external.component.spec.ts` も生成し、次のようになります。
+また、コンポーネントの初期テストファイル `banner.spec.ts` も生成し、次のようになります。
-;
-詳細については、[waitForAsync](guide/testing/components-scenarios#waitForAsync) セクションを参照してください。
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### セットアップの削減
@@ -55,25 +73,30 @@ HELPFUL: `compileComponents` は非同期であるため、`@angular/core/testin
これらの高度なテスト機能については、次のセクションで説明します。
今のところ、このテストファイルをより管理しやすいサイズに大幅に縮小できます。
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ fixtureを介してコンポーネントインスタンスにアクセスし、J
後で `DebugElement.nativeElement` に遭遇しますが、これも `any` 型です。
Angularは、コンパイル時に `nativeElement` がどのようなHTML要素であるか、あるいはHTML要素であるかどうかすらを知ることができません。
-アプリケーションは、サーバーや [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API) などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
+アプリケーションは、サーバーやNode環境などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
このガイドのテストはブラウザで実行されるように設計されているため、`nativeElement` の値は常に `HTMLElement` またはその派生クラスのいずれかになります。
@@ -115,17 +178,28 @@ Angularは、コンパイル時に `nativeElement` がどのようなHTML要素
次に、`HTMLElement.querySelector` を呼び出して段落要素を取得し、バナーテキストを探すテストを示します。
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
Angularの _fixture_ は、`fixture.nativeElement` を介してコンポーネントの要素を直接提供します。
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
`DebugElement` には、このガイドの他の場所で説明されているように、テストで役立つ他のメソッドとプロパティがあります。
Angularコアライブラリから `DebugElement` シンボルをインポートします。
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
注目すべき観察結果をいくつか紹介します。
diff --git a/adev-ja/src/content/guide/testing/components-scenarios.en.md b/adev-ja/src/content/guide/testing/components-scenarios.en.md
index 8cc4023f01..a2699bd4b3 100644
--- a/adev-ja/src/content/guide/testing/components-scenarios.en.md
+++ b/adev-ja/src/content/guide/testing/components-scenarios.en.md
@@ -4,11 +4,22 @@ This guide explores common component testing use cases.
## Component binding
-In the example application, the `BannerComponent` presents static title text in the HTML template.
+In the example application, the `Banner` component presents static title text in the HTML template.
-After a few changes, the `BannerComponent` presents a dynamic title by binding to the component's `title` property like this.
+After a few changes, the `Banner` component presents a dynamic title by binding to the component's `title` property like this.
-
{{ title() }}
',
+ styles: ['h1 { color: green; font-size: 350%}'],
+})
+export class Banner {
+ title = signal('Test Tour of Heroes');
+}
+```
As minimal as this is, you decide to add a test to confirm that component actually displays the right content where you think it should.
@@ -18,75 +29,86 @@ You'll write a sequence of tests that inspect the value of the `` element th
You update the `beforeEach` to find that element with a standard HTML `querySelector` and assign it to the `h1` variable.
-;
+let h1: HTMLElement;
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance; // Banner test instance
+ h1 = fixture.nativeElement.querySelector('h1');
+});
+```
### `createComponent()` does not bind data
For your first test you'd like to see that the screen displays the default `title`.
Your instinct is to write a test that immediately inspects the `` like this:
-
-
+```shell {hideCopy}
expected '' to contain 'Test Tour of Heroes'.
-
-
+```
Binding happens when Angular performs **change detection**.
In production, change detection kicks in automatically when Angular creates a component or the user enters a keystroke, for example.
-The `TestBed.createComponent` does not trigger change detection by default; a fact confirmed in the revised test:
+The `TestBed.createComponent` does not trigger change detection synchronously; a fact confirmed in the revised test:
-` have the expected title.
-{{ welcome() }}
',
+})
+export class Welcome {
+ private userAuth = inject(UserAuthentication);
+ welcome = signal(
+ this.userAuth.isLoggedIn() ? `Welcome, ${this.userAuth.user().name}` : 'Please log in.',
+ );
+}
+```
-The `WelcomeComponent` has decision logic that interacts with the service, logic that makes this component worth testing.
+The `Welcome` component has decision logic that interacts with the service, logic that makes this component worth testing.
### Provide service test doubles
A _component-under-test_ doesn't have to be provided with real services.
-Injecting the real `UserService` could be difficult.
+Injecting the real `UserAuthentication` could be difficult.
The real service might ask the user for login credentials and attempt to reach an authentication server.
These behaviors can be hard to intercept. Be aware that using test doubles makes the test behave differently from production so use them sparingly.
### Get injected services
-The tests need access to the `UserService` injected into the `WelcomeComponent`.
+The tests need access to the `UserAuthentication` injected into the `Welcome` component.
Angular has a hierarchical injection system.
There can be injectors at multiple levels, from the root injector created by the `TestBed` down through the component tree.
@@ -158,7 +184,10 @@ The safest way to get the injected service, the way that **_always works_**,
is to **get it from the injector of the _component-under-test_**.
The component injector is a property of the fixture's `DebugElement`.
-;
+let comp: Welcome;
+let userAuth: UserAuthentication; // the TestBed injected service
+let el: HTMLElement; // the DOM element with the welcome message
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Welcome);
+ comp = fixture.componentInstance;
+
+ // UserAuthentication from the root injector
+ userAuth = TestBed.inject(UserAuthentication);
+
+ // get the "welcome" element by CSS selector (e.g., by class name)
+ el = fixture.nativeElement.querySelector('.welcome');
+});
+```
And here are some tests:
-
+ {{ quote | async }}
+
+
+@if (errorMessage()) {
+ {{ errorMessage() }}
+}
+```
HELPFUL: The value of the component's `quote` property passes through an `AsyncPipe`.
That means the property returns either a `Promise` or an `Observable`.
-In this example, the `TwainComponent.getQuote()` method tells you that the `quote` property returns an `Observable`.
+In this example, the `TwainQuotes.getQuote()` method tells you that the `quote` property returns an `Observable`.
-
-
-fakeAsync(() => { /_test body_/ })
-
-
-
-The `fakeAsync()` function enables a linear coding style by running the test body in a special `fakeAsync test zone`.
-The test body appears to be synchronous.
-There is no nested syntax \(like a `Promise.then()`\) to disrupt the flow of control.
-
-HELPFUL: Limitation: The `fakeAsync()` function won't work if the test body makes an `XMLHttpRequest` \(XHR\) call.
-XHR calls within a test are rare, but if you need to call XHR, use `waitForAsync()`.
-
-IMPORTANT: Be aware that asynchronous tasks that happen inside the `fakeAsync` zone need to be manually executed with `flush` or `tick`. If you attempt to
-wait for them to complete (i.e. using `fixture.whenStable`) without using the
-`fakeAsync` test helpers to advance time, your test will likely fail. See below for more information.
-
-### The `tick()` function
-
-You do have to call [tick()](api/core/testing/tick) to advance the virtual clock.
-
-Calling [tick()](api/core/testing/tick) simulates the passage of time until all pending asynchronous activities finish.
-In this case, it waits for the observable's `setTimeout()`.
-The [tick()](api/core/testing/tick) function accepts `millis` and `tickOptions` as parameters. The `millis` parameter specifies how much the virtual clock advances and defaults to `0` if not provided.
-For example, if you have a `setTimeout(fn, 100)` in a `fakeAsync()` test, you need to use `tick(100)` to trigger the fn callback.
-The optional `tickOptions` parameter has a property named `processNewMacroTasksSynchronously`. The `processNewMacroTasksSynchronously` property represents whether to invoke new generated macro tasks when ticking and defaults to `true`.
+In the case your async service relies on the `HttpClient` to load remote data, it is recommended to return mock responses at the HTTP level with the `HttpTestingController`.
-
-
+The stub is designed in such a way that any component or service that injects it will receive the stubbed implementation.
+It means that any call to `getQuote` receives an observable with a test quote.
-If you want to support such a case, you need to define the macro task you want to support in `beforeEach()`.
-For example:
-
-
should not have a backgroundColor', () => {
+ // the h2 without the Highlight directive
+ const bareH2 = fixture.debugElement.query(By.css('h2:not([highlight])'));
+
+ expect(bareH2.styles.backgroundColor).toBeUndefined();
+});
+```
A few techniques are noteworthy:
@@ -47,6 +151,6 @@ A few techniques are noteworthy:
But feel free to exploit the `nativeElement` when that seems easier or more clear than the abstraction.
- Angular adds a directive to the injector of the element to which it is applied.
- The test for the default color uses the injector of the second `` to get its `HighlightDirective` instance and its `defaultColor`.
+ The test for the default color uses the injector of the second `` to get its `Highlight` instance and its `defaultColor`.
- `DebugElement.properties` affords access to the artificial custom property that is set by the directive
diff --git a/adev-ja/src/content/guide/testing/attribute-directives.md b/adev-ja/src/content/guide/testing/attribute-directives.md
index bc98b74b49..5b2ac20ccd 100644
--- a/adev-ja/src/content/guide/testing/attribute-directives.md
+++ b/adev-ja/src/content/guide/testing/attribute-directives.md
@@ -3,20 +3,64 @@
_属性ディレクティブ_は、要素、コンポーネント、または他のディレクティブの動作を変更します。
その名前は、ディレクティブが適用される方法、つまりホスト要素の属性として適用される方法を反映しています。
-## `HighlightDirective`のテスト
+## `Highlight`ディレクティブのテスト
-サンプルアプリケーションの`HighlightDirective`は、データバインドされた色またはデフォルトの色（ライトグレー）に基づいて、要素の背景色を設定します。
+サンプルアプリケーションの`Highlight`ディレクティブは、データバインドされた色またはデフォルトの色（ライトグレー）に基づいて、要素の背景色を設定します。
また、要素のカスタムプロパティ（`customProperty`）を`true`に設定しますが、これは単に設定できることを示すためです。
-About
+ Quote of the day:
+ ;
+
+beforeEach(async () => {
+ TestBed.configureTestingModule({
+ providers: [TwainService, UserService],
+ schemas: [CUSTOM_ELEMENTS_SCHEMA],
+ });
+ fixture = TestBed.createComponent(About);
+ await fixture.whenStable();
+});
+
+it('should have skyblue ', () => {
+ const h2: HTMLElement = fixture.nativeElement.querySelector('h2');
+ const bgColor = h2.style.backgroundColor;
+ expect(bgColor).toBe('skyblue');
+});
しかし、単一のユースケースをテストしても、ディレクティブの機能のすべてを調べられるとは限りません。
ディレクティブを使用するすべてのコンポーネントを見つけてテストすることは、面倒で壊れやすく、完全なカバレッジを実現する可能性もほとんどありません。
@@ -26,16 +70,75 @@ _クラスのみのテスト_は役立つ場合がありますが、このディ
より良い解決策は、ディレクティブのすべての適用方法を示す人工的なテストコンポーネントを作成することです。
-Something Yellow
+ The Default (Gray)
+ No Highlight
+
+ `,
+})
+class Test {}
+```
-HELPFUL: ``のケースでは、`HighlightDirective`を、入力ボックス内の色の値の名前とバインドしています。
+HELPFUL: ``のケースでは、`Highlight`を、入力ボックス内の色の値の名前とバインドしています。
初期値は単語"cyan"であり、これは入力ボックスの背景色になります。
このコンポーネントのテストをいくつか紹介します。
-;
+let des: DebugElement[]; // the three elements w/ the directive
+
+beforeEach(async () => {
+ fixture = TestBed.createComponent(Test);
+ await fixture.whenStable();
+
+ // all elements with an attached Highlight
+ des = fixture.debugElement.queryAll(By.directive(Highlight));
+});
+
+// color tests
+it('should have three highlighted elements', () => {
+ expect(des.length).toBe(3);
+});
+
+it('should color 1st background "yellow"', () => {
+ const bgColor = des[0].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe('yellow');
+});
+
+it('should color 2nd background w/ default color', () => {
+ const dir = des[1].injector.get(Highlight);
+ const bgColor = des[1].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe(dir.defaultColor);
+});
+
+it('should bind background to value color', async () => {
+ // easier to work with nativeElement
+ const input = des[2].nativeElement as HTMLInputElement;
+ expect(input.style.backgroundColor, 'initial backgroundColor').toBe('cyan');
+
+ input.value = 'green';
+
+ // Dispatch a DOM event so that Angular responds to the input value change.
+ input.dispatchEvent(new Event('input'));
+ await fixture.whenStable();
+
+ expect(input.style.backgroundColor, 'changed backgroundColor').toBe('green');
+});
+
+it('bare should not have a backgroundColor', () => {
+ // the h2 without the Highlight directive
+ const bareH2 = fixture.debugElement.query(By.css('h2:not([highlight])'));
+
+ expect(bareH2.styles.backgroundColor).toBeUndefined();
+});
+```
いくつかのテクニックが注目に値します。
@@ -47,6 +150,7 @@ HELPFUL: ``のケースでは、`HighlightDirective`を、入力ボック
しかし、抽象化よりも簡単で明確な場合は、`nativeElement`を利用してください。
- Angularは、適用された要素のインジェクターにディレクティブを追加します。
- デフォルトの色に対するテストでは、2番目の``のインジェクターを使用して、その`HighlightDirective`インスタンスとその`defaultColor`を取得します。
+ デフォルトの色に対するテストでは、2番目の``のインジェクターを使用して、その`Highlight`インスタンスとその`defaultColor`を取得します。
- `DebugElement.properties`は、ディレクティブによって設定された人工的なカスタムプロパティにアクセスできます。
+
diff --git a/adev-ja/src/content/guide/testing/components-basics.en.md b/adev-ja/src/content/guide/testing/components-basics.en.md
index 4341bdd006..82dce45e08 100644
--- a/adev-ja/src/content/guide/testing/components-basics.en.md
+++ b/adev-ja/src/content/guide/testing/components-basics.en.md
@@ -17,9 +17,9 @@ Classes alone cannot tell you if the component is going to render properly, resp
- Is `Lightswitch.clicked()` bound to anything such that the user can invoke it?
- Is the `Lightswitch.message` displayed?
-- Can the user actually select the hero displayed by `DashboardHeroComponent`?
+- Can the user actually select the hero displayed by the `DashboardHero` component?
- Is the hero name displayed as expected \(such as uppercase\)?
-- Is the welcome message displayed by the template of `WelcomeComponent`?
+- Is the welcome message displayed by the template of the `Welcome` component?
These might not be troubling questions for the preceding simple components illustrated.
But many components have complex interactions with the DOM elements described in their templates, causing HTML to appear and disappear as the component state changes.
@@ -32,19 +32,37 @@ To write these kinds of test, you'll use additional features of the `TestBed` as
The CLI creates an initial test file for you by default when you ask it to generate a new component.
-For example, the following CLI command generates a `BannerComponent` in the `app/banner` folder \(with inline template and styles\):
+For example, the following CLI command generates a `Banner` component in the `app/banner` folder \(with inline template and styles\):
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-It also generates an initial test file for the component, `banner-external.component.spec.ts`, that looks like this:
+It also generates an initial test file for the component, `banner.spec.ts`, that looks like this:
-;
-Refer to the [waitForAsync](guide/testing/components-scenarios#waitForAsync) section for more details.
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### Reduce the setup
@@ -55,25 +73,30 @@ The rest of the file is boilerplate setup code anticipating more advanced tests
You'll learn about these advanced test features in the following sections.
For now, you can radically reduce this test file to a more manageable size:
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ The value of `ComponentFixture.nativeElement` has the `any` type.
Later you'll encounter the `DebugElement.nativeElement` and it too has the `any` type.
Angular can't know at compile time what kind of HTML element the `nativeElement` is or if it even is an HTML element.
-The application might be running on a _non-browser platform_, such as the server or a [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API), where the element might have a diminished API or not exist at all.
+The application might be running on a _non-browser platform_, such as the server or a node environment, where the element might have a diminished API or not exist at all.
The tests in this guide are designed to run in a browser so a `nativeElement` value will always be an `HTMLElement` or one of its derived classes.
@@ -115,17 +178,28 @@ Knowing that it is an `HTMLElement` of some sort, use the standard HTML `querySe
Here's another test that calls `HTMLElement.querySelector` to get the paragraph element and look for the banner text:
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
The Angular _fixture_ provides the component's element directly through the `fixture.nativeElement`.
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
The `DebugElement` has other methods and properties that are useful in tests, as you'll see elsewhere in this guide.
You import the `DebugElement` symbol from the Angular core library.
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
Some noteworthy observations:
diff --git a/adev-ja/src/content/guide/testing/components-basics.md b/adev-ja/src/content/guide/testing/components-basics.md
index 833d620f05..550c14cf83 100644
--- a/adev-ja/src/content/guide/testing/components-basics.md
+++ b/adev-ja/src/content/guide/testing/components-basics.md
@@ -17,9 +17,9 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
- `Lightswitch.clicked()` はユーザーが呼び出せるように何かとバインドされていますか？
- `Lightswitch.message` は表示されますか？
-- ユーザーは `DashboardHeroComponent` によって表示されるヒーローを実際に選択できますか？
+- ユーザーは `DashboardHero` コンポーネントによって表示されるヒーローを実際に選択できますか？
- ヒーローの名前は期待通り（たとえば、大文字）に表示されますか？
-- `WelcomeComponent` のテンプレートによってウェルカムメッセージは表示されますか？
+- `Welcome` コンポーネントのテンプレートによってウェルカムメッセージは表示されますか？
これらの質問は、説明した前の簡単なコンポーネントにとっては問題ないかもしれません。
しかし、多くのコンポーネントは、そのテンプレートで記述されているDOM要素との複雑な対話を持ち、コンポーネントの状態が変わるとHTMLが表示および非表示になります。
@@ -32,19 +32,37 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
CLIは、新しいコンポーネントの生成を要求するときに、デフォルトで初期テストファイルを自動的に生成します。
-たとえば、次のCLIコマンドは `app/banner` フォルダーに `BannerComponent` を生成します（インラインテンプレートとスタイル付き）。
+たとえば、次のCLIコマンドは `app/banner` フォルダーに `Banner` コンポーネントを生成します（インラインテンプレートとスタイル付き）。
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-また、コンポーネントの初期テストファイル `banner-external.component.spec.ts` も生成し、次のようになります。
+また、コンポーネントの初期テストファイル `banner.spec.ts` も生成し、次のようになります。
-;
-詳細については、[waitForAsync](guide/testing/components-scenarios#waitForAsync) セクションを参照してください。
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### セットアップの削減
@@ -55,25 +73,30 @@ HELPFUL: `compileComponents` は非同期であるため、`@angular/core/testin
これらの高度なテスト機能については、次のセクションで説明します。
今のところ、このテストファイルをより管理しやすいサイズに大幅に縮小できます。
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ fixtureを介してコンポーネントインスタンスにアクセスし、J
後で `DebugElement.nativeElement` に遭遇しますが、これも `any` 型です。
Angularは、コンパイル時に `nativeElement` がどのようなHTML要素であるか、あるいはHTML要素であるかどうかすらを知ることができません。
-アプリケーションは、サーバーや [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API) などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
+アプリケーションは、サーバーやNode環境などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
このガイドのテストはブラウザで実行されるように設計されているため、`nativeElement` の値は常に `HTMLElement` またはその派生クラスのいずれかになります。
@@ -115,17 +178,28 @@ Angularは、コンパイル時に `nativeElement` がどのようなHTML要素
次に、`HTMLElement.querySelector` を呼び出して段落要素を取得し、バナーテキストを探すテストを示します。
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
Angularの _fixture_ は、`fixture.nativeElement` を介してコンポーネントの要素を直接提供します。
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
`DebugElement` には、このガイドの他の場所で説明されているように、テストで役立つ他のメソッドとプロパティがあります。
Angularコアライブラリから `DebugElement` シンボルをインポートします。
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
注目すべき観察結果をいくつか紹介します。
diff --git a/adev-ja/src/content/guide/testing/components-scenarios.en.md b/adev-ja/src/content/guide/testing/components-scenarios.en.md
index 8cc4023f01..a2699bd4b3 100644
--- a/adev-ja/src/content/guide/testing/components-scenarios.en.md
+++ b/adev-ja/src/content/guide/testing/components-scenarios.en.md
@@ -4,11 +4,22 @@ This guide explores common component testing use cases.
## Component binding
-In the example application, the `BannerComponent` presents static title text in the HTML template.
+In the example application, the `Banner` component presents static title text in the HTML template.
-After a few changes, the `BannerComponent` presents a dynamic title by binding to the component's `title` property like this.
+After a few changes, the `Banner` component presents a dynamic title by binding to the component's `title` property like this.
-
{{ title() }}
',
+ styles: ['h1 { color: green; font-size: 350%}'],
+})
+export class Banner {
+ title = signal('Test Tour of Heroes');
+}
+```
As minimal as this is, you decide to add a test to confirm that component actually displays the right content where you think it should.
@@ -18,75 +29,86 @@ You'll write a sequence of tests that inspect the value of the `` element th
You update the `beforeEach` to find that element with a standard HTML `querySelector` and assign it to the `h1` variable.
-;
+let h1: HTMLElement;
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance; // Banner test instance
+ h1 = fixture.nativeElement.querySelector('h1');
+});
+```
### `createComponent()` does not bind data
For your first test you'd like to see that the screen displays the default `title`.
Your instinct is to write a test that immediately inspects the `` like this:
-
-
+```shell {hideCopy}
expected '' to contain 'Test Tour of Heroes'.
-
-
+```
Binding happens when Angular performs **change detection**.
In production, change detection kicks in automatically when Angular creates a component or the user enters a keystroke, for example.
-The `TestBed.createComponent` does not trigger change detection by default; a fact confirmed in the revised test:
+The `TestBed.createComponent` does not trigger change detection synchronously; a fact confirmed in the revised test:
-` have the expected title.
-{{ welcome() }}
',
+})
+export class Welcome {
+ private userAuth = inject(UserAuthentication);
+ welcome = signal(
+ this.userAuth.isLoggedIn() ? `Welcome, ${this.userAuth.user().name}` : 'Please log in.',
+ );
+}
+```
-The `WelcomeComponent` has decision logic that interacts with the service, logic that makes this component worth testing.
+The `Welcome` component has decision logic that interacts with the service, logic that makes this component worth testing.
### Provide service test doubles
A _component-under-test_ doesn't have to be provided with real services.
-Injecting the real `UserService` could be difficult.
+Injecting the real `UserAuthentication` could be difficult.
The real service might ask the user for login credentials and attempt to reach an authentication server.
These behaviors can be hard to intercept. Be aware that using test doubles makes the test behave differently from production so use them sparingly.
### Get injected services
-The tests need access to the `UserService` injected into the `WelcomeComponent`.
+The tests need access to the `UserAuthentication` injected into the `Welcome` component.
Angular has a hierarchical injection system.
There can be injectors at multiple levels, from the root injector created by the `TestBed` down through the component tree.
@@ -158,7 +184,10 @@ The safest way to get the injected service, the way that **_always works_**,
is to **get it from the injector of the _component-under-test_**.
The component injector is a property of the fixture's `DebugElement`.
-;
+let comp: Welcome;
+let userAuth: UserAuthentication; // the TestBed injected service
+let el: HTMLElement; // the DOM element with the welcome message
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Welcome);
+ comp = fixture.componentInstance;
+
+ // UserAuthentication from the root injector
+ userAuth = TestBed.inject(UserAuthentication);
+
+ // get the "welcome" element by CSS selector (e.g., by class name)
+ el = fixture.nativeElement.querySelector('.welcome');
+});
+```
And here are some tests:
-
+ {{ quote | async }}
+
+
+@if (errorMessage()) {
+ {{ errorMessage() }}
+}
+```
HELPFUL: The value of the component's `quote` property passes through an `AsyncPipe`.
That means the property returns either a `Promise` or an `Observable`.
-In this example, the `TwainComponent.getQuote()` method tells you that the `quote` property returns an `Observable`.
+In this example, the `TwainQuotes.getQuote()` method tells you that the `quote` property returns an `Observable`.
-
-
-fakeAsync(() => { /_test body_/ })
-
-
-
-The `fakeAsync()` function enables a linear coding style by running the test body in a special `fakeAsync test zone`.
-The test body appears to be synchronous.
-There is no nested syntax \(like a `Promise.then()`\) to disrupt the flow of control.
-
-HELPFUL: Limitation: The `fakeAsync()` function won't work if the test body makes an `XMLHttpRequest` \(XHR\) call.
-XHR calls within a test are rare, but if you need to call XHR, use `waitForAsync()`.
-
-IMPORTANT: Be aware that asynchronous tasks that happen inside the `fakeAsync` zone need to be manually executed with `flush` or `tick`. If you attempt to
-wait for them to complete (i.e. using `fixture.whenStable`) without using the
-`fakeAsync` test helpers to advance time, your test will likely fail. See below for more information.
-
-### The `tick()` function
-
-You do have to call [tick()](api/core/testing/tick) to advance the virtual clock.
-
-Calling [tick()](api/core/testing/tick) simulates the passage of time until all pending asynchronous activities finish.
-In this case, it waits for the observable's `setTimeout()`.
-The [tick()](api/core/testing/tick) function accepts `millis` and `tickOptions` as parameters. The `millis` parameter specifies how much the virtual clock advances and defaults to `0` if not provided.
-For example, if you have a `setTimeout(fn, 100)` in a `fakeAsync()` test, you need to use `tick(100)` to trigger the fn callback.
-The optional `tickOptions` parameter has a property named `processNewMacroTasksSynchronously`. The `processNewMacroTasksSynchronously` property represents whether to invoke new generated macro tasks when ticking and defaults to `true`.
+In the case your async service relies on the `HttpClient` to load remote data, it is recommended to return mock responses at the HTTP level with the `HttpTestingController`.
-
-
+The stub is designed in such a way that any component or service that injects it will receive the stubbed implementation.
+It means that any call to `getQuote` receives an observable with a test quote.
-If you want to support such a case, you need to define the macro task you want to support in `beforeEach()`.
-For example:
-
-
` to get its `Highlight` instance and its `defaultColor`.
- `DebugElement.properties` affords access to the artificial custom property that is set by the directive
diff --git a/adev-ja/src/content/guide/testing/attribute-directives.md b/adev-ja/src/content/guide/testing/attribute-directives.md
index bc98b74b49..5b2ac20ccd 100644
--- a/adev-ja/src/content/guide/testing/attribute-directives.md
+++ b/adev-ja/src/content/guide/testing/attribute-directives.md
@@ -3,20 +3,64 @@
_属性ディレクティブ_は、要素、コンポーネント、または他のディレクティブの動作を変更します。
その名前は、ディレクティブが適用される方法、つまりホスト要素の属性として適用される方法を反映しています。
-## `HighlightDirective`のテスト
+## `Highlight`ディレクティブのテスト
-サンプルアプリケーションの`HighlightDirective`は、データバインドされた色またはデフォルトの色（ライトグレー）に基づいて、要素の背景色を設定します。
+サンプルアプリケーションの`Highlight`ディレクティブは、データバインドされた色またはデフォルトの色（ライトグレー）に基づいて、要素の背景色を設定します。
また、要素のカスタムプロパティ（`customProperty`）を`true`に設定しますが、これは単に設定できることを示すためです。
-About
+ Quote of the day:
+ ;
+
+beforeEach(async () => {
+ TestBed.configureTestingModule({
+ providers: [TwainService, UserService],
+ schemas: [CUSTOM_ELEMENTS_SCHEMA],
+ });
+ fixture = TestBed.createComponent(About);
+ await fixture.whenStable();
+});
+
+it('should have skyblue ', () => {
+ const h2: HTMLElement = fixture.nativeElement.querySelector('h2');
+ const bgColor = h2.style.backgroundColor;
+ expect(bgColor).toBe('skyblue');
+});
しかし、単一のユースケースをテストしても、ディレクティブの機能のすべてを調べられるとは限りません。
ディレクティブを使用するすべてのコンポーネントを見つけてテストすることは、面倒で壊れやすく、完全なカバレッジを実現する可能性もほとんどありません。
@@ -26,16 +70,75 @@ _クラスのみのテスト_は役立つ場合がありますが、このディ
より良い解決策は、ディレクティブのすべての適用方法を示す人工的なテストコンポーネントを作成することです。
-Something Yellow
+ The Default (Gray)
+ No Highlight
+
+ `,
+})
+class Test {}
+```
-HELPFUL: ``のケースでは、`HighlightDirective`を、入力ボックス内の色の値の名前とバインドしています。
+HELPFUL: ``のケースでは、`Highlight`を、入力ボックス内の色の値の名前とバインドしています。
初期値は単語"cyan"であり、これは入力ボックスの背景色になります。
このコンポーネントのテストをいくつか紹介します。
-;
+let des: DebugElement[]; // the three elements w/ the directive
+
+beforeEach(async () => {
+ fixture = TestBed.createComponent(Test);
+ await fixture.whenStable();
+
+ // all elements with an attached Highlight
+ des = fixture.debugElement.queryAll(By.directive(Highlight));
+});
+
+// color tests
+it('should have three highlighted elements', () => {
+ expect(des.length).toBe(3);
+});
+
+it('should color 1st background "yellow"', () => {
+ const bgColor = des[0].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe('yellow');
+});
+
+it('should color 2nd background w/ default color', () => {
+ const dir = des[1].injector.get(Highlight);
+ const bgColor = des[1].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe(dir.defaultColor);
+});
+
+it('should bind background to value color', async () => {
+ // easier to work with nativeElement
+ const input = des[2].nativeElement as HTMLInputElement;
+ expect(input.style.backgroundColor, 'initial backgroundColor').toBe('cyan');
+
+ input.value = 'green';
+
+ // Dispatch a DOM event so that Angular responds to the input value change.
+ input.dispatchEvent(new Event('input'));
+ await fixture.whenStable();
+
+ expect(input.style.backgroundColor, 'changed backgroundColor').toBe('green');
+});
+
+it('bare should not have a backgroundColor', () => {
+ // the h2 without the Highlight directive
+ const bareH2 = fixture.debugElement.query(By.css('h2:not([highlight])'));
+
+ expect(bareH2.styles.backgroundColor).toBeUndefined();
+});
+```
いくつかのテクニックが注目に値します。
@@ -47,6 +150,7 @@ HELPFUL: ``のケースでは、`HighlightDirective`を、入力ボック
しかし、抽象化よりも簡単で明確な場合は、`nativeElement`を利用してください。
- Angularは、適用された要素のインジェクターにディレクティブを追加します。
- デフォルトの色に対するテストでは、2番目の``のインジェクターを使用して、その`HighlightDirective`インスタンスとその`defaultColor`を取得します。
+ デフォルトの色に対するテストでは、2番目の``のインジェクターを使用して、その`Highlight`インスタンスとその`defaultColor`を取得します。
- `DebugElement.properties`は、ディレクティブによって設定された人工的なカスタムプロパティにアクセスできます。
+
diff --git a/adev-ja/src/content/guide/testing/components-basics.en.md b/adev-ja/src/content/guide/testing/components-basics.en.md
index 4341bdd006..82dce45e08 100644
--- a/adev-ja/src/content/guide/testing/components-basics.en.md
+++ b/adev-ja/src/content/guide/testing/components-basics.en.md
@@ -17,9 +17,9 @@ Classes alone cannot tell you if the component is going to render properly, resp
- Is `Lightswitch.clicked()` bound to anything such that the user can invoke it?
- Is the `Lightswitch.message` displayed?
-- Can the user actually select the hero displayed by `DashboardHeroComponent`?
+- Can the user actually select the hero displayed by the `DashboardHero` component?
- Is the hero name displayed as expected \(such as uppercase\)?
-- Is the welcome message displayed by the template of `WelcomeComponent`?
+- Is the welcome message displayed by the template of the `Welcome` component?
These might not be troubling questions for the preceding simple components illustrated.
But many components have complex interactions with the DOM elements described in their templates, causing HTML to appear and disappear as the component state changes.
@@ -32,19 +32,37 @@ To write these kinds of test, you'll use additional features of the `TestBed` as
The CLI creates an initial test file for you by default when you ask it to generate a new component.
-For example, the following CLI command generates a `BannerComponent` in the `app/banner` folder \(with inline template and styles\):
+For example, the following CLI command generates a `Banner` component in the `app/banner` folder \(with inline template and styles\):
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-It also generates an initial test file for the component, `banner-external.component.spec.ts`, that looks like this:
+It also generates an initial test file for the component, `banner.spec.ts`, that looks like this:
-;
-Refer to the [waitForAsync](guide/testing/components-scenarios#waitForAsync) section for more details.
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### Reduce the setup
@@ -55,25 +73,30 @@ The rest of the file is boilerplate setup code anticipating more advanced tests
You'll learn about these advanced test features in the following sections.
For now, you can radically reduce this test file to a more manageable size:
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ The value of `ComponentFixture.nativeElement` has the `any` type.
Later you'll encounter the `DebugElement.nativeElement` and it too has the `any` type.
Angular can't know at compile time what kind of HTML element the `nativeElement` is or if it even is an HTML element.
-The application might be running on a _non-browser platform_, such as the server or a [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API), where the element might have a diminished API or not exist at all.
+The application might be running on a _non-browser platform_, such as the server or a node environment, where the element might have a diminished API or not exist at all.
The tests in this guide are designed to run in a browser so a `nativeElement` value will always be an `HTMLElement` or one of its derived classes.
@@ -115,17 +178,28 @@ Knowing that it is an `HTMLElement` of some sort, use the standard HTML `querySe
Here's another test that calls `HTMLElement.querySelector` to get the paragraph element and look for the banner text:
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
The Angular _fixture_ provides the component's element directly through the `fixture.nativeElement`.
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
The `DebugElement` has other methods and properties that are useful in tests, as you'll see elsewhere in this guide.
You import the `DebugElement` symbol from the Angular core library.
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
Some noteworthy observations:
diff --git a/adev-ja/src/content/guide/testing/components-basics.md b/adev-ja/src/content/guide/testing/components-basics.md
index 833d620f05..550c14cf83 100644
--- a/adev-ja/src/content/guide/testing/components-basics.md
+++ b/adev-ja/src/content/guide/testing/components-basics.md
@@ -17,9 +17,9 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
- `Lightswitch.clicked()` はユーザーが呼び出せるように何かとバインドされていますか？
- `Lightswitch.message` は表示されますか？
-- ユーザーは `DashboardHeroComponent` によって表示されるヒーローを実際に選択できますか？
+- ユーザーは `DashboardHero` コンポーネントによって表示されるヒーローを実際に選択できますか？
- ヒーローの名前は期待通り（たとえば、大文字）に表示されますか？
-- `WelcomeComponent` のテンプレートによってウェルカムメッセージは表示されますか？
+- `Welcome` コンポーネントのテンプレートによってウェルカムメッセージは表示されますか？
これらの質問は、説明した前の簡単なコンポーネントにとっては問題ないかもしれません。
しかし、多くのコンポーネントは、そのテンプレートで記述されているDOM要素との複雑な対話を持ち、コンポーネントの状態が変わるとHTMLが表示および非表示になります。
@@ -32,19 +32,37 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
CLIは、新しいコンポーネントの生成を要求するときに、デフォルトで初期テストファイルを自動的に生成します。
-たとえば、次のCLIコマンドは `app/banner` フォルダーに `BannerComponent` を生成します（インラインテンプレートとスタイル付き）。
+たとえば、次のCLIコマンドは `app/banner` フォルダーに `Banner` コンポーネントを生成します（インラインテンプレートとスタイル付き）。
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-また、コンポーネントの初期テストファイル `banner-external.component.spec.ts` も生成し、次のようになります。
+また、コンポーネントの初期テストファイル `banner.spec.ts` も生成し、次のようになります。
-;
-詳細については、[waitForAsync](guide/testing/components-scenarios#waitForAsync) セクションを参照してください。
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### セットアップの削減
@@ -55,25 +73,30 @@ HELPFUL: `compileComponents` は非同期であるため、`@angular/core/testin
これらの高度なテスト機能については、次のセクションで説明します。
今のところ、このテストファイルをより管理しやすいサイズに大幅に縮小できます。
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ fixtureを介してコンポーネントインスタンスにアクセスし、J
後で `DebugElement.nativeElement` に遭遇しますが、これも `any` 型です。
Angularは、コンパイル時に `nativeElement` がどのようなHTML要素であるか、あるいはHTML要素であるかどうかすらを知ることができません。
-アプリケーションは、サーバーや [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API) などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
+アプリケーションは、サーバーやNode環境などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
このガイドのテストはブラウザで実行されるように設計されているため、`nativeElement` の値は常に `HTMLElement` またはその派生クラスのいずれかになります。
@@ -115,17 +178,28 @@ Angularは、コンパイル時に `nativeElement` がどのようなHTML要素
次に、`HTMLElement.querySelector` を呼び出して段落要素を取得し、バナーテキストを探すテストを示します。
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
Angularの _fixture_ は、`fixture.nativeElement` を介してコンポーネントの要素を直接提供します。
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
`DebugElement` には、このガイドの他の場所で説明されているように、テストで役立つ他のメソッドとプロパティがあります。
Angularコアライブラリから `DebugElement` シンボルをインポートします。
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
注目すべき観察結果をいくつか紹介します。
diff --git a/adev-ja/src/content/guide/testing/components-scenarios.en.md b/adev-ja/src/content/guide/testing/components-scenarios.en.md
index 8cc4023f01..a2699bd4b3 100644
--- a/adev-ja/src/content/guide/testing/components-scenarios.en.md
+++ b/adev-ja/src/content/guide/testing/components-scenarios.en.md
@@ -4,11 +4,22 @@ This guide explores common component testing use cases.
## Component binding
-In the example application, the `BannerComponent` presents static title text in the HTML template.
+In the example application, the `Banner` component presents static title text in the HTML template.
-After a few changes, the `BannerComponent` presents a dynamic title by binding to the component's `title` property like this.
+After a few changes, the `Banner` component presents a dynamic title by binding to the component's `title` property like this.
-
{{ title() }}
',
+ styles: ['h1 { color: green; font-size: 350%}'],
+})
+export class Banner {
+ title = signal('Test Tour of Heroes');
+}
+```
As minimal as this is, you decide to add a test to confirm that component actually displays the right content where you think it should.
@@ -18,75 +29,86 @@ You'll write a sequence of tests that inspect the value of the `` element th
You update the `beforeEach` to find that element with a standard HTML `querySelector` and assign it to the `h1` variable.
-;
+let h1: HTMLElement;
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance; // Banner test instance
+ h1 = fixture.nativeElement.querySelector('h1');
+});
+```
### `createComponent()` does not bind data
For your first test you'd like to see that the screen displays the default `title`.
Your instinct is to write a test that immediately inspects the `` like this:
-
-
+```shell {hideCopy}
expected '' to contain 'Test Tour of Heroes'.
-
-
+```
Binding happens when Angular performs **change detection**.
In production, change detection kicks in automatically when Angular creates a component or the user enters a keystroke, for example.
-The `TestBed.createComponent` does not trigger change detection by default; a fact confirmed in the revised test:
+The `TestBed.createComponent` does not trigger change detection synchronously; a fact confirmed in the revised test:
-` have the expected title.
-{{ welcome() }}
',
+})
+export class Welcome {
+ private userAuth = inject(UserAuthentication);
+ welcome = signal(
+ this.userAuth.isLoggedIn() ? `Welcome, ${this.userAuth.user().name}` : 'Please log in.',
+ );
+}
+```
-The `WelcomeComponent` has decision logic that interacts with the service, logic that makes this component worth testing.
+The `Welcome` component has decision logic that interacts with the service, logic that makes this component worth testing.
### Provide service test doubles
A _component-under-test_ doesn't have to be provided with real services.
-Injecting the real `UserService` could be difficult.
+Injecting the real `UserAuthentication` could be difficult.
The real service might ask the user for login credentials and attempt to reach an authentication server.
These behaviors can be hard to intercept. Be aware that using test doubles makes the test behave differently from production so use them sparingly.
### Get injected services
-The tests need access to the `UserService` injected into the `WelcomeComponent`.
+The tests need access to the `UserAuthentication` injected into the `Welcome` component.
Angular has a hierarchical injection system.
There can be injectors at multiple levels, from the root injector created by the `TestBed` down through the component tree.
@@ -158,7 +184,10 @@ The safest way to get the injected service, the way that **_always works_**,
is to **get it from the injector of the _component-under-test_**.
The component injector is a property of the fixture's `DebugElement`.
-;
+let comp: Welcome;
+let userAuth: UserAuthentication; // the TestBed injected service
+let el: HTMLElement; // the DOM element with the welcome message
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Welcome);
+ comp = fixture.componentInstance;
+
+ // UserAuthentication from the root injector
+ userAuth = TestBed.inject(UserAuthentication);
+
+ // get the "welcome" element by CSS selector (e.g., by class name)
+ el = fixture.nativeElement.querySelector('.welcome');
+});
+```
And here are some tests:
-
+ {{ quote | async }}
+
+
+@if (errorMessage()) {
+ {{ errorMessage() }}
+}
+```
HELPFUL: The value of the component's `quote` property passes through an `AsyncPipe`.
That means the property returns either a `Promise` or an `Observable`.
-In this example, the `TwainComponent.getQuote()` method tells you that the `quote` property returns an `Observable`.
+In this example, the `TwainQuotes.getQuote()` method tells you that the `quote` property returns an `Observable`.
-
-
-fakeAsync(() => { /_test body_/ })
-
-
-
-The `fakeAsync()` function enables a linear coding style by running the test body in a special `fakeAsync test zone`.
-The test body appears to be synchronous.
-There is no nested syntax \(like a `Promise.then()`\) to disrupt the flow of control.
-
-HELPFUL: Limitation: The `fakeAsync()` function won't work if the test body makes an `XMLHttpRequest` \(XHR\) call.
-XHR calls within a test are rare, but if you need to call XHR, use `waitForAsync()`.
-
-IMPORTANT: Be aware that asynchronous tasks that happen inside the `fakeAsync` zone need to be manually executed with `flush` or `tick`. If you attempt to
-wait for them to complete (i.e. using `fixture.whenStable`) without using the
-`fakeAsync` test helpers to advance time, your test will likely fail. See below for more information.
-
-### The `tick()` function
-
-You do have to call [tick()](api/core/testing/tick) to advance the virtual clock.
-
-Calling [tick()](api/core/testing/tick) simulates the passage of time until all pending asynchronous activities finish.
-In this case, it waits for the observable's `setTimeout()`.
-The [tick()](api/core/testing/tick) function accepts `millis` and `tickOptions` as parameters. The `millis` parameter specifies how much the virtual clock advances and defaults to `0` if not provided.
-For example, if you have a `setTimeout(fn, 100)` in a `fakeAsync()` test, you need to use `tick(100)` to trigger the fn callback.
-The optional `tickOptions` parameter has a property named `processNewMacroTasksSynchronously`. The `processNewMacroTasksSynchronously` property represents whether to invoke new generated macro tasks when ticking and defaults to `true`.
+In the case your async service relies on the `HttpClient` to load remote data, it is recommended to return mock responses at the HTTP level with the `HttpTestingController`.
-
-
+The stub is designed in such a way that any component or service that injects it will receive the stubbed implementation.
+It means that any call to `getQuote` receives an observable with a test quote.
-If you want to support such a case, you need to define the macro task you want to support in `beforeEach()`.
-For example:
-
-
', () => {
+ const h2: HTMLElement = fixture.nativeElement.querySelector('h2');
+ const bgColor = h2.style.backgroundColor;
+ expect(bgColor).toBe('skyblue');
+});
しかし、単一のユースケースをテストしても、ディレクティブの機能のすべてを調べられるとは限りません。
ディレクティブを使用するすべてのコンポーネントを見つけてテストすることは、面倒で壊れやすく、完全なカバレッジを実現する可能性もほとんどありません。
@@ -26,16 +70,75 @@ _クラスのみのテスト_は役立つ場合がありますが、このディ
より良い解決策は、ディレクティブのすべての適用方法を示す人工的なテストコンポーネントを作成することです。
-Something Yellow
+ The Default (Gray)
+ No Highlight
+
+ `,
+})
+class Test {}
+```
-HELPFUL: ``のケースでは、`HighlightDirective`を、入力ボックス内の色の値の名前とバインドしています。
+HELPFUL: ``のケースでは、`Highlight`を、入力ボックス内の色の値の名前とバインドしています。
初期値は単語"cyan"であり、これは入力ボックスの背景色になります。
このコンポーネントのテストをいくつか紹介します。
-;
+let des: DebugElement[]; // the three elements w/ the directive
+
+beforeEach(async () => {
+ fixture = TestBed.createComponent(Test);
+ await fixture.whenStable();
+
+ // all elements with an attached Highlight
+ des = fixture.debugElement.queryAll(By.directive(Highlight));
+});
+
+// color tests
+it('should have three highlighted elements', () => {
+ expect(des.length).toBe(3);
+});
+
+it('should color 1st background "yellow"', () => {
+ const bgColor = des[0].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe('yellow');
+});
+
+it('should color 2nd background w/ default color', () => {
+ const dir = des[1].injector.get(Highlight);
+ const bgColor = des[1].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe(dir.defaultColor);
+});
+
+it('should bind background to value color', async () => {
+ // easier to work with nativeElement
+ const input = des[2].nativeElement as HTMLInputElement;
+ expect(input.style.backgroundColor, 'initial backgroundColor').toBe('cyan');
+
+ input.value = 'green';
+
+ // Dispatch a DOM event so that Angular responds to the input value change.
+ input.dispatchEvent(new Event('input'));
+ await fixture.whenStable();
+
+ expect(input.style.backgroundColor, 'changed backgroundColor').toBe('green');
+});
+
+it('bare should not have a backgroundColor', () => {
+ // the h2 without the Highlight directive
+ const bareH2 = fixture.debugElement.query(By.css('h2:not([highlight])'));
+
+ expect(bareH2.styles.backgroundColor).toBeUndefined();
+});
+```
いくつかのテクニックが注目に値します。
@@ -47,6 +150,7 @@ HELPFUL: ``のケースでは、`HighlightDirective`を、入力ボック
しかし、抽象化よりも簡単で明確な場合は、`nativeElement`を利用してください。
- Angularは、適用された要素のインジェクターにディレクティブを追加します。
- デフォルトの色に対するテストでは、2番目の``のインジェクターを使用して、その`HighlightDirective`インスタンスとその`defaultColor`を取得します。
+ デフォルトの色に対するテストでは、2番目の``のインジェクターを使用して、その`Highlight`インスタンスとその`defaultColor`を取得します。
- `DebugElement.properties`は、ディレクティブによって設定された人工的なカスタムプロパティにアクセスできます。
+
diff --git a/adev-ja/src/content/guide/testing/components-basics.en.md b/adev-ja/src/content/guide/testing/components-basics.en.md
index 4341bdd006..82dce45e08 100644
--- a/adev-ja/src/content/guide/testing/components-basics.en.md
+++ b/adev-ja/src/content/guide/testing/components-basics.en.md
@@ -17,9 +17,9 @@ Classes alone cannot tell you if the component is going to render properly, resp
- Is `Lightswitch.clicked()` bound to anything such that the user can invoke it?
- Is the `Lightswitch.message` displayed?
-- Can the user actually select the hero displayed by `DashboardHeroComponent`?
+- Can the user actually select the hero displayed by the `DashboardHero` component?
- Is the hero name displayed as expected \(such as uppercase\)?
-- Is the welcome message displayed by the template of `WelcomeComponent`?
+- Is the welcome message displayed by the template of the `Welcome` component?
These might not be troubling questions for the preceding simple components illustrated.
But many components have complex interactions with the DOM elements described in their templates, causing HTML to appear and disappear as the component state changes.
@@ -32,19 +32,37 @@ To write these kinds of test, you'll use additional features of the `TestBed` as
The CLI creates an initial test file for you by default when you ask it to generate a new component.
-For example, the following CLI command generates a `BannerComponent` in the `app/banner` folder \(with inline template and styles\):
+For example, the following CLI command generates a `Banner` component in the `app/banner` folder \(with inline template and styles\):
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-It also generates an initial test file for the component, `banner-external.component.spec.ts`, that looks like this:
+It also generates an initial test file for the component, `banner.spec.ts`, that looks like this:
-;
-Refer to the [waitForAsync](guide/testing/components-scenarios#waitForAsync) section for more details.
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### Reduce the setup
@@ -55,25 +73,30 @@ The rest of the file is boilerplate setup code anticipating more advanced tests
You'll learn about these advanced test features in the following sections.
For now, you can radically reduce this test file to a more manageable size:
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ The value of `ComponentFixture.nativeElement` has the `any` type.
Later you'll encounter the `DebugElement.nativeElement` and it too has the `any` type.
Angular can't know at compile time what kind of HTML element the `nativeElement` is or if it even is an HTML element.
-The application might be running on a _non-browser platform_, such as the server or a [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API), where the element might have a diminished API or not exist at all.
+The application might be running on a _non-browser platform_, such as the server or a node environment, where the element might have a diminished API or not exist at all.
The tests in this guide are designed to run in a browser so a `nativeElement` value will always be an `HTMLElement` or one of its derived classes.
@@ -115,17 +178,28 @@ Knowing that it is an `HTMLElement` of some sort, use the standard HTML `querySe
Here's another test that calls `HTMLElement.querySelector` to get the paragraph element and look for the banner text:
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
The Angular _fixture_ provides the component's element directly through the `fixture.nativeElement`.
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
The `DebugElement` has other methods and properties that are useful in tests, as you'll see elsewhere in this guide.
You import the `DebugElement` symbol from the Angular core library.
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
Some noteworthy observations:
diff --git a/adev-ja/src/content/guide/testing/components-basics.md b/adev-ja/src/content/guide/testing/components-basics.md
index 833d620f05..550c14cf83 100644
--- a/adev-ja/src/content/guide/testing/components-basics.md
+++ b/adev-ja/src/content/guide/testing/components-basics.md
@@ -17,9 +17,9 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
- `Lightswitch.clicked()` はユーザーが呼び出せるように何かとバインドされていますか？
- `Lightswitch.message` は表示されますか？
-- ユーザーは `DashboardHeroComponent` によって表示されるヒーローを実際に選択できますか？
+- ユーザーは `DashboardHero` コンポーネントによって表示されるヒーローを実際に選択できますか？
- ヒーローの名前は期待通り（たとえば、大文字）に表示されますか？
-- `WelcomeComponent` のテンプレートによってウェルカムメッセージは表示されますか？
+- `Welcome` コンポーネントのテンプレートによってウェルカムメッセージは表示されますか？
これらの質問は、説明した前の簡単なコンポーネントにとっては問題ないかもしれません。
しかし、多くのコンポーネントは、そのテンプレートで記述されているDOM要素との複雑な対話を持ち、コンポーネントの状態が変わるとHTMLが表示および非表示になります。
@@ -32,19 +32,37 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
CLIは、新しいコンポーネントの生成を要求するときに、デフォルトで初期テストファイルを自動的に生成します。
-たとえば、次のCLIコマンドは `app/banner` フォルダーに `BannerComponent` を生成します（インラインテンプレートとスタイル付き）。
+たとえば、次のCLIコマンドは `app/banner` フォルダーに `Banner` コンポーネントを生成します（インラインテンプレートとスタイル付き）。
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-また、コンポーネントの初期テストファイル `banner-external.component.spec.ts` も生成し、次のようになります。
+また、コンポーネントの初期テストファイル `banner.spec.ts` も生成し、次のようになります。
-;
-詳細については、[waitForAsync](guide/testing/components-scenarios#waitForAsync) セクションを参照してください。
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### セットアップの削減
@@ -55,25 +73,30 @@ HELPFUL: `compileComponents` は非同期であるため、`@angular/core/testin
これらの高度なテスト機能については、次のセクションで説明します。
今のところ、このテストファイルをより管理しやすいサイズに大幅に縮小できます。
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ fixtureを介してコンポーネントインスタンスにアクセスし、J
後で `DebugElement.nativeElement` に遭遇しますが、これも `any` 型です。
Angularは、コンパイル時に `nativeElement` がどのようなHTML要素であるか、あるいはHTML要素であるかどうかすらを知ることができません。
-アプリケーションは、サーバーや [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API) などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
+アプリケーションは、サーバーやNode環境などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
このガイドのテストはブラウザで実行されるように設計されているため、`nativeElement` の値は常に `HTMLElement` またはその派生クラスのいずれかになります。
@@ -115,17 +178,28 @@ Angularは、コンパイル時に `nativeElement` がどのようなHTML要素
次に、`HTMLElement.querySelector` を呼び出して段落要素を取得し、バナーテキストを探すテストを示します。
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
Angularの _fixture_ は、`fixture.nativeElement` を介してコンポーネントの要素を直接提供します。
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
`DebugElement` には、このガイドの他の場所で説明されているように、テストで役立つ他のメソッドとプロパティがあります。
Angularコアライブラリから `DebugElement` シンボルをインポートします。
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
注目すべき観察結果をいくつか紹介します。
diff --git a/adev-ja/src/content/guide/testing/components-scenarios.en.md b/adev-ja/src/content/guide/testing/components-scenarios.en.md
index 8cc4023f01..a2699bd4b3 100644
--- a/adev-ja/src/content/guide/testing/components-scenarios.en.md
+++ b/adev-ja/src/content/guide/testing/components-scenarios.en.md
@@ -4,11 +4,22 @@ This guide explores common component testing use cases.
## Component binding
-In the example application, the `BannerComponent` presents static title text in the HTML template.
+In the example application, the `Banner` component presents static title text in the HTML template.
-After a few changes, the `BannerComponent` presents a dynamic title by binding to the component's `title` property like this.
+After a few changes, the `Banner` component presents a dynamic title by binding to the component's `title` property like this.
-
{{ title() }}
',
+ styles: ['h1 { color: green; font-size: 350%}'],
+})
+export class Banner {
+ title = signal('Test Tour of Heroes');
+}
+```
As minimal as this is, you decide to add a test to confirm that component actually displays the right content where you think it should.
@@ -18,75 +29,86 @@ You'll write a sequence of tests that inspect the value of the `` element th
You update the `beforeEach` to find that element with a standard HTML `querySelector` and assign it to the `h1` variable.
-;
+let h1: HTMLElement;
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance; // Banner test instance
+ h1 = fixture.nativeElement.querySelector('h1');
+});
+```
### `createComponent()` does not bind data
For your first test you'd like to see that the screen displays the default `title`.
Your instinct is to write a test that immediately inspects the `` like this:
-
-
+```shell {hideCopy}
expected '' to contain 'Test Tour of Heroes'.
-
-
+```
Binding happens when Angular performs **change detection**.
In production, change detection kicks in automatically when Angular creates a component or the user enters a keystroke, for example.
-The `TestBed.createComponent` does not trigger change detection by default; a fact confirmed in the revised test:
+The `TestBed.createComponent` does not trigger change detection synchronously; a fact confirmed in the revised test:
-` have the expected title.
-{{ welcome() }}
',
+})
+export class Welcome {
+ private userAuth = inject(UserAuthentication);
+ welcome = signal(
+ this.userAuth.isLoggedIn() ? `Welcome, ${this.userAuth.user().name}` : 'Please log in.',
+ );
+}
+```
-The `WelcomeComponent` has decision logic that interacts with the service, logic that makes this component worth testing.
+The `Welcome` component has decision logic that interacts with the service, logic that makes this component worth testing.
### Provide service test doubles
A _component-under-test_ doesn't have to be provided with real services.
-Injecting the real `UserService` could be difficult.
+Injecting the real `UserAuthentication` could be difficult.
The real service might ask the user for login credentials and attempt to reach an authentication server.
These behaviors can be hard to intercept. Be aware that using test doubles makes the test behave differently from production so use them sparingly.
### Get injected services
-The tests need access to the `UserService` injected into the `WelcomeComponent`.
+The tests need access to the `UserAuthentication` injected into the `Welcome` component.
Angular has a hierarchical injection system.
There can be injectors at multiple levels, from the root injector created by the `TestBed` down through the component tree.
@@ -158,7 +184,10 @@ The safest way to get the injected service, the way that **_always works_**,
is to **get it from the injector of the _component-under-test_**.
The component injector is a property of the fixture's `DebugElement`.
-;
+let comp: Welcome;
+let userAuth: UserAuthentication; // the TestBed injected service
+let el: HTMLElement; // the DOM element with the welcome message
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Welcome);
+ comp = fixture.componentInstance;
+
+ // UserAuthentication from the root injector
+ userAuth = TestBed.inject(UserAuthentication);
+
+ // get the "welcome" element by CSS selector (e.g., by class name)
+ el = fixture.nativeElement.querySelector('.welcome');
+});
+```
And here are some tests:
-
+ {{ quote | async }}
+
+
+@if (errorMessage()) {
+ {{ errorMessage() }}
+}
+```
HELPFUL: The value of the component's `quote` property passes through an `AsyncPipe`.
That means the property returns either a `Promise` or an `Observable`.
-In this example, the `TwainComponent.getQuote()` method tells you that the `quote` property returns an `Observable`.
+In this example, the `TwainQuotes.getQuote()` method tells you that the `quote` property returns an `Observable`.
-
-
-fakeAsync(() => { /_test body_/ })
-
-
-
-The `fakeAsync()` function enables a linear coding style by running the test body in a special `fakeAsync test zone`.
-The test body appears to be synchronous.
-There is no nested syntax \(like a `Promise.then()`\) to disrupt the flow of control.
-
-HELPFUL: Limitation: The `fakeAsync()` function won't work if the test body makes an `XMLHttpRequest` \(XHR\) call.
-XHR calls within a test are rare, but if you need to call XHR, use `waitForAsync()`.
-
-IMPORTANT: Be aware that asynchronous tasks that happen inside the `fakeAsync` zone need to be manually executed with `flush` or `tick`. If you attempt to
-wait for them to complete (i.e. using `fixture.whenStable`) without using the
-`fakeAsync` test helpers to advance time, your test will likely fail. See below for more information.
-
-### The `tick()` function
-
-You do have to call [tick()](api/core/testing/tick) to advance the virtual clock.
-
-Calling [tick()](api/core/testing/tick) simulates the passage of time until all pending asynchronous activities finish.
-In this case, it waits for the observable's `setTimeout()`.
-The [tick()](api/core/testing/tick) function accepts `millis` and `tickOptions` as parameters. The `millis` parameter specifies how much the virtual clock advances and defaults to `0` if not provided.
-For example, if you have a `setTimeout(fn, 100)` in a `fakeAsync()` test, you need to use `tick(100)` to trigger the fn callback.
-The optional `tickOptions` parameter has a property named `processNewMacroTasksSynchronously`. The `processNewMacroTasksSynchronously` property represents whether to invoke new generated macro tasks when ticking and defaults to `true`.
+In the case your async service relies on the `HttpClient` to load remote data, it is recommended to return mock responses at the HTTP level with the `HttpTestingController`.
-
-
+The stub is designed in such a way that any component or service that injects it will receive the stubbed implementation.
+It means that any call to `getQuote` receives an observable with a test quote.
-If you want to support such a case, you need to define the macro task you want to support in `beforeEach()`.
-For example:
-
-
background "yellow"', () => {
+ const bgColor = des[0].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe('yellow');
+});
+
+it('should color 2nd background w/ default color', () => {
+ const dir = des[1].injector.get(Highlight);
+ const bgColor = des[1].nativeElement.style.backgroundColor;
+ expect(bgColor).toBe(dir.defaultColor);
+});
+
+it('should bind background to value color', async () => {
+ // easier to work with nativeElement
+ const input = des[2].nativeElement as HTMLInputElement;
+ expect(input.style.backgroundColor, 'initial backgroundColor').toBe('cyan');
+
+ input.value = 'green';
+
+ // Dispatch a DOM event so that Angular responds to the input value change.
+ input.dispatchEvent(new Event('input'));
+ await fixture.whenStable();
+
+ expect(input.style.backgroundColor, 'changed backgroundColor').toBe('green');
+});
+
+it('bare should not have a backgroundColor', () => {
+ // the h2 without the Highlight directive
+ const bareH2 = fixture.debugElement.query(By.css('h2:not([highlight])'));
+
+ expect(bareH2.styles.backgroundColor).toBeUndefined();
+});
+```
いくつかのテクニックが注目に値します。
@@ -47,6 +150,7 @@ HELPFUL: ``のケースでは、`HighlightDirective`を、入力ボック
しかし、抽象化よりも簡単で明確な場合は、`nativeElement`を利用してください。
- Angularは、適用された要素のインジェクターにディレクティブを追加します。
- デフォルトの色に対するテストでは、2番目の``のインジェクターを使用して、その`HighlightDirective`インスタンスとその`defaultColor`を取得します。
+ デフォルトの色に対するテストでは、2番目の``のインジェクターを使用して、その`Highlight`インスタンスとその`defaultColor`を取得します。
- `DebugElement.properties`は、ディレクティブによって設定された人工的なカスタムプロパティにアクセスできます。
+
diff --git a/adev-ja/src/content/guide/testing/components-basics.en.md b/adev-ja/src/content/guide/testing/components-basics.en.md
index 4341bdd006..82dce45e08 100644
--- a/adev-ja/src/content/guide/testing/components-basics.en.md
+++ b/adev-ja/src/content/guide/testing/components-basics.en.md
@@ -17,9 +17,9 @@ Classes alone cannot tell you if the component is going to render properly, resp
- Is `Lightswitch.clicked()` bound to anything such that the user can invoke it?
- Is the `Lightswitch.message` displayed?
-- Can the user actually select the hero displayed by `DashboardHeroComponent`?
+- Can the user actually select the hero displayed by the `DashboardHero` component?
- Is the hero name displayed as expected \(such as uppercase\)?
-- Is the welcome message displayed by the template of `WelcomeComponent`?
+- Is the welcome message displayed by the template of the `Welcome` component?
These might not be troubling questions for the preceding simple components illustrated.
But many components have complex interactions with the DOM elements described in their templates, causing HTML to appear and disappear as the component state changes.
@@ -32,19 +32,37 @@ To write these kinds of test, you'll use additional features of the `TestBed` as
The CLI creates an initial test file for you by default when you ask it to generate a new component.
-For example, the following CLI command generates a `BannerComponent` in the `app/banner` folder \(with inline template and styles\):
+For example, the following CLI command generates a `Banner` component in the `app/banner` folder \(with inline template and styles\):
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-It also generates an initial test file for the component, `banner-external.component.spec.ts`, that looks like this:
+It also generates an initial test file for the component, `banner.spec.ts`, that looks like this:
-;
-Refer to the [waitForAsync](guide/testing/components-scenarios#waitForAsync) section for more details.
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### Reduce the setup
@@ -55,25 +73,30 @@ The rest of the file is boilerplate setup code anticipating more advanced tests
You'll learn about these advanced test features in the following sections.
For now, you can radically reduce this test file to a more manageable size:
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ The value of `ComponentFixture.nativeElement` has the `any` type.
Later you'll encounter the `DebugElement.nativeElement` and it too has the `any` type.
Angular can't know at compile time what kind of HTML element the `nativeElement` is or if it even is an HTML element.
-The application might be running on a _non-browser platform_, such as the server or a [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API), where the element might have a diminished API or not exist at all.
+The application might be running on a _non-browser platform_, such as the server or a node environment, where the element might have a diminished API or not exist at all.
The tests in this guide are designed to run in a browser so a `nativeElement` value will always be an `HTMLElement` or one of its derived classes.
@@ -115,17 +178,28 @@ Knowing that it is an `HTMLElement` of some sort, use the standard HTML `querySe
Here's another test that calls `HTMLElement.querySelector` to get the paragraph element and look for the banner text:
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
The Angular _fixture_ provides the component's element directly through the `fixture.nativeElement`.
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
The `DebugElement` has other methods and properties that are useful in tests, as you'll see elsewhere in this guide.
You import the `DebugElement` symbol from the Angular core library.
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
Some noteworthy observations:
diff --git a/adev-ja/src/content/guide/testing/components-basics.md b/adev-ja/src/content/guide/testing/components-basics.md
index 833d620f05..550c14cf83 100644
--- a/adev-ja/src/content/guide/testing/components-basics.md
+++ b/adev-ja/src/content/guide/testing/components-basics.md
@@ -17,9 +17,9 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
- `Lightswitch.clicked()` はユーザーが呼び出せるように何かとバインドされていますか？
- `Lightswitch.message` は表示されますか？
-- ユーザーは `DashboardHeroComponent` によって表示されるヒーローを実際に選択できますか？
+- ユーザーは `DashboardHero` コンポーネントによって表示されるヒーローを実際に選択できますか？
- ヒーローの名前は期待通り（たとえば、大文字）に表示されますか？
-- `WelcomeComponent` のテンプレートによってウェルカムメッセージは表示されますか？
+- `Welcome` コンポーネントのテンプレートによってウェルカムメッセージは表示されますか？
これらの質問は、説明した前の簡単なコンポーネントにとっては問題ないかもしれません。
しかし、多くのコンポーネントは、そのテンプレートで記述されているDOM要素との複雑な対話を持ち、コンポーネントの状態が変わるとHTMLが表示および非表示になります。
@@ -32,19 +32,37 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
CLIは、新しいコンポーネントの生成を要求するときに、デフォルトで初期テストファイルを自動的に生成します。
-たとえば、次のCLIコマンドは `app/banner` フォルダーに `BannerComponent` を生成します（インラインテンプレートとスタイル付き）。
+たとえば、次のCLIコマンドは `app/banner` フォルダーに `Banner` コンポーネントを生成します（インラインテンプレートとスタイル付き）。
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-また、コンポーネントの初期テストファイル `banner-external.component.spec.ts` も生成し、次のようになります。
+また、コンポーネントの初期テストファイル `banner.spec.ts` も生成し、次のようになります。
-;
-詳細については、[waitForAsync](guide/testing/components-scenarios#waitForAsync) セクションを参照してください。
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### セットアップの削減
@@ -55,25 +73,30 @@ HELPFUL: `compileComponents` は非同期であるため、`@angular/core/testin
これらの高度なテスト機能については、次のセクションで説明します。
今のところ、このテストファイルをより管理しやすいサイズに大幅に縮小できます。
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ fixtureを介してコンポーネントインスタンスにアクセスし、J
後で `DebugElement.nativeElement` に遭遇しますが、これも `any` 型です。
Angularは、コンパイル時に `nativeElement` がどのようなHTML要素であるか、あるいはHTML要素であるかどうかすらを知ることができません。
-アプリケーションは、サーバーや [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API) などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
+アプリケーションは、サーバーやNode環境などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
このガイドのテストはブラウザで実行されるように設計されているため、`nativeElement` の値は常に `HTMLElement` またはその派生クラスのいずれかになります。
@@ -115,17 +178,28 @@ Angularは、コンパイル時に `nativeElement` がどのようなHTML要素
次に、`HTMLElement.querySelector` を呼び出して段落要素を取得し、バナーテキストを探すテストを示します。
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
Angularの _fixture_ は、`fixture.nativeElement` を介してコンポーネントの要素を直接提供します。
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
`DebugElement` には、このガイドの他の場所で説明されているように、テストで役立つ他のメソッドとプロパティがあります。
Angularコアライブラリから `DebugElement` シンボルをインポートします。
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
注目すべき観察結果をいくつか紹介します。
diff --git a/adev-ja/src/content/guide/testing/components-scenarios.en.md b/adev-ja/src/content/guide/testing/components-scenarios.en.md
index 8cc4023f01..a2699bd4b3 100644
--- a/adev-ja/src/content/guide/testing/components-scenarios.en.md
+++ b/adev-ja/src/content/guide/testing/components-scenarios.en.md
@@ -4,11 +4,22 @@ This guide explores common component testing use cases.
## Component binding
-In the example application, the `BannerComponent` presents static title text in the HTML template.
+In the example application, the `Banner` component presents static title text in the HTML template.
-After a few changes, the `BannerComponent` presents a dynamic title by binding to the component's `title` property like this.
+After a few changes, the `Banner` component presents a dynamic title by binding to the component's `title` property like this.
-
{{ title() }}
',
+ styles: ['h1 { color: green; font-size: 350%}'],
+})
+export class Banner {
+ title = signal('Test Tour of Heroes');
+}
+```
As minimal as this is, you decide to add a test to confirm that component actually displays the right content where you think it should.
@@ -18,75 +29,86 @@ You'll write a sequence of tests that inspect the value of the `` element th
You update the `beforeEach` to find that element with a standard HTML `querySelector` and assign it to the `h1` variable.
-;
+let h1: HTMLElement;
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance; // Banner test instance
+ h1 = fixture.nativeElement.querySelector('h1');
+});
+```
### `createComponent()` does not bind data
For your first test you'd like to see that the screen displays the default `title`.
Your instinct is to write a test that immediately inspects the `` like this:
-
-
+```shell {hideCopy}
expected '' to contain 'Test Tour of Heroes'.
-
-
+```
Binding happens when Angular performs **change detection**.
In production, change detection kicks in automatically when Angular creates a component or the user enters a keystroke, for example.
-The `TestBed.createComponent` does not trigger change detection by default; a fact confirmed in the revised test:
+The `TestBed.createComponent` does not trigger change detection synchronously; a fact confirmed in the revised test:
-` have the expected title.
-{{ welcome() }}
',
+})
+export class Welcome {
+ private userAuth = inject(UserAuthentication);
+ welcome = signal(
+ this.userAuth.isLoggedIn() ? `Welcome, ${this.userAuth.user().name}` : 'Please log in.',
+ );
+}
+```
-The `WelcomeComponent` has decision logic that interacts with the service, logic that makes this component worth testing.
+The `Welcome` component has decision logic that interacts with the service, logic that makes this component worth testing.
### Provide service test doubles
A _component-under-test_ doesn't have to be provided with real services.
-Injecting the real `UserService` could be difficult.
+Injecting the real `UserAuthentication` could be difficult.
The real service might ask the user for login credentials and attempt to reach an authentication server.
These behaviors can be hard to intercept. Be aware that using test doubles makes the test behave differently from production so use them sparingly.
### Get injected services
-The tests need access to the `UserService` injected into the `WelcomeComponent`.
+The tests need access to the `UserAuthentication` injected into the `Welcome` component.
Angular has a hierarchical injection system.
There can be injectors at multiple levels, from the root injector created by the `TestBed` down through the component tree.
@@ -158,7 +184,10 @@ The safest way to get the injected service, the way that **_always works_**,
is to **get it from the injector of the _component-under-test_**.
The component injector is a property of the fixture's `DebugElement`.
-;
+let comp: Welcome;
+let userAuth: UserAuthentication; // the TestBed injected service
+let el: HTMLElement; // the DOM element with the welcome message
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Welcome);
+ comp = fixture.componentInstance;
+
+ // UserAuthentication from the root injector
+ userAuth = TestBed.inject(UserAuthentication);
+
+ // get the "welcome" element by CSS selector (e.g., by class name)
+ el = fixture.nativeElement.querySelector('.welcome');
+});
+```
And here are some tests:
-
+ {{ quote | async }}
+
+
+@if (errorMessage()) {
+ {{ errorMessage() }}
+}
+```
HELPFUL: The value of the component's `quote` property passes through an `AsyncPipe`.
That means the property returns either a `Promise` or an `Observable`.
-In this example, the `TwainComponent.getQuote()` method tells you that the `quote` property returns an `Observable`.
+In this example, the `TwainQuotes.getQuote()` method tells you that the `quote` property returns an `Observable`.
-
-
-fakeAsync(() => { /_test body_/ })
-
-
-
-The `fakeAsync()` function enables a linear coding style by running the test body in a special `fakeAsync test zone`.
-The test body appears to be synchronous.
-There is no nested syntax \(like a `Promise.then()`\) to disrupt the flow of control.
-
-HELPFUL: Limitation: The `fakeAsync()` function won't work if the test body makes an `XMLHttpRequest` \(XHR\) call.
-XHR calls within a test are rare, but if you need to call XHR, use `waitForAsync()`.
-
-IMPORTANT: Be aware that asynchronous tasks that happen inside the `fakeAsync` zone need to be manually executed with `flush` or `tick`. If you attempt to
-wait for them to complete (i.e. using `fixture.whenStable`) without using the
-`fakeAsync` test helpers to advance time, your test will likely fail. See below for more information.
-
-### The `tick()` function
-
-You do have to call [tick()](api/core/testing/tick) to advance the virtual clock.
-
-Calling [tick()](api/core/testing/tick) simulates the passage of time until all pending asynchronous activities finish.
-In this case, it waits for the observable's `setTimeout()`.
-The [tick()](api/core/testing/tick) function accepts `millis` and `tickOptions` as parameters. The `millis` parameter specifies how much the virtual clock advances and defaults to `0` if not provided.
-For example, if you have a `setTimeout(fn, 100)` in a `fakeAsync()` test, you need to use `tick(100)` to trigger the fn callback.
-The optional `tickOptions` parameter has a property named `processNewMacroTasksSynchronously`. The `processNewMacroTasksSynchronously` property represents whether to invoke new generated macro tasks when ticking and defaults to `true`.
+In the case your async service relies on the `HttpClient` to load remote data, it is recommended to return mock responses at the HTTP level with the `HttpTestingController`.
-
-
+The stub is designed in such a way that any component or service that injects it will receive the stubbed implementation.
+It means that any call to `getQuote` receives an observable with a test quote.
-If you want to support such a case, you need to define the macro task you want to support in `beforeEach()`.
-For example:
-
-
should not have a backgroundColor', () => {
+ // the h2 without the Highlight directive
+ const bareH2 = fixture.debugElement.query(By.css('h2:not([highlight])'));
+
+ expect(bareH2.styles.backgroundColor).toBeUndefined();
+});
+```
いくつかのテクニックが注目に値します。
@@ -47,6 +150,7 @@ HELPFUL: ``のケースでは、`HighlightDirective`を、入力ボック
しかし、抽象化よりも簡単で明確な場合は、`nativeElement`を利用してください。
- Angularは、適用された要素のインジェクターにディレクティブを追加します。
- デフォルトの色に対するテストでは、2番目の``のインジェクターを使用して、その`HighlightDirective`インスタンスとその`defaultColor`を取得します。
+ デフォルトの色に対するテストでは、2番目の``のインジェクターを使用して、その`Highlight`インスタンスとその`defaultColor`を取得します。
- `DebugElement.properties`は、ディレクティブによって設定された人工的なカスタムプロパティにアクセスできます。
+
diff --git a/adev-ja/src/content/guide/testing/components-basics.en.md b/adev-ja/src/content/guide/testing/components-basics.en.md
index 4341bdd006..82dce45e08 100644
--- a/adev-ja/src/content/guide/testing/components-basics.en.md
+++ b/adev-ja/src/content/guide/testing/components-basics.en.md
@@ -17,9 +17,9 @@ Classes alone cannot tell you if the component is going to render properly, resp
- Is `Lightswitch.clicked()` bound to anything such that the user can invoke it?
- Is the `Lightswitch.message` displayed?
-- Can the user actually select the hero displayed by `DashboardHeroComponent`?
+- Can the user actually select the hero displayed by the `DashboardHero` component?
- Is the hero name displayed as expected \(such as uppercase\)?
-- Is the welcome message displayed by the template of `WelcomeComponent`?
+- Is the welcome message displayed by the template of the `Welcome` component?
These might not be troubling questions for the preceding simple components illustrated.
But many components have complex interactions with the DOM elements described in their templates, causing HTML to appear and disappear as the component state changes.
@@ -32,19 +32,37 @@ To write these kinds of test, you'll use additional features of the `TestBed` as
The CLI creates an initial test file for you by default when you ask it to generate a new component.
-For example, the following CLI command generates a `BannerComponent` in the `app/banner` folder \(with inline template and styles\):
+For example, the following CLI command generates a `Banner` component in the `app/banner` folder \(with inline template and styles\):
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-It also generates an initial test file for the component, `banner-external.component.spec.ts`, that looks like this:
+It also generates an initial test file for the component, `banner.spec.ts`, that looks like this:
-;
-Refer to the [waitForAsync](guide/testing/components-scenarios#waitForAsync) section for more details.
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### Reduce the setup
@@ -55,25 +73,30 @@ The rest of the file is boilerplate setup code anticipating more advanced tests
You'll learn about these advanced test features in the following sections.
For now, you can radically reduce this test file to a more manageable size:
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ The value of `ComponentFixture.nativeElement` has the `any` type.
Later you'll encounter the `DebugElement.nativeElement` and it too has the `any` type.
Angular can't know at compile time what kind of HTML element the `nativeElement` is or if it even is an HTML element.
-The application might be running on a _non-browser platform_, such as the server or a [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API), where the element might have a diminished API or not exist at all.
+The application might be running on a _non-browser platform_, such as the server or a node environment, where the element might have a diminished API or not exist at all.
The tests in this guide are designed to run in a browser so a `nativeElement` value will always be an `HTMLElement` or one of its derived classes.
@@ -115,17 +178,28 @@ Knowing that it is an `HTMLElement` of some sort, use the standard HTML `querySe
Here's another test that calls `HTMLElement.querySelector` to get the paragraph element and look for the banner text:
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
The Angular _fixture_ provides the component's element directly through the `fixture.nativeElement`.
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
The `DebugElement` has other methods and properties that are useful in tests, as you'll see elsewhere in this guide.
You import the `DebugElement` symbol from the Angular core library.
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
Some noteworthy observations:
diff --git a/adev-ja/src/content/guide/testing/components-basics.md b/adev-ja/src/content/guide/testing/components-basics.md
index 833d620f05..550c14cf83 100644
--- a/adev-ja/src/content/guide/testing/components-basics.md
+++ b/adev-ja/src/content/guide/testing/components-basics.md
@@ -17,9 +17,9 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
- `Lightswitch.clicked()` はユーザーが呼び出せるように何かとバインドされていますか？
- `Lightswitch.message` は表示されますか？
-- ユーザーは `DashboardHeroComponent` によって表示されるヒーローを実際に選択できますか？
+- ユーザーは `DashboardHero` コンポーネントによって表示されるヒーローを実際に選択できますか？
- ヒーローの名前は期待通り（たとえば、大文字）に表示されますか？
-- `WelcomeComponent` のテンプレートによってウェルカムメッセージは表示されますか？
+- `Welcome` コンポーネントのテンプレートによってウェルカムメッセージは表示されますか？
これらの質問は、説明した前の簡単なコンポーネントにとっては問題ないかもしれません。
しかし、多くのコンポーネントは、そのテンプレートで記述されているDOM要素との複雑な対話を持ち、コンポーネントの状態が変わるとHTMLが表示および非表示になります。
@@ -32,19 +32,37 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
CLIは、新しいコンポーネントの生成を要求するときに、デフォルトで初期テストファイルを自動的に生成します。
-たとえば、次のCLIコマンドは `app/banner` フォルダーに `BannerComponent` を生成します（インラインテンプレートとスタイル付き）。
+たとえば、次のCLIコマンドは `app/banner` フォルダーに `Banner` コンポーネントを生成します（インラインテンプレートとスタイル付き）。
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-また、コンポーネントの初期テストファイル `banner-external.component.spec.ts` も生成し、次のようになります。
+また、コンポーネントの初期テストファイル `banner.spec.ts` も生成し、次のようになります。
-;
-詳細については、[waitForAsync](guide/testing/components-scenarios#waitForAsync) セクションを参照してください。
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### セットアップの削減
@@ -55,25 +73,30 @@ HELPFUL: `compileComponents` は非同期であるため、`@angular/core/testin
これらの高度なテスト機能については、次のセクションで説明します。
今のところ、このテストファイルをより管理しやすいサイズに大幅に縮小できます。
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ fixtureを介してコンポーネントインスタンスにアクセスし、J
後で `DebugElement.nativeElement` に遭遇しますが、これも `any` 型です。
Angularは、コンパイル時に `nativeElement` がどのようなHTML要素であるか、あるいはHTML要素であるかどうかすらを知ることができません。
-アプリケーションは、サーバーや [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API) などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
+アプリケーションは、サーバーやNode環境などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
このガイドのテストはブラウザで実行されるように設計されているため、`nativeElement` の値は常に `HTMLElement` またはその派生クラスのいずれかになります。
@@ -115,17 +178,28 @@ Angularは、コンパイル時に `nativeElement` がどのようなHTML要素
次に、`HTMLElement.querySelector` を呼び出して段落要素を取得し、バナーテキストを探すテストを示します。
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
Angularの _fixture_ は、`fixture.nativeElement` を介してコンポーネントの要素を直接提供します。
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
`DebugElement` には、このガイドの他の場所で説明されているように、テストで役立つ他のメソッドとプロパティがあります。
Angularコアライブラリから `DebugElement` シンボルをインポートします。
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
注目すべき観察結果をいくつか紹介します。
diff --git a/adev-ja/src/content/guide/testing/components-scenarios.en.md b/adev-ja/src/content/guide/testing/components-scenarios.en.md
index 8cc4023f01..a2699bd4b3 100644
--- a/adev-ja/src/content/guide/testing/components-scenarios.en.md
+++ b/adev-ja/src/content/guide/testing/components-scenarios.en.md
@@ -4,11 +4,22 @@ This guide explores common component testing use cases.
## Component binding
-In the example application, the `BannerComponent` presents static title text in the HTML template.
+In the example application, the `Banner` component presents static title text in the HTML template.
-After a few changes, the `BannerComponent` presents a dynamic title by binding to the component's `title` property like this.
+After a few changes, the `Banner` component presents a dynamic title by binding to the component's `title` property like this.
-
{{ title() }}
',
+ styles: ['h1 { color: green; font-size: 350%}'],
+})
+export class Banner {
+ title = signal('Test Tour of Heroes');
+}
+```
As minimal as this is, you decide to add a test to confirm that component actually displays the right content where you think it should.
@@ -18,75 +29,86 @@ You'll write a sequence of tests that inspect the value of the `` element th
You update the `beforeEach` to find that element with a standard HTML `querySelector` and assign it to the `h1` variable.
-;
+let h1: HTMLElement;
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance; // Banner test instance
+ h1 = fixture.nativeElement.querySelector('h1');
+});
+```
### `createComponent()` does not bind data
For your first test you'd like to see that the screen displays the default `title`.
Your instinct is to write a test that immediately inspects the `` like this:
-
-
+```shell {hideCopy}
expected '' to contain 'Test Tour of Heroes'.
-
-
+```
Binding happens when Angular performs **change detection**.
In production, change detection kicks in automatically when Angular creates a component or the user enters a keystroke, for example.
-The `TestBed.createComponent` does not trigger change detection by default; a fact confirmed in the revised test:
+The `TestBed.createComponent` does not trigger change detection synchronously; a fact confirmed in the revised test:
-` have the expected title.
-{{ welcome() }}
',
+})
+export class Welcome {
+ private userAuth = inject(UserAuthentication);
+ welcome = signal(
+ this.userAuth.isLoggedIn() ? `Welcome, ${this.userAuth.user().name}` : 'Please log in.',
+ );
+}
+```
-The `WelcomeComponent` has decision logic that interacts with the service, logic that makes this component worth testing.
+The `Welcome` component has decision logic that interacts with the service, logic that makes this component worth testing.
### Provide service test doubles
A _component-under-test_ doesn't have to be provided with real services.
-Injecting the real `UserService` could be difficult.
+Injecting the real `UserAuthentication` could be difficult.
The real service might ask the user for login credentials and attempt to reach an authentication server.
These behaviors can be hard to intercept. Be aware that using test doubles makes the test behave differently from production so use them sparingly.
### Get injected services
-The tests need access to the `UserService` injected into the `WelcomeComponent`.
+The tests need access to the `UserAuthentication` injected into the `Welcome` component.
Angular has a hierarchical injection system.
There can be injectors at multiple levels, from the root injector created by the `TestBed` down through the component tree.
@@ -158,7 +184,10 @@ The safest way to get the injected service, the way that **_always works_**,
is to **get it from the injector of the _component-under-test_**.
The component injector is a property of the fixture's `DebugElement`.
-;
+let comp: Welcome;
+let userAuth: UserAuthentication; // the TestBed injected service
+let el: HTMLElement; // the DOM element with the welcome message
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Welcome);
+ comp = fixture.componentInstance;
+
+ // UserAuthentication from the root injector
+ userAuth = TestBed.inject(UserAuthentication);
+
+ // get the "welcome" element by CSS selector (e.g., by class name)
+ el = fixture.nativeElement.querySelector('.welcome');
+});
+```
And here are some tests:
-
+ {{ quote | async }}
+
+
+@if (errorMessage()) {
+ {{ errorMessage() }}
+}
+```
HELPFUL: The value of the component's `quote` property passes through an `AsyncPipe`.
That means the property returns either a `Promise` or an `Observable`.
-In this example, the `TwainComponent.getQuote()` method tells you that the `quote` property returns an `Observable`.
+In this example, the `TwainQuotes.getQuote()` method tells you that the `quote` property returns an `Observable`.
-
-
-fakeAsync(() => { /_test body_/ })
-
-
-
-The `fakeAsync()` function enables a linear coding style by running the test body in a special `fakeAsync test zone`.
-The test body appears to be synchronous.
-There is no nested syntax \(like a `Promise.then()`\) to disrupt the flow of control.
-
-HELPFUL: Limitation: The `fakeAsync()` function won't work if the test body makes an `XMLHttpRequest` \(XHR\) call.
-XHR calls within a test are rare, but if you need to call XHR, use `waitForAsync()`.
-
-IMPORTANT: Be aware that asynchronous tasks that happen inside the `fakeAsync` zone need to be manually executed with `flush` or `tick`. If you attempt to
-wait for them to complete (i.e. using `fixture.whenStable`) without using the
-`fakeAsync` test helpers to advance time, your test will likely fail. See below for more information.
-
-### The `tick()` function
-
-You do have to call [tick()](api/core/testing/tick) to advance the virtual clock.
-
-Calling [tick()](api/core/testing/tick) simulates the passage of time until all pending asynchronous activities finish.
-In this case, it waits for the observable's `setTimeout()`.
-The [tick()](api/core/testing/tick) function accepts `millis` and `tickOptions` as parameters. The `millis` parameter specifies how much the virtual clock advances and defaults to `0` if not provided.
-For example, if you have a `setTimeout(fn, 100)` in a `fakeAsync()` test, you need to use `tick(100)` to trigger the fn callback.
-The optional `tickOptions` parameter has a property named `processNewMacroTasksSynchronously`. The `processNewMacroTasksSynchronously` property represents whether to invoke new generated macro tasks when ticking and defaults to `true`.
+In the case your async service relies on the `HttpClient` to load remote data, it is recommended to return mock responses at the HTTP level with the `HttpTestingController`.
-
-
+The stub is designed in such a way that any component or service that injects it will receive the stubbed implementation.
+It means that any call to `getQuote` receives an observable with a test quote.
-If you want to support such a case, you need to define the macro task you want to support in `beforeEach()`.
-For example:
-
-
`のインジェクターを使用して、その`Highlight`インスタンスとその`defaultColor`を取得します。
- `DebugElement.properties`は、ディレクティブによって設定された人工的なカスタムプロパティにアクセスできます。
+
diff --git a/adev-ja/src/content/guide/testing/components-basics.en.md b/adev-ja/src/content/guide/testing/components-basics.en.md
index 4341bdd006..82dce45e08 100644
--- a/adev-ja/src/content/guide/testing/components-basics.en.md
+++ b/adev-ja/src/content/guide/testing/components-basics.en.md
@@ -17,9 +17,9 @@ Classes alone cannot tell you if the component is going to render properly, resp
- Is `Lightswitch.clicked()` bound to anything such that the user can invoke it?
- Is the `Lightswitch.message` displayed?
-- Can the user actually select the hero displayed by `DashboardHeroComponent`?
+- Can the user actually select the hero displayed by the `DashboardHero` component?
- Is the hero name displayed as expected \(such as uppercase\)?
-- Is the welcome message displayed by the template of `WelcomeComponent`?
+- Is the welcome message displayed by the template of the `Welcome` component?
These might not be troubling questions for the preceding simple components illustrated.
But many components have complex interactions with the DOM elements described in their templates, causing HTML to appear and disappear as the component state changes.
@@ -32,19 +32,37 @@ To write these kinds of test, you'll use additional features of the `TestBed` as
The CLI creates an initial test file for you by default when you ask it to generate a new component.
-For example, the following CLI command generates a `BannerComponent` in the `app/banner` folder \(with inline template and styles\):
+For example, the following CLI command generates a `Banner` component in the `app/banner` folder \(with inline template and styles\):
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-It also generates an initial test file for the component, `banner-external.component.spec.ts`, that looks like this:
+It also generates an initial test file for the component, `banner.spec.ts`, that looks like this:
-;
-Refer to the [waitForAsync](guide/testing/components-scenarios#waitForAsync) section for more details.
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### Reduce the setup
@@ -55,25 +73,30 @@ The rest of the file is boilerplate setup code anticipating more advanced tests
You'll learn about these advanced test features in the following sections.
For now, you can radically reduce this test file to a more manageable size:
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ The value of `ComponentFixture.nativeElement` has the `any` type.
Later you'll encounter the `DebugElement.nativeElement` and it too has the `any` type.
Angular can't know at compile time what kind of HTML element the `nativeElement` is or if it even is an HTML element.
-The application might be running on a _non-browser platform_, such as the server or a [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API), where the element might have a diminished API or not exist at all.
+The application might be running on a _non-browser platform_, such as the server or a node environment, where the element might have a diminished API or not exist at all.
The tests in this guide are designed to run in a browser so a `nativeElement` value will always be an `HTMLElement` or one of its derived classes.
@@ -115,17 +178,28 @@ Knowing that it is an `HTMLElement` of some sort, use the standard HTML `querySe
Here's another test that calls `HTMLElement.querySelector` to get the paragraph element and look for the banner text:
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
The Angular _fixture_ provides the component's element directly through the `fixture.nativeElement`.
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
The `DebugElement` has other methods and properties that are useful in tests, as you'll see elsewhere in this guide.
You import the `DebugElement` symbol from the Angular core library.
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
Some noteworthy observations:
diff --git a/adev-ja/src/content/guide/testing/components-basics.md b/adev-ja/src/content/guide/testing/components-basics.md
index 833d620f05..550c14cf83 100644
--- a/adev-ja/src/content/guide/testing/components-basics.md
+++ b/adev-ja/src/content/guide/testing/components-basics.md
@@ -17,9 +17,9 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
- `Lightswitch.clicked()` はユーザーが呼び出せるように何かとバインドされていますか？
- `Lightswitch.message` は表示されますか？
-- ユーザーは `DashboardHeroComponent` によって表示されるヒーローを実際に選択できますか？
+- ユーザーは `DashboardHero` コンポーネントによって表示されるヒーローを実際に選択できますか？
- ヒーローの名前は期待通り（たとえば、大文字）に表示されますか？
-- `WelcomeComponent` のテンプレートによってウェルカムメッセージは表示されますか？
+- `Welcome` コンポーネントのテンプレートによってウェルカムメッセージは表示されますか？
これらの質問は、説明した前の簡単なコンポーネントにとっては問題ないかもしれません。
しかし、多くのコンポーネントは、そのテンプレートで記述されているDOM要素との複雑な対話を持ち、コンポーネントの状態が変わるとHTMLが表示および非表示になります。
@@ -32,19 +32,37 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
CLIは、新しいコンポーネントの生成を要求するときに、デフォルトで初期テストファイルを自動的に生成します。
-たとえば、次のCLIコマンドは `app/banner` フォルダーに `BannerComponent` を生成します（インラインテンプレートとスタイル付き）。
+たとえば、次のCLIコマンドは `app/banner` フォルダーに `Banner` コンポーネントを生成します（インラインテンプレートとスタイル付き）。
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-また、コンポーネントの初期テストファイル `banner-external.component.spec.ts` も生成し、次のようになります。
+また、コンポーネントの初期テストファイル `banner.spec.ts` も生成し、次のようになります。
-;
-詳細については、[waitForAsync](guide/testing/components-scenarios#waitForAsync) セクションを参照してください。
+ beforeEach(async () => {
+ await TestBed.configureTestingModule({
+ imports: [Banner],
+ }).compileComponents();
+
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+ await fixture.whenStable();
+ });
+
+ it('should create', () => {
+ expect(component).toBeTruthy();
+ });
+});
+```
### セットアップの削減
@@ -55,25 +73,30 @@ HELPFUL: `compileComponents` は非同期であるため、`@angular/core/testin
これらの高度なテスト機能については、次のセクションで説明します。
今のところ、このテストファイルをより管理しやすいサイズに大幅に縮小できます。
-;
+
+ beforeEach(async () => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance;
+
+ await fixture.whenStable(); // necessary to wait for the initial rendering
+ });
+
+ it('should create', () => {
+ expect(component).toBeDefined();
+ });
+});
+```
- {
+ TestBed.configureTestingModule({providers});
+ return TestBed.createComponent(Banner);
+}
+```
### `nativeElement`
@@ -107,7 +170,7 @@ fixtureを介してコンポーネントインスタンスにアクセスし、J
後で `DebugElement.nativeElement` に遭遇しますが、これも `any` 型です。
Angularは、コンパイル時に `nativeElement` がどのようなHTML要素であるか、あるいはHTML要素であるかどうかすらを知ることができません。
-アプリケーションは、サーバーや [Web Worker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API) などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
+アプリケーションは、サーバーやNode環境などの _非ブラウザープラットフォーム_ で実行されている可能性があり、その場合、要素のAPIが制限されているか、存在しない可能性があります。
このガイドのテストはブラウザで実行されるように設計されているため、`nativeElement` の値は常に `HTMLElement` またはその派生クラスのいずれかになります。
@@ -115,17 +178,28 @@ Angularは、コンパイル時に `nativeElement` がどのようなHTML要素
次に、`HTMLElement.querySelector` を呼び出して段落要素を取得し、バナーテキストを探すテストを示します。
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
Angularの _fixture_ は、`fixture.nativeElement` を介してコンポーネントの要素を直接提供します。
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
`DebugElement` には、このガイドの他の場所で説明されているように、テストで役立つ他のメソッドとプロパティがあります。
Angularコアライブラリから `DebugElement` シンボルをインポートします。
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
注目すべき観察結果をいくつか紹介します。
diff --git a/adev-ja/src/content/guide/testing/components-scenarios.en.md b/adev-ja/src/content/guide/testing/components-scenarios.en.md
index 8cc4023f01..a2699bd4b3 100644
--- a/adev-ja/src/content/guide/testing/components-scenarios.en.md
+++ b/adev-ja/src/content/guide/testing/components-scenarios.en.md
@@ -4,11 +4,22 @@ This guide explores common component testing use cases.
## Component binding
-In the example application, the `BannerComponent` presents static title text in the HTML template.
+In the example application, the `Banner` component presents static title text in the HTML template.
-After a few changes, the `BannerComponent` presents a dynamic title by binding to the component's `title` property like this.
+After a few changes, the `Banner` component presents a dynamic title by binding to the component's `title` property like this.
-
{{ title() }}
',
+ styles: ['h1 { color: green; font-size: 350%}'],
+})
+export class Banner {
+ title = signal('Test Tour of Heroes');
+}
+```
As minimal as this is, you decide to add a test to confirm that component actually displays the right content where you think it should.
@@ -18,75 +29,86 @@ You'll write a sequence of tests that inspect the value of the `` element th
You update the `beforeEach` to find that element with a standard HTML `querySelector` and assign it to the `h1` variable.
-;
+let h1: HTMLElement;
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Banner);
+ component = fixture.componentInstance; // Banner test instance
+ h1 = fixture.nativeElement.querySelector('h1');
+});
+```
### `createComponent()` does not bind data
For your first test you'd like to see that the screen displays the default `title`.
Your instinct is to write a test that immediately inspects the `` like this:
-
-
+```shell {hideCopy}
expected '' to contain 'Test Tour of Heroes'.
-
-
+```
Binding happens when Angular performs **change detection**.
In production, change detection kicks in automatically when Angular creates a component or the user enters a keystroke, for example.
-The `TestBed.createComponent` does not trigger change detection by default; a fact confirmed in the revised test:
+The `TestBed.createComponent` does not trigger change detection synchronously; a fact confirmed in the revised test:
-` have the expected title.
-{{ welcome() }}
',
+})
+export class Welcome {
+ private userAuth = inject(UserAuthentication);
+ welcome = signal(
+ this.userAuth.isLoggedIn() ? `Welcome, ${this.userAuth.user().name}` : 'Please log in.',
+ );
+}
+```
-The `WelcomeComponent` has decision logic that interacts with the service, logic that makes this component worth testing.
+The `Welcome` component has decision logic that interacts with the service, logic that makes this component worth testing.
### Provide service test doubles
A _component-under-test_ doesn't have to be provided with real services.
-Injecting the real `UserService` could be difficult.
+Injecting the real `UserAuthentication` could be difficult.
The real service might ask the user for login credentials and attempt to reach an authentication server.
These behaviors can be hard to intercept. Be aware that using test doubles makes the test behave differently from production so use them sparingly.
### Get injected services
-The tests need access to the `UserService` injected into the `WelcomeComponent`.
+The tests need access to the `UserAuthentication` injected into the `Welcome` component.
Angular has a hierarchical injection system.
There can be injectors at multiple levels, from the root injector created by the `TestBed` down through the component tree.
@@ -158,7 +184,10 @@ The safest way to get the injected service, the way that **_always works_**,
is to **get it from the injector of the _component-under-test_**.
The component injector is a property of the fixture's `DebugElement`.
-;
+let comp: Welcome;
+let userAuth: UserAuthentication; // the TestBed injected service
+let el: HTMLElement; // the DOM element with the welcome message
+
+beforeEach(() => {
+ fixture = TestBed.createComponent(Welcome);
+ comp = fixture.componentInstance;
+
+ // UserAuthentication from the root injector
+ userAuth = TestBed.inject(UserAuthentication);
+
+ // get the "welcome" element by CSS selector (e.g., by class name)
+ el = fixture.nativeElement.querySelector('.welcome');
+});
+```
And here are some tests:
-
+ {{ quote | async }}
+
+
+@if (errorMessage()) {
+ {{ errorMessage() }}
+}
+```
HELPFUL: The value of the component's `quote` property passes through an `AsyncPipe`.
That means the property returns either a `Promise` or an `Observable`.
-In this example, the `TwainComponent.getQuote()` method tells you that the `quote` property returns an `Observable`.
+In this example, the `TwainQuotes.getQuote()` method tells you that the `quote` property returns an `Observable`.
-
-
-fakeAsync(() => { /_test body_/ })
-
-
-
-The `fakeAsync()` function enables a linear coding style by running the test body in a special `fakeAsync test zone`.
-The test body appears to be synchronous.
-There is no nested syntax \(like a `Promise.then()`\) to disrupt the flow of control.
-
-HELPFUL: Limitation: The `fakeAsync()` function won't work if the test body makes an `XMLHttpRequest` \(XHR\) call.
-XHR calls within a test are rare, but if you need to call XHR, use `waitForAsync()`.
-
-IMPORTANT: Be aware that asynchronous tasks that happen inside the `fakeAsync` zone need to be manually executed with `flush` or `tick`. If you attempt to
-wait for them to complete (i.e. using `fixture.whenStable`) without using the
-`fakeAsync` test helpers to advance time, your test will likely fail. See below for more information.
-
-### The `tick()` function
-
-You do have to call [tick()](api/core/testing/tick) to advance the virtual clock.
-
-Calling [tick()](api/core/testing/tick) simulates the passage of time until all pending asynchronous activities finish.
-In this case, it waits for the observable's `setTimeout()`.
-The [tick()](api/core/testing/tick) function accepts `millis` and `tickOptions` as parameters. The `millis` parameter specifies how much the virtual clock advances and defaults to `0` if not provided.
-For example, if you have a `setTimeout(fn, 100)` in a `fakeAsync()` test, you need to use `tick(100)` to trigger the fn callback.
-The optional `tickOptions` parameter has a property named `processNewMacroTasksSynchronously`. The `processNewMacroTasksSynchronously` property represents whether to invoke new generated macro tasks when ticking and defaults to `true`.
+In the case your async service relies on the `HttpClient` to load remote data, it is recommended to return mock responses at the HTTP level with the `HttpTestingController`.
-
-
+The stub is designed in such a way that any component or service that injects it will receive the stubbed implementation.
+It means that any call to `getQuote` receives an observable with a test quote.
-If you want to support such a case, you need to define the macro task you want to support in `beforeEach()`.
-For example:
-
-
with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
The Angular _fixture_ provides the component's element directly through the `fixture.nativeElement`.
-
with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
The `DebugElement` has other methods and properties that are useful in tests, as you'll see elsewhere in this guide.
You import the `DebugElement` symbol from the Angular core library.
-
with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
Some noteworthy observations:
diff --git a/adev-ja/src/content/guide/testing/components-basics.md b/adev-ja/src/content/guide/testing/components-basics.md
index 833d620f05..550c14cf83 100644
--- a/adev-ja/src/content/guide/testing/components-basics.md
+++ b/adev-ja/src/content/guide/testing/components-basics.md
@@ -17,9 +17,9 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
- `Lightswitch.clicked()` はユーザーが呼び出せるように何かとバインドされていますか？
- `Lightswitch.message` は表示されますか？
-- ユーザーは `DashboardHeroComponent` によって表示されるヒーローを実際に選択できますか？
+- ユーザーは `DashboardHero` コンポーネントによって表示されるヒーローを実際に選択できますか？
- ヒーローの名前は期待通り（たとえば、大文字）に表示されますか？
-- `WelcomeComponent` のテンプレートによってウェルカムメッセージは表示されますか？
+- `Welcome` コンポーネントのテンプレートによってウェルカムメッセージは表示されますか？
これらの質問は、説明した前の簡単なコンポーネントにとっては問題ないかもしれません。
しかし、多くのコンポーネントは、そのテンプレートで記述されているDOM要素との複雑な対話を持ち、コンポーネントの状態が変わるとHTMLが表示および非表示になります。
@@ -32,19 +32,37 @@ Angularの `TestBed` は、次のセクションで説明するように、こ
CLIは、新しいコンポーネントの生成を要求するときに、デフォルトで初期テストファイルを自動的に生成します。
-たとえば、次のCLIコマンドは `app/banner` フォルダーに `BannerComponent` を生成します（インラインテンプレートとスタイル付き）。
+たとえば、次のCLIコマンドは `app/banner` フォルダーに `Banner` コンポーネントを生成します（インラインテンプレートとスタイル付き）。
```shell
-ng generate component banner --inline-template --inline-style --module app
+ng generate component banner --inline-template --inline-style
```
-また、コンポーネントの初期テストファイル `banner-external.component.spec.ts` も生成し、次のようになります。
+また、コンポーネントの初期テストファイル `banner.spec.ts` も生成し、次のようになります。
- with "banner works!"', () => {
+ const bannerElement: HTMLElement = fixture.nativeElement;
+ const p = bannerElement.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
### `DebugElement`
Angularの _fixture_ は、`fixture.nativeElement` を介してコンポーネントの要素を直接提供します。
- with fixture.debugElement.nativeElement', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const bannerEl: HTMLElement = bannerDe.nativeElement;
+ const p = bannerEl.querySelector('p')!;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
`DebugElement` には、このガイドの他の場所で説明されているように、テストで役立つ他のメソッドとプロパティがあります。
Angularコアライブラリから `DebugElement` シンボルをインポートします。
- with fixture.debugElement.query(By.css)', () => {
+ const bannerDe: DebugElement = fixture.debugElement;
+ const paragraphDe = bannerDe.query(By.css('p'));
+ const p: HTMLElement = paragraphDe.nativeElement;
+ expect(p.textContent).toEqual('banner works!');
+});
+```
注目すべき観察結果をいくつか紹介します。
diff --git a/adev-ja/src/content/guide/testing/components-scenarios.en.md b/adev-ja/src/content/guide/testing/components-scenarios.en.md
index 8cc4023f01..a2699bd4b3 100644
--- a/adev-ja/src/content/guide/testing/components-scenarios.en.md
+++ b/adev-ja/src/content/guide/testing/components-scenarios.en.md
@@ -4,11 +4,22 @@ This guide explores common component testing use cases.
## Component binding
-In the example application, the `BannerComponent` presents static title text in the HTML template.
+In the example application, the `Banner` component presents static title text in the HTML template.
-After a few changes, the `BannerComponent` presents a dynamic title by binding to the component's `title` property like this.
+After a few changes, the `Banner` component presents a dynamic title by binding to the component's `title` property like this.
-
+ {{ quote | async }}
+ {{ errorMessage() }}{{ title() }}
',
+ styles: ['h1 { color: green; font-size: 350%}'],
+})
+export class Banner {
+ title = signal('Test Tour of Heroes');
+}
+```
As minimal as this is, you decide to add a test to confirm that component actually displays the right content where you think it should.
@@ -18,75 +29,86 @@ You'll write a sequence of tests that inspect the value of the `` element th
You update the `beforeEach` to find that element with a standard HTML `querySelector` and assign it to the `h1` variable.
-
` like this:
-
` have the expected title.
-
{{ welcome() }}
',
+})
+export class Welcome {
+ private userAuth = inject(UserAuthentication);
+ welcome = signal(
+ this.userAuth.isLoggedIn() ? `Welcome, ${this.userAuth.user().name}` : 'Please log in.',
+ );
+}
+```
-The `WelcomeComponent` has decision logic that interacts with the service, logic that makes this component worth testing.
+The `Welcome` component has decision logic that interacts with the service, logic that makes this component worth testing.
### Provide service test doubles
A _component-under-test_ doesn't have to be provided with real services.
-Injecting the real `UserService` could be difficult.
+Injecting the real `UserAuthentication` could be difficult.
The real service might ask the user for login credentials and attempt to reach an authentication server.
These behaviors can be hard to intercept. Be aware that using test doubles makes the test behave differently from production so use them sparingly.
### Get injected services
-The tests need access to the `UserService` injected into the `WelcomeComponent`.
+The tests need access to the `UserAuthentication` injected into the `Welcome` component.
Angular has a hierarchical injection system.
There can be injectors at multiple levels, from the root injector created by the `TestBed` down through the component tree.
@@ -158,7 +184,10 @@ The safest way to get the injected service, the way that **_always works_**,
is to **get it from the injector of the _component-under-test_**.
The component injector is a property of the fixture's `DebugElement`.
-