SPAでのレイヤードアーキテクチャの考察と不確実性へのマインドセット

結論

---

追記

歴史は繰り返されており、どの時代でも同じ傾向や原則がある

WhatとHowの分離

知らない技術を採用するのが恐いというハードルの高さはあるかもしれないが、試してみて向き合うしかない

ここから本題

フロントエンドの関心は UI とそれにまつわる必要な処理だが、それらは頻繁に変わる。フロントエンドでの短命のモデルに変更を加え続けるよりも、レイヤーやモデルの存在を気にせず E2E でべた書きした方が将来の保守性・実装速度が上という状況はあり得る。短命なモデルしかないフロントエンドに、レイヤードアーキテクチャはどの程度役に立つのだろうか。

領域全体を常にすぐに把握しやすい状態に保つことができれば追加実装しやすい。レイヤードアーキテクチャの欠点はボイラープレート的コードが必要になることと、E2E での把握がしにくくなることだ。フロントエンドではJSON色付け係という言葉があるようにサーバーから取得したデータをユーザーに見せる処理で完結する場合も多く、その中間のロジックもあまりないので技術的詳細を隠蔽してもあまりうれしくない。フォームをはじめユーザーに操作してもらうところも多いが、こちらも HTML の仕様と強く結びついているので隠蔽の旨味は少ないと思う。

レイヤを作ったとしてもどこかで、「これ本当に必要？」となりがち

そうであれば、むしろレイヤーを取っ払って、データ取得と表示を近くに書いてみたらどうだろうか。ボイラープレートが減って E2E での把握もしやすい、把握しやすくミニマムなコードができるのではないか。（ドメインモデルがあるような普通のサーバー的には失格かもしれないが）

以下のような思想とも似ている

今の実装（の一部分）を捨てて作り直すすることに躊躇しなくなると何がうれしいか。フロントエンドで（一部分の）実装を捨てるという事態は、負債解消や機能追加等の実装上の理由だけでなく、UI デザインの変更や検証で部分的に作り変える、という理由でも起きる。

むしろ、現実の使い捨て製品のように、捨てるコストが低い方が運用の柔軟さに勝り、実装や UI デザインの試行錯誤や改善が行いやすい。

たとえば、ちょっとした買い物でも、抗菌・消臭などの付加価値がある高級な消耗品を買うぐらいなら、1ヶ月スパンごとに百均で新品を買いなおすほうがもろもろコストがいいしキレイだし気分もいいみたいな

捨てる前提で作ると運用しやすい

hooksはUIを捨てるときの影響範囲を最小限にするための抽象化として捉える

参照記事系

フロントエンドではユーザーが期待する振る舞いが価値

UIを操作するシナリオが違えばドメインも違う

テストについて

まとめ

影響範囲閉じてるほうが嬉しい

既存の状態管理を理解するコスト > 0から設計し直して作り直すコスト

SPAをどうやって作るか、の時代は終わりつつある

今やるべきインプット

ライブラリのドキュメントを読み、思想を理解する

言語仕様を把握する

今やるべきアウトプット

自分が何をすることになったのか自分で理解して作る

常に自分がいなくなっても他人に説明できるものを書く

関連

レイヤを重ねて冗長化するのではなく、必要十分でミニマムな設計を目指す

レイヤ化する場合は目的を明確にする

レイヤーがペイするであろうn年後には基盤技術が総入れ替えで1から書き直したほうが早い

車輪の再発明もある

基本的にどのライブラリを使うとしても剥がすのは大変

薄く使えるに越したことはないが、利用するとき決めたなら中途半端に剥がしやすく使うよりも恩恵を受けられるように全振りするほうがメリットは大きい

どこが変わる可能性があるか、どうやって捨てるか、レイヤを配置することが本質的なのかは問い続ける

技術の変遷や経年劣化への対応

その代わりUIを構成するコアロジックを守る