宣言的UIのデータアーキテクチャはコンポーネントを中心に考える
UIの最小単位はコンポーネントだが、データ構造や振る舞いの分割はどのように行うとよいのだろうか。 関連
などを実践した経験を持っているがうまくいったケースはほとんどない
なぜうまくいかなかったのか？
---
---
@adwd118: サーバーでロジック＞外部依存(DBなど)の関係にするのは理解できるけど、フロントエンドってクライアントっていうくらいなんだから外部依存を扱うことの関心のほうが主では？なのでReactのfetchと状態とViewが一度に現れるような書き方がポピュラーになった気がする @adwd118: フロントエンドとバックエンドでクリーンアーキテクチャの同心円が2つあるんじゃなくて、あくまでもサーバーサイドがメインの同心円にフロントエンドがくっつくイメージ https://pbs.twimg.com/media/FnxBA7FaAAQIhFr.jpghttps://pbs.twimg.com/media/FnxBDBzaQAEkAfu.jpg
GraphQLでいうと参照系でのdomain->usecase->viewあたりの変換はQueryの柔軟性でほぼ自動で、あとは更新系のドメインロジック(Usecase相当)をMutationに落とし込めばこの図での関係性はすごくしっくりくるのでやっぱりGraphQL最高🔥 @adwd118: あとそうだ、同心円以前の原則である依存性の逆転もフロントエンドでやらないほうが楽だと思う。サーバー・クライアントという関係からして明らかにサーバーに依存してるわけで、逆転で得たかったテスタビリティとかが別の手段で確保されてればいいんじゃないかな？ @adwd118: フロントでレイヤリングしてもいいけどああいうのが唯一の手段ではないし、別の生産性が高くてテスタビリティも同等なやり方があるのではという提案というか、最近のフロント見てると流れは明らかにそっちなはず const { loading } = useQuery(...);
で今どきは済むところをusecase->port->presenterとかやる意味ンゴ…😇
必然的にコンポーネントを中心に組み立てることとなる
@fumi_sagawa: propsを極力排してコンポーネントは閉じる。「jotaiで複数回使われる状態の共有/TanstackQueryでDB直通」させたいんだけど過激派かな？ 最近SPAはめちゃくちゃちっちゃいMVCの集まりだと思ってる @yuta0801_: 直接的にはあまり言及してるのを見ないが長い間Suspenseが事実上Relayで使うためにあったような状態だったのを感がるとReact側はGraphQL推してるはずで、それなのにNext.jsがfetchレベルで標準APIを拡張して制御させようとするのはよくわからないな 上述の「サーバーサイドがメインの同心円にフロントエンドがくっつく」という文脈を交えての仮設koushisa.icon
@rickhanlonii: @Dan Abramov It’s like original React changed how we thought about separation of concerns from separating technologies to separating components, and now it’s doing the same for separating the stack. It’s just components all the way down. Reactの登場によって、技術の分離からコンポーネントの分離へと、関心事の分離の考え方が変わりましたが、今度はスタックの分離も同じようになりました。スタックの分離も同様で、ずっとコンポーネントだけです。
---
これからどう考えるべきか
サーバーとクライアントは主従関係にある
リソースの構造や関係性に目を向けたコンポーネント設計が重要である UI/UXの仕様変更で複数のファイル or コンポーネントをまたがって変更するのは避けたい MVVMのようにデータ構造と振る舞いが密結合な双方向バインディングのアーキテクチャを避ける 依存を一方通行にするためにコンポーネントとイベントハンドラのインタフェースを整理する 細かく分けすぎるのではなく、一番外側の制御フローを意識的にシンプルにする
コンポーネントをまたいだロジックやステートで依存関係が生じる場合 ---
ペイするケースが少ない
あまり独自のXXX層とかを設けない
APIの構造とクライアント上のユースケースが合わない場合にはじめてドメインモデルを検討する 技術の変遷に対する考え方