FlutterでAtomic DesignとProviderとBLoCパターンを使って構成してみた

こんにちは!
今回は個人的な開発で、ネイティブアプリを作成するのにFlutterを使用しているので、使用した構成や困ったことなどを書いていこうと思います!

使用しているパッケージ

まず、前提としてWeb APIとの通信をするアプリの開発をします。私は下記のライブラリを使用しています。

▼dependencies
・http: APIとの疎通に使用します。
・json_annotation: json_serializableでのアノテーションの定義用パッケージ
・provider: BLoCの管理で使用します。2019年から主流になってきて、Googleでもこちらを使用するようにという事で進んでいるようです。

▼dev_dependencies
・build_runner: json serialize及びdeserializeの処理を自動生成してくれるビルドランナー
・json_serializable: json_serializableで使用されるアノテーションを定義するパッケージ

アーキテクチャ

・ディレクトリ構成

├── bloc
├── domain
│   ├── model
│   ├── repository
│   └── service
├── router.dart
└── view
    ├── components
    │   ├── atom
    │   ├── molecule
    │   ├── organism
    │   └── template
    └── pages

・全体像

※BLoCと Service に関しては、components内で使用する場合があります。

・view周りは基本的にpageからtemplateを呼び出し、そこにorganismを入れていくのが主となりますが、大規模でない場合はtemplateは必要ないと思いました。

・viewからdomainへのアクセスはserviceを通すことを厳守し、modelをviewに渡して使います。

・viewに渡されたモデルを状態として管理したい場合はBLoCに入れます。

・repositoryはAPI Providerとしての役割も持たせているのですが、分けた方がいいかなとも思いました。

この構成で困ったこと

・先ほども記載しましたが、大規模でない場合はtemplateは作るのが面倒ですし必要ないなと思いました。pageに対してorganismを入れていくほうが簡単ですし小回りも効くなと思います。

・BLoCはProviderを使用してStreamとSinkを行っているのですが、pageの状態を管理する上でServiceから受け取ったModelをBLoCのプロパティとして入れるのか、そもそもModelをBLoCとしてしまうのか、どちらがいいのだろうと困りましたが、個人的にはビルドランナーを使用して簡単にModelを作りたかったので、ModelをBLoCのプロパティとして持たせています。

oCはProviderを使用してStreamとSinkを行っているのですが、pageの状態を管理する上でServiceから受け取ったModelをBLoCのプロパティとして入れるのか、そもそもModelをBLoCとしてしまうのか、どちらがいいのだろうと困りましたが、個人的にはビルドランナーを使用して簡単にModelを作りたかったので、ModelをBLoCのプロパティとして持たせています。

まとめ

Flutterはまだまだ新しいフレームワークなので、基本的な使い方などは公式リファレンスを見れば大体わかるのですが、設計周りの事を調べるのは情報が少なく中々苦労しました。

とはいえ、他のプログラムを知っていると入りはかなり楽に入れるフレームワークで、viewのcomponentも簡単に作成できたりと、デザインができない私としてはとても嬉しいフレームワークです。もっと勉強して業務レベルで使えればなと思います!

関連記事

プロジェクトストーリー

おすすめ記事

技術

コメント

この記事へのコメントはありません。

カテゴリー

TOP
TOP