[React]UIツリーに着目してフロントエンドの複雑さについて考えてみる
はじめに
Reactで開発しているとどうしても処理が複雑になり、コンポーネントが肥大化したり、副作用のある関数が増えてバグの原因になったりすると思います。
今回は「A Philosophy of Software Design」を読んだ上で、こんな構成にするといいんじゃないかな？と思うところがあったので、記事にしてみました。
考えが浅いところがあるかもしれませんがご了承ください。
データ構造で考えるフロントエンド
データ構造といっても難しい話ではなく、皆さんも馴染みがあるTree構造について考えます。
React公式ドキュメントにもUIをツリーとして理解するとあるように、基本的にフロントエンド開発において真新しい話ではないかと思います。
ここで以降の話で関連するものを以下3点ピックアップしておきます。
※一部意訳してますので、参照リンク先と定義が異なる箇所があります。
- Parent Node：子ノードを持つノード
- Leaf Node：子ノードを持たない末端のノード
- Subtree：任意のノードとその子孫
フロントエンドの文脈で考えると、Nodeはコンポーネントと読み替えて考えていただいて良いかと思います。
ソフトウェアにおける複雑さとどのように向き合うか
「A Philosophy of Software Design」を参考にすると、ソフトウェアにおける複雑さへのアプローチとして
- シンプルにすること
- 複雑さを隠蔽すること(※厳密には隠蔽ではなくカプセル化すること、と記載)
上記2点が考えられるかなと思います。
具体的に実装上はどのように考えれば良いでしょうか。
ここでは、副作用に着目してみたいと思います。
シンプルである、と言うことは、副作用がなく、参照透過性が担保されている純粋関数であると言うこと。
逆に複雑なものは副作用を含むものと定義してみます。
複雑さをどのように隠蔽するか？
結論
- ParentNodeに副作用を集約し、カスタムHooksで隠蔽する
- Leaf Nodeは純粋関数コンポーネントとして、副作用がない、かつ参照透過性が担保された状態で設計する
さらに厳密に言えば、カスタムHooksもデータの取得と送信があるような画面では
- loader hooks
- action hooks
といった形で分離すると良いかと思います。
※この点はRemixを普段書いてる方は自然とフレームワークの制約として分割しているかと思います。
さいごに
普段フロントエンドを開発している中で、どうしたらもっとシンプルに、保守性が高い状態で内部品質を担保できるだろう？と悩んできました。
本を読んだり手を動かす中で、今の所ベターだと思う考えをまとめてみました。
調べていたらRSCに関する記事にも似たようなことが書かれていたので、今後、よりUIツリーを意識した実装が効果的になる機会が多そうです。
不備や不明点などありましたらご指摘いただけますと幸いです。
Discussion