📘
自分用のFlutterプロジェクトテンプレートを育て始めた
こんにちは、Flutterプロジェクトのテンプレートを育て始めたので、記事を書いておきます。
リポジトリ
モチベーション
-
AIがコードを書くなら設計がより重要になりそうと考えているから
- 中身を理解しているテンプレートを育てるのが大事になりそう?
-
dartのWorkspace、melos使ってみたい
- いつも悩むところだいたい同じで、煮え切らないまま走り出すことが多いから、テンプレートで煮え切っておく
- 特にディレクトリ構成、命名規則...
参考にした
以下のリポジトリを参考にさせていただきました。やること自体は概ね同じ気がしますが(Flutter公式のサンプルアプリはriverpod使ってないから違うけど)、ディレクトリ構成とかに違いがありますね。
感想など
ディレクトリ構成
いつも悩みます。これの組み方を色々試すのが一番時間がかかりました。
Layer-first vs Feature-first
今回、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
をつける
- (Async)Notifierは
- ファイルの命名規則
- suffixに
_provider
つけるか? -> つけない。Notifierは_notifier
をつける
- suffixに
- ファイルを
/provider
に置くか?- これは
/provider
に置いたけど、その必要はなかったと思う。ui層だけ/provider
あったほうが良さそう
- これは
workspace, melos
少人数で開発するときに、実際にどれくらい生産性が上がるかは正直実感できなかったのですが、なんとなく整頓されている感じが「気持ち良く」感じました。
最後に
こういうテンプレートを作るのは、普段時間を使えないところに使える気がするので、良いですね。
思考や理解も整理されます。これからも更新していきたいと思ってます。
Discussion