【Flutter】今週のインプット 2021/5/17-23
今回の記事は、Flutterについてここ一週間(2021/5/17-23)でのキャッチアップをつらつら書いていこうと思います。
こんにちは、とりかつ((@torikatsu923)https://twitter.com/torikatsu923)です。
今回の記事は、Flutterについてここ一週間(2021/5/17-23)でのキャッチアップをつらつら書いていこうと思います。
Flutter2.2
先日のGoogleIOにてFlutter2.2が発表されました。
Announcing Flutter 2.2 at Google I/O 2021
Flutter2.2の内容についてはここの記事がよくまとまっていました。
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重ダウンロードの修正が入ったようです。 この修正を手元のプロジェクトで有効にするためには以下の手順を踏めば良さそうです。
- index.htmlを削除する
flutter create .を実行する
また、アクセシビリティ周りの機能も充実しました。
dev tool のアップデート
devtoolでProviderを確認できるようになりました🎉
The devtool for Provider is out 🎉 pic.twitter.com/BIL6ERymOP
— Remi Rousselet (@remi_rousselet) 2021年5月19日
riverpodのProviderは絶賛対応中だそうです。
riverpod
docsの更新
0.13.0 -> 0.14.0のStateNotifierまわりの破壊的変更に伴う、マイグレーションガイドが追加されていました。
どうやらcliでマイグレーションを行うことができるようです。
$ dart pub global activate riverpod_cli
$ riverpod migrate大幅なアップデート
こちらのIssueを眺めていると、riverpodの書き方の大幅なアップデートが入ることがわかりました。
[RFC] Unifying syntax for listening to providers (v2) · Issue #335 · rrousselGit/river_pod
個人的に大きいと感じていることは、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でハンドリングしたいことが結構あります。 （構成図の出典（Medium に掲載された図版））
dartにはJavaでいうthrowsのような構文がないため、どんなエラーを吐くのかを知りたいときはメソッドの内部使用を見る必要があります。 しかし、これではメソッドを呼び出す側がメソッドがどんな型のエラーを吐くかを知ることになります。 これでは、せっかくレイヤーごとに分離しているのに、レイヤ間が密結合になってしまいます。 また、エラーハンドリング漏れも十分に考えられます。
そこで、Resultを使用する方法が考えられます。
Resultライブラリを使うべきか - ntaoo blog
Resultは値に対して成功、失敗の文脈を持たせることができるため、エラーハンドリングの漏れを防ぐことができます。
さらに、独自のResultクラスとエラークラスを定義して、各エラーをアプリケーションに依存したエラーへ変換することで、よりすっきりした構成にすることが可能です。
wasabeef/flutter-architecture-blueprints
-––