📘

自分用のFlutterプロジェクトテンプレートを育て始めた

に公開

こんにちは、Flutterプロジェクトのテンプレートを育て始めたので、記事を書いておきます。

リポジトリ

https://github.com/dl10yr/my_flutter_template

モチベーション

  • AIがコードを書くなら設計がより重要になりそうと考えているから

    • 中身を理解しているテンプレートを育てるのが大事になりそう?
  • dartのWorkspace、melos使ってみたい

https://dart.dev/tools/pub/workspaces
https://pub.dev/packages/melos/versions/7.0.0-dev.8

  • いつも悩むところだいたい同じで、煮え切らないまま走り出すことが多いから、テンプレートで煮え切っておく
    • 特にディレクトリ構成、命名規則...

参考にした

以下のリポジトリを参考にさせていただきました。やること自体は概ね同じ気がしますが(Flutter公式のサンプルアプリはriverpod使ってないから違うけど)、ディレクトリ構成とかに違いがありますね。

https://github.com/flutter/samples/tree/main/compass_app
https://github.com/hukusuke1007/flutter_app_template
https://github.com/yumemi-inc/flutter-mobile-project-template
https://github.com/altive/flutter_app_template
https://github.com/bizz84/complete-flutter-course

感想など

ディレクトリ構成

いつも悩みます。これの組み方を色々試すのが一番時間がかかりました。

Layer-first vs Feature-first

https://codewithandrea.com/articles/flutter-project-structure/

今回、Layer-first構成も試してみたのですが、Feature-firstの方がどうしてもしっくり来たので、featureにしました。
(というか、途中からworkspaceでpackageに分けました)

サブ機能のディレクトリも作る

サブ機能のディレクトリを作るかも結構悩むのですが、これも作る方が個人的には楽に感じます。
(上から辿っていってファイルが探しやすいので)

features/
└── aaa/
  ├── common/
  │   ├── data/
  │   ├── domain/
  │   └── ui/
  │       └── view/
  └── bbb/
      ├── data/
      ├── domain/
      └── ui/
        ├── provider/
        └── view/

providerおよび定義しているファイル関連

まぁこの辺は好みで良いと思うのですが、プロジェクト内で方針を一貫させるのって以外に難しいなと感じます。

  • providerの命名規則
    • (Async)NotifierはNotifierをつける
  • ファイルの命名規則
    • suffixに_providerつけるか? -> つけない。Notifierは_notifierをつける
  • ファイルを/providerに置くか?
    • これは/providerに置いたけど、その必要はなかったと思う。ui層だけ/providerあったほうが良さそう

workspace, melos

少人数で開発するときに、実際にどれくらい生産性が上がるかは正直実感できなかったのですが、なんとなく整頓されている感じが「気持ち良く」感じました。

最後に

こういうテンプレートを作るのは、普段時間を使えないところに使える気がするので、良いですね。
思考や理解も整理されます。これからも更新していきたいと思ってます。

Discussion