きももまなきんのダンス

ぼちぼちと、技術的なあれこれを。

try! Swiftメモ: Day1-6 毎日リアクティブ

reactiveもかなり定着して来た感じですね。

Ustreamのような大規模なサービスでも安定的に活用できているそうなので、かなりパワフルで期待できますね。

これまでは使えば使うほどイベント管理ができなくなりそうなイメージでしたが、
ちゃんと突き詰めると簡潔にかけると聞いて、今度採用してみたいと思いました。

reactiveの楽しさに触れて仲間入りしたい

概要

Why reactive ?

  • Ustream
  • 何百万人に出すので、安定している可読なコードベースを意識
    • → であるがゆえに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)
      • というようにかける
  • Combine
  • Simplify , Unify async operations
    • operationをチェーン化していく
  • trade off

Tips

  • Debugging - No.1

    • どうやってデバッグする ?
      • 一定のストリームに問題がありそうなときはどうするか
        • console.logをストリームにアタッチしていく
  • Fancy KVO

    • Observationがパワフルなので、色々使いたくなる
      • KVO使い過ぎるとパフォーマンスが落ちてしまう
    • View bindingを使っていこう
  • inject side effect carefully

    • side effectが増えると、測定が難しくなる
      • どこが変わるとどこが変わるかがわかりづらくなる
    • side effectは本当に必要な時だけ入れる
  • Avoid chaos

    • Immutability + schedulers
      • .onScheduler(MainScheduler)

スポンサードリンク