2026.05.27 覚書 / 2026.05.27 memo's

2026.05.27 覚書 / 2026.05.27 memo's

自分が参考になったブログの紹介します。

Angular

dev.to

• Angular 21 対応の @stackline/angular-multiselect-dropdown というマルチセレクト Dropdown コンポーネント紹介記事です。
• 単なる Dropdown ではなく、業務画面・管理画面・フィルター・権限編集・レポート画面などで使うことを想定した実用寄りの UI コンポーネントとして説明されています。
• 主な機能は、単一選択・複数選択、検索、全選択・全解除、グループ化、カスタム item / badge テンプレート、Template-driven Forms / Reactive Forms 対応、lazy loading、CSS / SCSS テーマ対応などです。
• 移行しやすさが大きなテーマです。新しい selector は <angular-multiselect>、既存互換として <angular2-multiselect> も維持しており、既存テンプレートを一気に書き換えなくても段階的に移行できる、という主張です。
• Angular major version ごとに検証済み package line を持つ方針で、広い peer dependency range よりも「CI・本番・移行計画で予測可能な互換性」を重視しています。
• Live functional examples が強調されており、basic multi-select、検索、selection limit、grouped datasets、disabled state、empty data、long list、lazy loading、custom templates などをブラウザで確認できる構成です。
• 読む価値としては、「Angular 21 対応 UI ライブラリの紹介」だけでなく、「既存 Angular アプリで UI コンポーネントをどう安全に移行するか」の観点が参考になります。

dev.to

• 公式 Kubernetes Dashboard が 2026 年 1 月に archive された背景を踏まえ、元の Angular ベース UI を Angular 21 までアップグレードした、という事例記事です。
• 筆者は以前、Kubernetes Dashboard を React + MUI で再構築したものの、元の Dashboard の見た目や雰囲気から離れてしまい「しっくり来なかった」と説明しています。
• 最初は Angular 16 から 21 へ直接アップグレードしようとして失敗気味になり、UI は動いたものの問題が多く、いったん React + MUI 版へ切り替えた流れが書かれています。
• その後、Claude Desktop / Claude Web / Claude Code を使い、旧 stack の技術・機能分析、Angular migration path の調査、Angular 16 → 21 の段階的 upgrade を進めた、という AI 支援開発の実例でもあります。
• 最終的には、元の Web UI にかなり近い見た目で Angular 21 化できたとし、Tooltips や Status Pills など細かい差分も side-by-side 比較で修正したと述べています。
• 読む価値としては、「Angular major version を飛ばして上げると事故る」「段階的 migration と都度テストが重要」という、かなり実務臭い教訓が得られます。
• 特に、Angular 16 → 21 のような大きめの移行では、Nx / Angular workspace でも同じく「一段ずつ上げる」「各段階でテストする」方針の裏付けとして使えそうです。

NgRx

dev.to

• NgRx SignalStore を「何にでも使うべき万能ツール」として扱うことへの批判記事です。
• 筆者は SignalStore 自体を否定しているわけではなく、強力なツールだと認めたうえで、使いどころを誤ると技術的負債になる、という立場です。
• 例として、URL parameter の id を元に User details を取得する画面を取り上げています。単純に component input signal と resource を組み合わせれば済む処理を、SignalStore に通すと setId method、patchState、component 側の effect などが必要になり、ボイラープレートと認知負荷が増えると説明しています。
• 主な批判点は 3 つです。
  • component input を SignalStore に渡すのが複雑
  • server state / API state の管理に向いていない場面がある
  • dependency tracking / testability に弱点がある
• 特に server state については、SignalStore が client state を source of truth として扱うため、URL state や resource 由来の state と同期する必要が出て、API trigger や loading / error handling が手作業になりがちだと指摘しています。
• 一方で、SignalStore は「1 つの client state」を管理する用途には非常に向いている、という評価もしています。typed initial state、methods による state 更新、computed による derived state を 1 箇所にまとめられる点は長所とされています。
• 筆者の結論はかなり明確で、SignalStore は「one client state」を扱う用途に絞り、server state、URL state、複数 state の facade / orchestration には使いすぎない方がよい、というものです。
• 読む価値としては、NgRx SignalStore 導入時の設計判断にかなり刺さります。特に ComponentStore 的な局所 state 管理、Signals、Angular resource、server state 管理をどう分けるか考える材料になります。

RxJS

dev.to

• Angular Signals が普及した現在でも、Angular アプリで RxJS は必要なのか？というテーマの記事です。
• 結論は「必要。ただし、どこでも使うものではない」です。筆者は、これは好みの問題ではなく architecture / boundary の問題だと整理しています。
• RxJS は event stream、非同期 composition、時間ベースの処理に強く、HTTP request、WebSocket、複雑な async workflow、event orchestration などに向いていると説明されています。
• Signals は synchronous reactivity、local state tracking、明示的な依存関係に向いており、UI state、derived state、component-level reactivity に適しているとされています。
• 問題は RxJS と Signals のどちらを選ぶかではなく、境界を決めずに混ぜることだと述べています。境界が曖昧だと、state の重複、logic の分散、source of truth の不明確化が起きる、という指摘です。
• 記事内のシンプルなルールは「RxJS handles the outside world. Signals handle the UI world.」です。つまり、RxJS は integration layer、Signals は presentation layer として使い分けるという整理です。
• 読む価値としては、Angular + RxJS + Signals の設計方針をチームで共有する時に使いやすい記事です。