try! Swiftメモ: Day1-6 毎日リアクティブ
reactiveもかなり定着して来た感じですね。
Ustreamのような大規模なサービスでも安定的に活用できているそうなので、かなりパワフルで期待できますね。
これまでは使えば使うほどイベント管理ができなくなりそうなイメージでしたが、
ちゃんと突き詰めると簡潔にかけると聞いて、今度採用してみたいと思いました。
reactiveの楽しさに触れて仲間入りしたい
概要
Why reactive ?
- Ustream
- 何百万人に出すので、安定している可読なコードベースを意識
- → であるがゆえにreactiveなコードをかいている
- == reactiveは安定的で可読的
- なにより楽しい
- → であるがゆえにreactiveなコードをかいている
- いくつかのパラダイムをミックスして使っている
- 求めているクオリティを維持するため
What is reactive ?
- リアクティブとは?
- データとデータフローを管理するのがリアクティブ
- CWS Signal
- 非同期データ
- reactiveで解決しよう
- stateを減らすことがメリットとなる
- テストしやすくなる
- 変化に対するリアクションとして定義していく
- how ではなく whatにフォーカスすることができる
- 宣言型で書ける
- ReactiveKit
- コンセプトは似ているので、そこを学ぶ
リアクティブのメリット
When do i apply it(reactive)?
- ある複雑なコードがあるとき、reactiveを使うとさらに複雑になる
- しかし、ある地点を過ぎると簡潔になる
- うまくいくケース
- reactiveをviewとvcでつかう
- 通信で使う
- MVVM
- ViewとViewロジックでの同期
- 複雑性に対して解決を見出そうと思っている
- ステート変更を管理する
- Reduce
- flagが3つくらいあったら
- reactive(flag1) && reactive(flag2)
- というようにかける
- flagが3つくらいあったら
- Combine
- Simplify , Unify async operations
- operationをチェーン化していく
- trade off
Tips
Debugging - No.1
- どうやってデバッグする ?
- 一定のストリームに問題がありそうなときはどうするか
- console.logをストリームにアタッチしていく
- 一定のストリームに問題がありそうなときはどうするか
- どうやってデバッグする ?
Fancy KVO
- Observationがパワフルなので、色々使いたくなる
- KVO使い過ぎるとパフォーマンスが落ちてしまう
- View bindingを使っていこう
- Observationがパワフルなので、色々使いたくなる
inject side effect carefully
- side effectが増えると、測定が難しくなる
- どこが変わるとどこが変わるかがわかりづらくなる
- side effectは本当に必要な時だけ入れる
- e.g. トラッキングとか
- side effectが増えると、測定が難しくなる
Avoid chaos
- Immutability + schedulers
- .onScheduler(MainScheduler)
- Immutability + schedulers