Widgetの構成の方針について

[naipaka]

このディスカッションのコメントを含めた内容は以下ページにまとめています📝
https://zenn.dev/altive/articles/flutter-presentation-directory

---

概要

Widgetの構成の方針をチームとして決めたいです🙋‍♂️
具体的にはXxxPage/XxxView/XxxButtonなどの各コンポーネントの分け方を定義したいです。

個人的にですが、構成についてチームで方針が決まっていると下記のようなメリットがあると思っています。

• 実装の際にWidgetの分離に迷いにくくなる
• レビューしやすくなる
• 責務が明確に分けられていてテストが書きやすくなる
  などなど…

みなさんは普段どんな構成で考えて実装していますでしょうか？👀
自分はまだこれといった形が定められていないので、みなさんの意見を聞きながら方針が決められたら嬉しいです！

以下Altiveのflutter_app_templateをもとに、自分が普段考えている構成を記載しましたので、「こうした方がよさそう」や「自分ならこういう構成にする」などあれば、コメントいただきたいです！🙏
（そもそもここまで決めなくても良いなどの意見も歓迎です！🙇‍♂️）

---

構成の概要

PageとViewとその他画面構成要素でクラス及びファイルを分ける。

Page

• 各画面と1対1の部品
• 画面を構成する枠組み部分として定義
• Scaffoldを配置し、appBarやbody、floatingActionButtonなどには分離したクラスを設定
  • PageからはappBarのタイトルやbodyの中身、floatingActionButtonがどう動くかなどは知らなくて良い状態とする

具体例

home_page.dart

class HomePage extends StatelessWidget {
  const HomePage({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: HomeAppBar(),
      body: const SafeArea(
        child: HomeView(),
      ),
      floatingActionButton: const HomeFloatingActionButton(),
    );
  }
}

View

• 各画面と1対1の部品
• 画面を構成する中身部分として定義
• Scaffoldのbody部分を管理
• 基本各要素を参照するだけ
  • Viewからは各要素がどのように働くかを知らない状態とする

具体例

home_view.dart

class HomeView extends StatelessWidget {
  const HomeView({super.key});

  @override
  Widget build(BuildContext context) {
    return SingleChildScrollView(
      child: Padding(
        padding: const EdgeInsets.symmetric(
          horizontal: Layout.horizontalMargin,
        ),
        child: Column(
          children: const [
            HomeHeader(),
            TodoList(),
            HomeFooter(),
          ],
        ),
      ),
    );
  }
}

その他画面構成要素

• Viewに載せる画面要素
• まとまりとして認識できるコンポーネント単位で分ける
  • ここら辺はまだ感覚でしかないのでどう定義すれば良いか迷い中

ディレクトリ構成例

ホーム画面にTODOリストを表示するような画面をイメージしています。

.
├── main.dart
└── presentation
    ├── app.dart
    ├── components
    │   ├── link_text.dart
    │   └── sign_in_button.dart
    ├── pages
    │   └── home
    │       ├── components
    │       │   ├── home_app_bar.dart
    │       │   ├── home_floating_action_button.dart
    │       │   ├── home_footer.dart
    │       │   ├── home_header.dart
    │       │   ├── todo_list.dart
    │       │   └── todo_list_item.dart
    │       ├── home_pagedart
    │       └── home_view.dart
    ├── router
    └── theme_data

※ presentation以外とpage/components以外は省略しています。

---

以上よろしくお願いいたします！

[riscait]

確かに、チーム開発だと書き方がバラバラになりがちで、一定のこうしたルールがあると見晴らしも良くなりそうですね👀！

この場合、基本プライベートWidgetにはせずに components にするのが良いですかね？
（プライベートWidgetだとテストできませんが、プライベートメソッドと同じくテスト非対象とする考えもできそう）

そして、ページ遷移時（遷移の書き方によってはこれも不要）を除き別の page ディレクトリのインポートしないというルールを設けておくと良さそうですね👍

[naipaka]

この場合、基本プライベートWidgetにはせずに components にするのが良いですかね？

プライベートでも良いかと思います！
理想を言えばテストで動きが担保できるようにしておきたいので、page？等のテストにほかコンポーネントのテストも含めてしまうか、@VisibleForTestingをつける形でもよさそうな気がします🙋‍♂️

そして、ページ遷移時（遷移の書き方によってはこれも不要）を除き別の page ディレクトリのインポートしないというルールを設けておくと良さそうですね👍

そうですね！インポートしたくなったらpagesと同じ階層のcomponentsに移す形になりそうですね🙆‍♂️

[riscait]

なるほど！とはいえ、 components にするかプライベートWidgetにするかの明確な判断材料があると迷わずすみそうですね👀
基本Page/View内ではプライベートWidgetは使わないことにして全部 components に統一した方が良いかな〜🧐

そうですね！インポートしたくなったらpagesと同じ階層のcomponentsに移す形になりそうですね🙆‍♂️

その通りの認識です👍

[naipaka]

基本Page/View内ではプライベートWidgetは使わないことにして全部 components に統一した方が良いかな〜🧐

そうですね〜自分は基本componentsに統一が好みです🙆‍♂️

components統一のデメリットはファイル移動が面倒なくらいですかね？👀
自分はスクロールして参照するより横に並べて確認することが多いので、分かれていた方が嬉しかったりしますが！🙋‍♂️

[nmsp]

components統一僕も良いなと思いました🙌
ファイル移動も初めから分けるつもりであればそこまで気にならない気がします🙋

ちなみに、
(1) presentation/components と
(2) presentation/pages/home/components
の2つがあると思うのですが、イメージ的には

(1) 複数のファイルから呼び出される可能性のあるコンポーネント
(2) 親となるviewのみから呼び出されるコンポーネント

みたいな認識であってますよね…？🤔

[naipaka]

概ね認識あっていると思います！🙆‍♂️

(1)についてはpages配下の複数のディレクトリ（複数の画面）から呼び出され得るコンポーネントという認識です！
例えば複数ファイルから呼び出されているものの、呼び出し元が全てhomeディレクトリであればhome配下のcomponentsでもよいのかなと思っています👀

[riscait]

page , view はまとめる（bodyに直接書く or viewをプライベートWidgetにする）でも良いかなとは思いました👀
そうすると、基本的に page.dart と各コンポーネントファイルだけ行き来すれば良いので楽になるメリットがあるかなと。
ただ、 view の中身によってはインデント深くなったりするかも？🤔

[riscait]

そうですね、3階層は深すぎる気がしますので、以下のどちらかがよさそうですかね？🤔

    ├── pages
    │   └── home
    │       ├── components
    │       │   ├── home_footer.dart
    │       │   ├── home_header.dart
    │       │   ├── todo_list.dart
    │       │   └── todo_list_item.dart
    │       ├── home_app_bar.dart
    │       ├── home_body.dart
    │       ├── home_floating_action_button.dart
    │       └── home_page.dart

or

    ├── pages
    │   └── home
    │       ├── components
    │       │   ├── home_app_bar.dart
    │       │   ├── home_body.dart
    │       │   ├── home_floating_action_button.dart
    │       │   ├── home_footer.dart
    │       │   ├── home_header.dart
    │       │   ├── todo_list.dart
    │       │   └── todo_list_item.dart
    │       └── home_page.dart

[riscait]

下の方の page.dart だけ独立しているのが分かりやすくてスッキリもしている気がしてきました笑
外部からは pages/home/home_page.dart のみインポートして良いと分かりやすいのもあるかなと👀

（ここで part を使うのもありだったり？）

[naipaka]

確かにです笑
どちらかというと下の方が良さそうですね！👍

---

まだここでpartを使う時のイメージが思いついてないのですが、
part使うとしたら、scaffold_components.dartなどを作ってその中でpart components/home_body.dartなどを書くとかですか？🤔
それともホーム画面をまとめるファイル作ってそこにpage含むファイル全てをpartでまとめる感じですかね👀

[riscait]

home_page.dart で part 'components/xxx.dart'
各 components/xxx.dart で part of '../home_page.dart'
のように書く想定でした！（もしかしてそうは書けない…？）

しかしやはり、 part だとプライベートWidgetにできるメリットはありますが、 import だけで十分な気がしますね👀

[naipaka]

なるほど！自分がイメージなかっただけで書けると思います！
（自分の中ではこちらのように基本part元？にはあまり処理を書かないイメージだった感じです✍️）

そうですね、他のクラスからhome_pageをimportした時はcomponentsの機能まで使いたいわけではない気がするのでimport で十分そうな気がします💡

[riscait]

ただの予想なんですが、例えば当初は空の AppBar だった時、 appBar: AppBar(), と書くだけのことが多いと思うのですが、
後日 title や actions を追加することになったとき、じゃあ HomeAppBar() 作ってコンポーネントファイルに移すかってなったら、home_page.dart のAppBarに対して書いていたテストも components/home_app_bar.dart に移さなくちゃいけなかったりするのが面倒だったりしそうだと思いました！
もし合っているなら、これもメリットになりそうですね👀✨
（AppBar単体のテスト書かないならそもそも不要ではありますが）

[naipaka]

そうですね、「画面ごとに別のAppBarを作る」という仕様が決まっている段階でHomeAppBarやCustomAppBarなどで空のコンポーネントを作っておくイメージでした！

「AppBarなどはコンポーネントファイルで作る」というルールができていれば、テストを移す作業もなくなるのでメリットになりそうです🙆‍♂️

[riscait]

AppBarは PreferredSizeWidget ですが、普段どうやってコンポーネント化していますか？
戻り値が PreferredSizeWidget で引数で BuildContext を渡す関数ですかね👀

[naipaka]

別プロジェクトだと下記の感じで作ってましたね✍️

home_app_bar.dart

class HomeAppBar extends StatelessWidget implements PreferredSizeWidget {
  const HomeAppBar({super.key});

  @override
  Widget build(BuildContext context) {
    return AppBar();
  }

  @override
  Size get preferredSize => const Size.fromHeight(Layout.appBarHeight);
}

[riscait]

おぉ！これならWidgetとしてもPreferredSizeWidgetとしても使えるので良いですね！
ありがとうございます🙌

[nmsp]

├── main.dart
└── presentation
    ├── app.dart
    ├── components
    │   ├── link_text.dart
    │   └── sign_in_button.dart
    ├── pages
    ├── router
    └── theme_data

↑の構成分かりやすく良いなと思ったのですが、
components内のフォルダ分けについてはいかがでしょうか？
プロジェクトによってはcomponentsに入っているファイルが少ないので、
そこまで分けなくても…という気はしつつも、種類が多くなってきた場合は、
フォルダが分かれている方が分かりやすい気がしました🙋
(一旦想定しているのはpresentation/componentsの方です)

・フォルダ分けをするか
・フォルダ分けをする場合の種類のおおよその候補(buttons・dialogs・cardsなど)
あたりは決めれたら嬉しいなと思います🙌

[naipaka]

コメントありがとうございます！！🙏
確かに共通コンポーネントはどんどん増えていくものだと思うので、カテゴリごとに分けられていると探しやすかったりしてよさそうですね👀
分けるの賛成です！🙋‍♂️

ただ、どう分けるかが難しいですね…🤔
ボタン系やダイアログ系は分かりやすいですが、例えば「IconとTextをRowで並べたコンポーネント」などはどういう分類にしたらいいか悩みそう。。

最初は気にせずにcomponentsに入れていって、同じ分類のコンポーネントが複数出てきた時に同じディレクトリでまとめる、といった方針でも良いかなと思ったりもしました💡

[riscait]

確かに components 内の整理も重要ですね💡
小林さんのいう通り分かりやすいものや複数あるものだけ分けて、その他分けにくいものは多くなってから整理が良さそうですね。

presentation/components/components.dart で 一括 export して使うようにしておけば整理後に使用箇所で差分も出ないですし✍️

[riscait]

presentation/components と page/home/components の名前が components で一緒だと若干分かりにくいので名前を変えるのもあり？でもあえて同じ名前でも問題ない気もするし…🤔

短くて抽象的なのだと presentation/widgets とか…？
page/ も Widget なんですが…

[naipaka]

確かに初見で見た人が分かりにくいかもしれませんね🤔
結構他のアプリのディレクトリ構成見ているとwidgetsで分けている方もいて、
ある程度共通パーツであることがわかりやすい気がするのでwidgetsでもよさそうですね👀

他presentation配下のcomponentsの代替としては、長くなってしまいますが修飾子をつけてcommon_components、generic_components、public_componentsとかですかね…？

…と色々他の候探してみましたが、「画面を構成するための部品」というまとまりの意味は同じだと思うので、あえて名前も同じでもいいのかなと思ったりもします👀
別の名前に変えるとそれぞれ別の意味があるようにも見えてしまう可能性があったり、pagesと同じ階層にあるところからpagesに限らず汎用的に使うものというのが分かりそうなので修飾子も冗長に見える気がしました🧐

[riscait]

別の名前に変えるとそれぞれ別の意味があるようにも見えてしまう可能性があったり、pagesと同じ階層にあるところからpagesに限らず汎用的に使うものというのが分かりそうなので修飾子も冗長に見える気がしました🧐

確かに、widgets にしたらしたで、 presentation/widgets/ と presentation/pages/xxx/components の違いは何？という疑問に変わるだけかもしれないですしね👀

presentation/components が良さそうです🙌

[riscait]

Page の第一要素である、AppBar, Body, FABあたりは HomePageAppBar , HomePageBody のように「Page」までを名前に含めても良い気がしてきた👀

メリットとしては…

• スニペットで入力しやすい $1AppBar のような
• Page 直接の要素だとわかる
• Widget だと分かりやすい命名になる
  • 例えば TodoPage があったとして、 TodoBody だとTODO自体の何かだという印象があるが TodoPageBody だと、ページ（Widget）の要素なんだなと分かりやすい？ (TodoAppBar, TodoFAB あたりは問題なさそうではあるのでもしかしたら Body の方がいけないのかもしれない可能性がある)

[naipaka]

TodoBody だとTODO自体の何かだという印象があるが TodoPageBody だと、ページ（Widget）の要素なんだなと分かりやすい？

これは確かにです✍️
Page含めるのありですね！👀
componentsの中で一覧で見たときでもpage直接の要素というのがわかりやすくてよさそう💡
賛成です！🙋‍♂️

[riscait]

components ウィジェットにバケツリレーで state なりのパラメータを渡していくか、都度Widgetで ref.watch で取得するか問題👀
TopLevel の presentation/components は当然、 ref.watch でプロバイダを使うのが難しいし複数から使われるので引数で渡すとして、
画面固有の presentation/pages/xxx/components では ConsumerWidget で ref.watch 可能ならそうするのが良いと思うんですがどうでしょう？👀

[naipaka]

画面固有の presentation/pages/xxx/components では ConsumerWidget で ref.watch 可能ならそうするのが良いと思うんですがどうでしょう？👀

自分としてもその方が良いと思いました！✍️
むしろpresentation/pages/xxx/components配下のWidgetに対しては基本的に引数で渡すことはせず、
Providerから状態をもらってConsumerWidgetやConsumer(builder:)を使って表示するようにする、
とした方が描画範囲を末端に追いやりやすいくなったり、constつけやすくなって良さそうかなと思いました🚀

[riscait]

現在もやってみての改善を繰り返しています。
最新のFlutterアプリディレクトリ構成は以下を参照してください。
https://handbook.altive.co.jp/engineering/flutter/app-lib-directories/