先日、FlutterGakkai の第 5 回に登壇者として参加させていただきました。プロポーザルを採択していただきましてありがとうございます。
https://fluttergakkai.connpass.com/event/304163/
他の方の発表も面白く勉強になり、懇親会も普段の生活ではあり得ないほど多くの方々と話しきれないほどの話題で盛り上がれました。FlutterKaigi や Flutter Cafe で知り合った方ともまたお会いできて楽しかったです。
さて、この投稿では自分の発表の補足説明やコメントへの回答などをざっくりできればと思います。
まずは自分の発表資料がこちらです。
https://docs.google.com/presentation/d/1QmzlfOTTnmkCTX9ov36KMGceL1HeCwYPaldc7J3w3Qk/edit?usp=sharing
「GetX を眺めて学ぶ Flutter」ということで、GetX そのものの使い方を理解するというよりは、GetX の実装や考え方を研究することで Flutter をより詳しく知ろう、さらにはパッケージの内部実装を読む面白さを知ろう、という内容になっています。
資料の中でも書きましたが、自分は GetX を使ったことはありません。先日の FlutterKaigi の発表に向けて Riverpod だけでなくその他の状態管理パッケージも同じように比較しながら調べていたところ、GetX の内部実装が面白かったので発表用にまとめてみようかな、と思ったのが今回の発表のきっかけです。
資料にもある通り、GetX の最大の強みは context などの Flutter 特有の仕組みを意識することなく画面遷移やダイアログ、言語切り替えなどを行える点です。言い換えると、Flutter 標準の方法でそれらを実装することに不便を感じない場合、あまり GetX を使うメリットはないと考えています。
ただしこれは、GetX の「 context なしで本来 context が必要な動作を実現できる」という部分についてのみの評価です。GetX はそれ以外にも状態管理パッケージとしての機能が含まれています。ここについてはまだどんな場合に有用なのかの自分なりの結論は出ていない状態です。いただいたコメントによると、Rx を使い慣れている方にとってはとっつきやすいところが良いそうです。
自分がアウトプットするどの情報についてもそうですが、一方的に「使うべき」「使わないべき」を決められる技術というのは本当に稀で、だいたいは「目の前の要件や状況に応じて自分で使うかどうかを判断する」のが開発者としての仕事だと思っています。
GetX についても「なんか使わない方が良いと言われてるから使わないし調べない」で避けてしまうのはもったいないと思った、というのも今回の発表のモチベーションでした。
懇親会でもそんな意図が伝わっていそうな会話ができてとても嬉しかったです。
使うべきかどうかを私が決めることはできませんが、調べたり触ってみたりすることは確実にその後の開発のプラスになるはずです。おすすめです。
さて、そんなお気持ち表明をしたところで、ここからはいくつかいただいたコメントに対して回答したいと思います。
生ちゅーやんでした。普段は所沢の自宅にこもって開発しているので、自分も「生 Flutter 開発者の方々がこんなに、、！」と思いながら参加させていただきました！
そうですね。Flutter の事情をとにかく隠すことで Flutter を初めて触る人でも Flutter アプリ開発でスタートダッシュをキメられる、というのが GetX の狙いだと思っています。実際それが当たっているからこそあの LIKE 数がつくほどの人気になっているのだと思っています。
そうですね。 Navigator やそれに紐づく NavigatorState、StatefulElement などのインスタンスは「引き回される」というよりは「 GlobalKey に紐づけられて BuildOwner によって管理される」という形で適切に保持されています。GlobalKey の currentState あたりの実装に飛ぶとわかりやすいかもしれません。
よかったです！資料公開しました！
こちらのコメントを MVC （Most Valuable Comment）に選ばせていただきました！その通りでございます。使わないにしてもコードを読んでみると新しい発見があって楽しいと思います！おすすめです。（再掲）
「品がない」のニュアンスが正確に読み取れているかは微妙ですが、気持ちはわかりますし、おそらく正しいです。
Flutter でも context を使う方法が標準であるように GlobalKey を多用すると「どこからでも UI をいじれてしまう」という問題が発生しやすくなり、ロジックと UI の分離がむずかしくなります。使い所の見極めが大事ですね。
このあたりは「開発者が設計で気をつける」で解決することもできなくはないですが、最近のトレンドとしては「気をつける」ではなく「仕組みとしてできないようにする」のが基本ですので、その点では Riverpod のような「不適切なことは仕組み上できないようになっている」作りが（理解が必要になる点はあるものの）最終的には安全だと思います。
GetX が避けられる理由の一部はこのロジックと UI の境目が曖昧になる、という部分かなと思っています。
ですね！たとえば provider パッケージでは「同じ型の状態オブジェクトを複数置けない」ことがデメリットと言われていますが、Flutter の Widget ツリーではこの「同じ型の Widget をサブツリーに置くことで、子孫に意識させることなくデザインや挙動を上書きする」手法がふんだんに使われていますので、それを利用できるようになるとさらに Flutter フレームワークが使いこなせると思います。
そうですね！コードの都合上どうしても context を参照できない場合はまさに GlobalKey の出番です。
あとは、祖先ではなく子孫に配置されているはずの Navigator を使って画面遷移をしたいような場合もやはり GlobalKey ですね。
まさにその点が GetX を使いすぎるリスクだと思っています。
GetX は Flutter の仕組みを隠してコーディングしやすくしているパッケージですので、逆にいうと Flutter の仕組みを理解して使いこなすことは GetX 前提のコーディングをしている限り実現できないのではと推測しています。
長く Flutter を使うことが見えている場合は、GetX を使う場合でも Flutter の学習自体は並行して必要で、どこかのタイミングで GetX を使い続けるかどうかを見直すことになるのだろうなと思います。
というわけで以上です。
ほかにも疑問や質問などがありましたらぜひ何かの形でコメントください。可能な範囲で拾っていきたいと思います。
改めて、FlutterGakkai を開催・運営していただいた関係者の皆様、発表を聞いていただいた参加者のみなさま、スポンサーの各企業様、とても楽しい場を実現していただいてありがとうございました！
次は FlutterNinjas での登壇を目指したいと思います。Remi さんの前で Riverpod について何か話たいです。
中條 剛 [Tsuyoshi Chujo] 