torikatsu.dev

Flutterとかプログラミングとかガジェットとか書きます

【Flutter】今週のインプット 2021/5/17-23

こんにちは、とりかつ((@torikatsu923)https://twitter.com/torikatsu923)です。

今回の記事は、Flutterについてここ一週間(2021/5/17-23)でのキャッチアップをつらつら書いていこうと思います。

Flutter2.2

先日のGoogleIOにてFlutter2.2が発表されました。 medium.com

Flutter2.2の内容についてはここの記事がよくまとまっていました。 medium.com

Dart2.13

Flutter2.2ではDart2.13が利用可能です。 Dart2.13ではクラスのタイプエイリアスを定義することができます。

// いままでのtypedef
typedef VoidCallBack = void Function();

// 2.13で可能になったtypedef
typedef Json = Map<String, dynamic>

いままでJsonをパースする処理でMap<Map<String, Map<String, dynamic>>>とか書かなければならなかったところがすっきり書けるようになったので とても嬉しい機能です。

Flutter web

main.dart.jsの2重ダウンロードの修正が入ったようです。 この修正を手元のプロジェクトで有効にするためには以下の手順を踏めば良さそうです。

  1. index.htmlを削除する
  2. flutter create .を実行する

また、アクセシビリティ周りの機能も充実しました。

dev tool のアップデート

devtoolでProviderを確認できるようになりました🎉

riverpodのProviderは絶賛対応中だそうです。

riverpod

docsの更新

riverpod.dev 0.13.0 -> 0.14.0のStateNotifierまわりの破壊的変更に伴う、マイグレーションガイドが追加されていました。

どうやらcliマイグレーションを行うことができるようです。

$ dart pub global activate riverpod_cli
$ riverpod migrate

大幅なアップデート

こちらのIssueを眺めていると、riverpodの書き方の大幅なアップデートが入ることがわかりました。 github.com

個人的に大きいと感じていることは、ProviderListener周りのアップデートです。

いままで、値の変更に応じてダイアログを表示したいようなケースではProviderListernerを使って、 以下のようにウィジェットを囲む必要がありました。

class Example extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return ProviderListener<Something>(
      provider: anotherProvider,
      onChange: (context, value) {}
    );
  }
}

これがバージョンアップによって以下のように書くことができるようです。

class _StatefulExampleState extends State<StatefulExample> {
  @override
  Widget build(BuildContext context) {
    A value = watch(a);
    listen<A>(a, (value) {
    });

  }
}

ウィジェットをネストする必要がなくなったため、よりフラットにかけるようになりました。

Flutterにおけるエラーハンドリング

Flutterで以下のようなMVVMライクな構造にしようとしたとき、DataレイヤのエラーをViewModelでハンドリングしたいことが結構あります。 https://miro.medium.com/max/700/1*Uj5dnm3RTQ89uidDpcObHw.jpeg

dartにはJavaでいうthrowsのような構文がないため、どんなエラーを吐くのかを知りたいときはメソッドの内部使用を見る必要があります。 しかし、これではメソッドを呼び出す側がメソッドがどんな型のエラーを吐くかを知ることになります。 これでは、せっかくレイヤーごとに分離しているのに、レイヤ間が密結合になってしまいます。 また、エラーハンドリング漏れも十分に考えられます。

そこで、Resultを使用する方法が考えられます。 ntaoo.hatenablog.com

Resultは値に対して成功、失敗の文脈を持たせることができるため、エラーハンドリングの漏れを防ぐことができます。

さらに、独自のResultクラスとエラークラスを定義して、各エラーをアプリケーションに依存したエラーへ変換することで、よりすっきりした構成にすることが可能です。 github.com