2026.06.27 覚書 / 2026.06.27 memo's
自分が参考になったブログの紹介します。
Angular
- Angular 2以降のモダン Angular は、メジャーバージョンごとのサポート期間が約18か月と短く、定期的なアップデートが必須になる、という内容です。
- サポート期間は「約6か月のアクティブサポート」＋「約12か月の LTS」という構成で、半年ごとに新メジャーが出るため、半年ごとにどれかのバージョンが EOL になります。
- 記事では Angular 19 が 2026年5月18日に EOL、Angular 20 と Angular 21 がサポート対象として扱われています。
- 実務上は、Angular は「一度アップグレードして終わり」ではなく、6〜12か月ごとに
ng updateを実行する運用をロードマップに組み込むべき、という主張です。 - アップグレードはメジャーを飛ばさず、1バージョンずつ進めること、Angular Material / NgRx / サードパーティライブラリも合わせて追従することが推奨されています。
- Angular v22 で追加された
injectAsyncを使い、サービス単位でビジネスロジックを遅延読み込みする方法を解説した記事です。 - 通常の
inject()は依存先を静的参照するため、使う頻度が低いサービスでも初期バンドルに含まれます。injectAsync()は動的 import と組み合わせて、必要になったタイミングでサービスを読み込めるようにします。 - 例として、レポート出力機能のように「画面は表示するが、エクスポート処理はボタン押下時だけ使う」ケースで、
ReportExporterサービスを遅延読み込みする例が紹介されています。 - ただし利用対象は
@Injectable({ providedIn: 'root' })または@Service()のサービスに限られ、複雑な provider 定義には対応しない点が制約です。 - Angular の遅延読み込み手段として、ルート単位の
loadChildren/loadComponent、ビュー単位の@defer、サービス単位のinjectAsync、通常の ES Moduleimport(...)を使い分ける、という整理がされています。
NgRx
- 従来の NgRx は、Actions / Reducers / Effects / Selectors などの儀式が多く、小〜中規模の状態管理には重すぎることが多かった、という問題意識から始まる記事です。
- NgRx SignalStore は Redux 的な dispatch / reducer 構造を捨て、Angular Signals をベースに「state は signals」「変更は methods」というシンプルなモデルにしている点を評価しています。
withStateで状態、withComputedで派生状態、withMethodsで状態変更メソッドを定義する構成が紹介されています。patchStateを使って state を更新し、配列やオブジェクトは直接 mutate せず、新しい参照を作るべきだと強調しています。直接push()すると signal が変化を検知できず、computed が古い値のままになる可能性があります。- 非同期処理では
rxMethodを使い、switchMapによるリクエストキャンセルなど、RxJS が引き続き有効であることを説明しています。結論として「UI状態は Signals、非同期イベント列は RxJS」という住み分けです。 - store を
providedIn: 'root'にするか、コンポーネントのprovidersに置いて画面単位にスコープするかが重要で、画面固有の state を何でもグローバルにするのは避けるべき、という実務的な指摘があります。
- NgRx Signal Store の入門チュートリアル記事です。Angular Signals に慣れていて、従来の NgRx も知っている開発者向けに書かれています。
- NgRx Signal Store は従来の
@ngrx/storeを完全に置き換えるものではなく、Actions → Reducers → Selectors が過剰に感じる場面向けの軽量な選択肢として位置付けられています。 signalStore()、withState()、withComputed()、withMethods()を使い、商品一覧・ローディング状態・派生状態を管理する例が紹介されています。- コンポーネント側では通常のサービスのように store を
inject()し、テンプレートからstore.products()やstore.productsCount()のように signal として直接参照します。asyncpipe やsubscribe()は不要です。 - 初期例では
firstValueFromとasync/awaitで HTTP を扱っていますが、より NgRx Signal Store らしい実装としてrxMethodとtapResponseへの書き換えも紹介されています。 rxMethod版ではswitchMapによる前回リクエストのキャンセル、tapResponseによるエラー時にもストリームを終了させない処理がポイントです。
- Angular Signals の基礎から、
signal()、computed()、effect()、RxJS 連携、input()/model()/output()までをまとめた解説記事です。 signal()はリアクティブな値コンテナで、値の読み取りは関数呼び出し形式、更新はset()またはupdate()を使うと説明しています。computed()は他の signal から派生する読み取り専用 signal で、遅延評価・キャッシュ・依存 signal 変更時の再計算が行われます。- テンプレート内では
count()のように signal を呼び出すことで Angular が依存関係を追跡し、必要な箇所だけ再描画できる、という説明です。 - コンポーネントクラス内で signal をただ読むだけでは購読にはならないため、副作用を起こしたい場合は
effect()を使うべき、と整理されています。 effect()は logging、localStorage 書き込み、外部ライブラリ連携、DOM 操作など「Angular のリアクティブ状態から外部世界へ影響を出す」用途に使うべきで、派生状態にはcomputed()を使うべき、という切り分けです。effect()のonCleanupを使うことで、タイマー、fetch、イベントリスナーなどを再実行前やコンポーネント破棄時に掃除できる点も説明されています。- Signals と RxJS は競合ではなく役割が異なり、UI状態や派生状態は Signals、HTTP / WebSocket / イベント列 / debounce / switchMap などは RxJS が向いている、という整理です。
toSignal()とtoObservable()による相互変換も紹介されています。
