iOSDC Japan 2016 参加メモ: A-5 Reactive State Machine
- @inamiy さん LINE
リアクティブプログラミング
時間経過に伴うイベントストリーム
FRP 関数型リアクティブプログラミング
- データフローを構築する
データフロー = 川の流れ
- 流れてくる状態の管理
Data Binding
- 定期的にデータを流して、データを常に変更できる状態に
Data Observing
- KVO出ないかぎり、永続監視はできない
- 継続的なデータフローとして永続化したい
Observable / Signal = EventEmitter
Variable / Mutable Property = EventEmitterの現在の値
FRP + MVVM で簡単になる
- 本当に？
ポケモンに例えてみるw
ViewModelがどんどんできてくる
- Viewの数だけViewModelが出来上がってしまう
これらが相互に連携して・・・複雑なデータフローを形成していってしまう
- つらい
FRP + MVVM
- フロー構築は楽になる
- 状態管理が楽になるわけではない
FRP + MVVMの問題点
- let Variableとvar rawValueと変わらない
データフローそのものが状態になってしまう
状態操作は楽になった
- が、状態の数は増えてしまった
どうすればいいのか
発送の転換
- データフローの固定化
- 状態の数を最小化
React.js
React.jsとは
Viewをステートレスに扱うフレームワーク
- 狭義の意味でのリアクティブプログラミングってわけじゃないよ
親の一つだけがstateful
子が全てstateless
しかし、データフロー構築は面倒
- 子から親へのデータフローが辛い
Redux
- 状態を一つのコンテナで管理
- 状態の管理がシングルトンにまとまる
問題点もある
Middlewareの位置づけ
- 役割が明確に位置づけられているが、分割しすぎていて面倒になる
- Reducerと密結合な方が楽なこともある
非同期処理が難しい
- 同期処理を前提に設計されているので、非同期に連鎖反応した時にフローが予測しにくい
- 非同期処理はFRPに任せてしまったほうがシンプル
Reduxの型を眺める
- よく見ると、State Machineのことを言っている
- ミーリ・マシンと同じ
Redux + FRP
- ReducerとMiddlewareを統合
- Reducerの返り値をOptionalに
- 状態遷移の失敗のケア
非同期処理にFRPをつかう
ReactiveAutomaton / RxAutomaton
- というのを作った
- https://gist.github.com/inamiy/1835a88e00bd19dff003e779fe63a2ed
- サンプルの紹介
ReactiveAutomatonまとめ
＊小さな状態管理から大きなシングルトンまで幅広く対応可能 * Elmの基本設計に近い
Model View ViewModel -> Model View Automatonへ
