📘

第4回 フロントエンドアーキテクチャを学ぶ

2021/11/14に公開約1,700字

読んだ記事

ぼくのかんがえたさいきょうのVueあーきてくちゃ

内容の自分的解釈

フロントの責務
遷移と参照に二分される。

  • 遷移は基本時にrouterを使えば良い。
  • 参照は「一覧」と「詳細」に大体分かれる。
  • 一覧は共通化できそう
  • 詳細は共通化がなかなか難しい
  • 新規作成と削除は基本一覧画面で、大体リストから要素を消したり追加するので
  • 編集は基本的に詳細で、一覧でやってもメリットがないから

ここまでは概ね同意だと思った。
基本的にフロントエンドの要件としてはちょっと極論の気もするが、概ね間違っていないと思った。
共通化については若干違う意見で、ユーザーサイトか管理サイトかでかなり共通化については考え方が変わると思った。
(管理サイトは特にどの画面も共通的なレイアウトになると思っている。)
削除については一覧画面からではなく、詳細画面でも良いと思った。

見通しのいい構成を考える
ほとんどディレクトリ構成についてで、特徴的なものが切り出されていた。
「enums」
たびたび使うべきか戦争になるが、ここについては特に記載しない。
サーバーとの定数やりとりに使用するenumなどを記載する。
また、namespaceをオーバーライドするとメソッドを生やすことができる。
これについては初めて知ったが、結構良さそうだと思った。詳しくは下記リンクから。
TypeScriptのEnumに関数を追加して値を返却する
「mixins」
説明:SetupContextに依存する処理を記載する、composition apiの肝の部分。
VueファイルにおけるSetup内での処理系統についてまとめられたもの。
emitやrouter, storeなどを全てこのロジックで呼ぶ。
また、APIに関連した処理などもこちらでimport。
要するにVueファイルで処理の記載を極限まで少なくするためにロジックを取りまとめているファイルとしている。
「models」
説明:APIクライアントとエンティティに関するロジックをとりまとめる。
・BaseModel
→APIクライアント。extendして使うことが想定されており、REST APIリクエストの共通処理が記載されている。
・extend
→BaseModelをextendしている。そのためCRUD処理の記載は不要。
独自のAPIメソッドも追加できる拡張性もある(BaseModelはあくまでREST APIの範囲を超えないので)。
また、レスポンスはデシリアライズ(レスポンスデータの加工関数を定義したもの)を常に通るので、FE上での表示のためのプロパティ作りもできる、エンティティのプロパティに集中できる。
「modules」
説明:SetupContextに依存しないビジネスロジック。
特定ドメインについてのビジネスロジックが記載されている。
e.g. 複雑なAPIのリクエストボディ作成など。
柔軟性の低いmodelsに依存するものなので、依存関係の向き先を考えると優れていると思う。
全てのディレクトリ構成については記事を参照してください。

感想

スライドを見たのみ(本来はRemote.vueの1つの発表)なので、理解しきれているかは微妙である。
個人的にはかなりディレクトリと内部が今まで見たことのないものでよかったが、一方でルールとして咀嚼すること、ドキュメントへ落とすことが大変だなと思った。
受託開発か否かでかなり差が出る内容だと思っており、受託でなく時間がそれなりにあるのであればこのように考えていくのもありかなと思った。どうしても人数が不定期に増減するなどがあると、アーキテクチャへここまで時間を割いて理解できるドキュメントを起こせるかというと、少し難しい気もした。

Discussion

ログインするとコメントできます