3-1. ざっくり

app

• ルーティングするところ

pages

• ページのレイアウトとか、機能を集積するところ
• データの変換層

features

• 機能を定義するところ
• 互いに排他的であること

components

• 汎用コンポを配置するところ

って感じの順位にする。もちろん、上位が下位で参照されないように制約いれる

3-2. pageとfeatureとcomponent

このプロジェクトでは明確に責務をわけたい

page

• そのページが提供する機能の集積
• データの受け取りは、サーバサイドで、一度レンダリングされると、基本的にクライアントでなんとかする。

feature

• システムが提供する機能
• 互いに排他的になるのかが、考えどころ

component

• 汎用性が高い。
• それ単体はほとんど役に立たず、主に見た目を提供してくれるもの。

3-3. featureの排他的性がレンダリング性能を改悪にするかもしれない

素結合にする汎用度が高くなるということは、親コンポ＝ページコンポからのバケツリレーが多発することが考えられる。

となると、全量レンダリングされることは避けられないだろう。
いいのかこれ？

3-4. 感想

パッケージ構成ばっか気にしていると、前に進まないので、調子がいい時にやろう