Signals 雑記 (2023-06-21)
- Signalがプリミティブであるということの意味
- プリミティブとそうでないものの違い=遍在性
- どこで使われていてもおかしくない原始的な構成要素
- Angular Signalsがリアクティビティプリミティブであるなら、Angular Signals はAngularアプリケーションのどこにどう登場してもおかしくない
- たとえドメイン層であっても
- 脱State, 脱Store
- State, Store というメンタルモデル
- JavaScriptでオブジェクトの状態の変化に対して反応的であるためには、なんらかの仕組みが必要
- Pull型でいえばポーリング、tick + dirty checking
- Push型でいえばイベントリスナー、Observerパターン
- あるオブジェクトについて、そのオブジェクトの変更を追跡するために外付けされるアダプターとして、Store というパターンが使われてきた
- Store パターンの本質はオブジェクトに対する変更(mutation)経路の制限
- 変更経路を絞ることで、変更されたときに確実に通知できる
- Store パターンを再利用可能な部品として実装しようとすると、あるひとまとまりのオブジェクトに対するポリモーフィックな設計になる
-
Store<T> - この
T がすなわち State - Store パターンが State という分節単位を要求する
- ところが、Signalsはオブジェクトそれ自体が変更を通知する、「物言うオブジェクト」
- 変更を追跡するために追加の仕組みを必要としない
- つまり、Storeが不要
- Storeが不要であるなら、同時に State という分節単位も不要
- State に組み入れられていたひとつひとつのオブジェクトが、それぞれ独立して状態として振る舞える
- そのような意味における脱State, 脱Store
- 実際には、細分化、to be fine-grained
- "状態管理"はもはや責務ではなくなった
- Signalsによって、Observerパターンがプリミティブとして状態オブジェクトそのものに組み込まれた
- もはや独立したメカニズムとして外部化できるものではなくなる
- Signals以後に残るのは、自律分散的に存在するそれぞれの状態オブジェクトが、互いにどのように関係するかというネットワークの構築か
