RealtimeDB胸熱話
@axross
いえーい
whoami
- @axross / Kohei Asai
- Kaizen Adを作ってたマン
- 2016年11月入社
- 2018年6月29日最終出社
RealtimeDB最高なので
- フロントエンドに限らず技術的なリードをした (たぶん)
- アプリケーションアーキテクチャの構築
- コードスタイルの確立
- たぶんAdの技術面はワシが一番知っとる(ドヤッ
やってきた中で
考えてきたことを
話します
○○○エンド奴隷化を
防ぐ
○○○エンド奴隷化
- バックエンド奴隷化
- APIがフロントエンドが欲しいデータを返してしまう
- フロントエンド奴隷化
- APIから得られるデータをどうにかして画面を表示する
- APIから得られるデータ以上のことをしない
どうやばいの?
- 仕様変更に弱い
- コストが肥大化する
- どこでどういうエラーが出るか予測できない
- 変更を怖がるようになる
- 奴隷側が不満を持ったまま働くことになる
防ぐには
- ときには原理主義的な考え方に身を預ける
- 「どうあるべきか?」を自問自答する
- これを考えるにはデザイン的な考え方が必要になる
「どうあるべき」を
どう探す?
- ユーザーシナリオを理解してドメインモデルを洗い出す
- 「画面上でどういうことをするか」になっては駄目
- -> バックエンド奴隷化
- 「どうデータベースに入れるか」になっては駄目
- -> フロントエンド奴隷化
- 「画面上でどういうことをするか」になっては駄目
InheritedWidgetの動き
- Widgetを継承しており、他のWidgetと同じように build() 内で使える
- 基本的にInheritedWidgetの child はリビルドされることがない
- InheritedWidget自身は build() メソッドを持たない
- ReactでいうとchildrenをそのままレンダーするHOC
InheritedWidgetの動き
- とはいえ他の要因で強制的にリビルドされることはある
- 「デバイスの向きがPortraitからLandscapeに変わった」など
- updateShouldNotify() を実装していると、子孫Widgetが再Buildされるべきかどうかを自身の同等性を担保する形で防ぐことができる
InheritedWidgetが使われているもの
- DefaultTextStyle
- IconTheme
- MediaQuery
- etc.
- その他、できそうなこと
- Dependency Injection
Dependency Injection
class Container {
Container({ @required this.foo });
final Foo foo;
}
class Provider extends InheritedWidget {
static Container of(BuildContext context) =>
context.inheritFromWidgetOfExactType(Provider).container;
Provider({Key key, Widget child, this.container}):
super(key: key, child: child);
final Container container;
@override bool updateShouldNotify(Provider old) =>
container != old.container;
}
スペース不足のため色々割愛
Contextを扱う
ベストプラクティス
static Foo of()
- というStaticメソッドを実装するのが定番
-
Contextを返す
-
Theme の例であれば ThemeData を返す
-
Dependency Injectionの例であれば注入されたコンテナを返す
-
-
ほとんどのFlutter標準APIではこの形になっている
責務とサイズを最小限に
- 1つのInheritedWidgetに何でもかんでも詰め込まない
- updateShouldNotify() の実行コストが高くなる
- 責務を適切に分離するのは言わずもがな大切
できるだけ const
-
子孫Widgetのキャッシュが効く
- InheritedWidgetのメリットを最大限享受できるようになる
- というか、Flutter一般的にもベター
Thank you
for
listening!
Copy of いえーい
By Kohei Asai
Copy of いえーい
- 350