私とRxSwift
2013-2014年
C#な世界でLINQとかReactive Extensionsが高評価なことを知る。
iOSアプリ開発でもこれを生かせないかということを考えはじめる。ReactiveCocoaのことも知る。
サーバーサイド方面でもReactive Programming の話題が活発なことを知る。
直接関係ないど何故かこの時期React(JS)も話題になってたりReactiveなんとかバズが到来していた。
https://www.reactivemanifesto.org/
Androidアプリ開発でもRxJavaが使われているらしいと聞く。当時入手できたAndroid端末は非力なものが多くてそんな巨大なライブラリ入れてるんだと驚いた記憶がある。
以下は時代背景が知れるRebuildの回
2016-2017年
アッテチーム の新規開発でRxSwiftを活用してるという講演を聞いてよさそうやんけと思う。
自分たちでもRxSwiftを使いはじめ試行錯誤する。
2018-2019年
周りがエンジニア0〜1人のスタートアップばかりになったので、新規プロジェクトではRxSwift使わなくていいんじゃない？ と言いはじめる。
google/promises あたりからでよいのではという説を唱えていたが、モバイルアプリ自体を開発しなくなった。
何がIssueだったのか
非同期処理
Future/Promise パターンのかわり
Web APIと連携するモバイルアプリはネットワークI/Oを多用するのでそこの記述にコールバック関数を使いがちだった。
GUIのイベント処理もマルチスレッドで非同期に行うことが多いので組み合わせるとグッチャグチャになりがちだったところにフィットしたと思う。
ストリームオブジェクトにすることでキャンセル処理も気軽に書けた。
Observableパターン
親子関係のあるような画面構成でこっちの画面で行った処理を伝達させて別の画面でUIを更新するっていうパターンをやりたかった。
GUIはステートルフルなので、どこから元となるデータを取得するかという処理が一箇所にまとめられたのが良かった。
宣言的UI
イベントごとに変化する画面を手続きコードで記述しているうちに管理がたいへんになってきた。
UIデータバインディングにすることでデータAがあったらこのUI、ストリームBが来たらこの動きをする。というコードを積み重ねて拡張できた。
あとUIのイベントをオブジェクトにできるので、頑張ったらテストも書けた(書くのはたいへんだった)
状態管理
UIデータバインディングにすることで状態管理をどう実現するのかっていう次のIssueに進めた。
ReactのFluxアーキテクチャがターニングポイントで、双方向データフローではなく単一方向にしましょうね、というところに落ち着いた。
業界ではサーバーレスポンス+ローカルキャッシュ+Redux化などの研究がどんどん進められていたが、そこはあまり関心を向けていなかった。
どう解決されたか
以下のようなトピックだけ知っているけど満足に活用した経験はないので、詳しい人に解説してほしい。
Swift Concurrency で非同期処理
UIKitからSwiftUIへ
Combine やObservation
おわりに
振り返ったことで
- Rxの話と見せかけて関心事はGUI開発のアーキテクチャ全体に及ぶ
- またモバイル開発はWebプラットフォームの影響を強く受けている
というのが分かった。
このように前提条件が素早く変化するプラットフォームでは、チーム開発での長期的なコミュニケーションにおいてはArchitectural Decision Recordsを残すのが定石と思う。
