1 of 13

acceptableパッケージ を利用した

Provider + StatefulWidget というパターン

2021.10.27 (Wed)

Flutter Meetup Osaka #8

@chooyan_eng

2 of 13

自己紹介

中條 剛(ちゅうじょう つよし)

  • フリーランスエンジニア
  • Flutterでアプリ開発してます
  • パッケージ開発もしています
  • 講師・メンターもしています

内側から理解するFlutter

Zenn で販売中�

3 of 13

【宣伝】FlutterKaigi 登壇します

「Everything is an Element」というタイトルで FlutterKaigi に登壇します

Flutter フレームワークの内部実装の話をします

日付:2021/11/29(1日目)

時間:19:10 ~

4 of 13

本 題

5 of 13

Provider パッケージ使ってますか?

  • 「状態管理パッケージ」のひとつ
  • InheritedWidget のラッパー
  • 複数の子孫 Widget からアクセスできる
  • 変更があるとリビルドを発生させる
  • どの単位で状態オブジェクトを分割するかが悩ましい。(画面ごと?データごと?)

Provider

状態

オブジェクト

6 of 13

StatefulWidget 使ってますか?

  • Widget 単独で使える
  • とてもシンプル
  • 状態の保持とリビルドができる
  • 「Provider があれば不要なもの」ではない

Stateful

Widget

状態

オブジェクト

7 of 13

Provider と StatefulWidget を使い分ける

Provider(InheritedWidget)

状態を複数のWidgetで共有できる

UI に依存しない形式のデータを保持する

StatefulWidget

単一のWidgetの状態を効率よく保持できる

ある UI に完結する状態を、その UI を構築するのに最も都合の良い形式で保持する

8 of 13

イメージ

Provider

画面A

画面B

XxxNotifier

State

State

1. データを DB 等から取得、保持

2. データを「画面B」用に加工して

Stateに保持

2. データを「画面A」用に加工して

Stateに保持

9 of 13

加工処理をどこでやるか問題

  • context.watch() や context.select() が呼び出せるのは build() 内だけ。
    • build() の中で加工処理する?
    • build() はいろいろなきっかけで頻繁に呼び出され得る
    • build() で重い処理をしてはいけない
  • didChangeDependencies() という手も
    • didChangeDependencies() では「何がどう変わったか」は判断できない
    • 依存している状態が1つでも変わったら全てのデータを再加工しなければならない
    • watch() 処理と加工処理がコード的に遠くなるので単純に読みづらい

10 of 13

acceptable パッケージを使おう

  • acceptable パッケージとは?
    • Provider と StatefulWidget を効率よく連携させるパッケージ
    • AcceptableStatefulWidget を継承しacceptProviders() をオーバーライドする
    • がんばってつくりました。

11 of 13

acceptable パッケージを使おう

1. state.value を監視する (watch)

2. state.value を倍にする (apply)

3. state.value を倍にしたものを保持

4. そのまま表示

12 of 13

acceptable パッケージを使えば

  • 効率的
    • 依存する値が変更された時に、その値に依存する加工処理だけが呼び出される�
  • 簡潔なコード
    • 「依存する処理」と「加工する処理」を並べて書ける
    • 「宣言的」っぽいコーディングができる�
  • Provider を使い過ぎない
    • 1つの Widget に完結する状態は StatefulWidget で!

13 of 13

ご静聴ありがとうございました