RxSwiftを“チーム開発に”導入する話
•
5 likes•5,344 views
RxSwiftを“チーム開発に”導入する話/髙橋祐記 (ukitaka) LINE Developer Meetup in Fukuoka #18 https://line.connpass.com/event/60580/
More Related Content
What's hot
What's hot (20)
Similar to RxSwiftを“チーム開発に”導入する話
Similar to RxSwiftを“チーム開発に”導入する話 (20)
More from LINE Corporation
More from LINE Corporation (20)
Recently uploaded
Recently uploaded (15)
RxSwiftを“チーム開発に”導入する話
- 2. ⾃⼰紹介 ⾼橋 祐記 LINE Fukuoka 株式会社 開発2チーム 所属 YUKI TAKAHASHI
- 3. 今⽇話すこと ・ RxSwiftをなぜ導⼊したか ・ RxSwiftをチームにどう導⼊したか ・ RxSwiftを適⽤したところ ・ RxSwiftを使った感想
- 9. なぜRxSwiftを導⼊したか • いままで別々の⼿法を使って実現していたが、 RxSwiftのObservableと呼ばれる型の⾼い表現⼒によってこれらを 統⼀的に扱える！！というのがモチベーション
- 11. Rx以前の⾮同期処理
- 13. Rx以前の⾮同期処理 (1)
- 14. Rx以前の⾮同期処理 (1)
- 15. • シンプルなAPI • コールバック地獄 • 統⼀されないエラー処理 Rx以前の⾮同期処理 (1)
- 16. • Future / Promise 系のライブラリ ・Bolts-Swift ・SwiftTask ・BrightFutures ← 推し ・などなど… Rx以前の⾮同期処理 (2)
- 17. Rx以前の⾮同期処理 (2)
- 18. Rx以前の⾮同期処理 (2)
- 19. • flatMapのようなAPIでモナディックに合成可能。 コールバック地獄にならない。 • エラーのハンドリング⽅法も統⼀できる • Futureは1つの計算結果を表す Rx以前の⾮同期処理 (2)
- 20. • シンプルなAPIリクエスト ・1リクエスト : 1レスポンス ・(Request) -> Future<Response, Error> Future / Promiseでも表現できたもの
- 21. • アニメーション ・() -> Future<Void, Error> のように表しておけば、 アニメーションの合成も簡単 Future / Promiseでも表現できたもの
- 22. • ユーザーの⼊⼒、UIイベント • 通知など (NSNotificationCenter, …) Future / Promiseで表現できなかったもの
- 23. • ユーザーの⼊⼒、UIイベント • 通知など (NSNotificationCenter, …) Future / Promiseで表現できなかったもの つまり、Future/Promiseだと 複数の値や結果を扱うことができなかった
- 24. Rx以前のMVVM
- 26. • SwiftBondなどのライブラリ • シンプルなオブザーバーパターン • KVO Rx以前のMVVM(データバインディング)
- 28. RxSwiftを導⼊する
- 31. RxSwiftをチームへ導⼊する
- 32. • パラダイムも全然違う • FRP以前にFPへの理解も必要 • 必要性をわかってもらうのも⼤変 – Delegateじゃなんでダメなんだっけ？ – target / actionじゃなんでダメなんだっけ？ Rxは学習コスト⾼め
- 34. • やったことは以下くらい ・できるメンバーがまず書いてみて参考にしてもらいつつ、レビュ ーやペアプログラミングなどでサポート ・ちょうどRxSwift本が出たのでオススメした • やればよかったこと ・布教活動、勉強会 ・Observableを⾃作してみてもらう ← オススメ Rxは学習コスト⾼め
- 35. • 概念的なところ • 各種オペレーター • エラーハンドリング • スレッド 特に難しそうと感じたところ
- 36. • Next / Error / Completed ・特にCompletedが⻤⾨ ・理解していないと、すぐ動かなくなったりメモリリークしたりす る ・take(1) 警察 概念的なところ
- 37. • Hot / Cold – shareReplay(1)の必要性など 概念的なところ
- 39. • flatMap / flatMapFirst / flatMapLatest ・⼀番使うオペレータだけど、⼀番ややこしい(と思う) • ambなど、マイナー(？)なオペレータもがっつり利⽤ 各種オペレーター
- 40. • RxMarblesなどのサイト • 公式ドキュメント • 実装読む ← オススメ – もっと⾔えば、実装が読めるようになるためのサポートがある とよいかも 各種オペレーター
- 42. • catchError / catchErrorJustReturn • retry / retryWhen ・「subscribeからやり直す」 ・retryWhenは個⼈的最難関operator エラー処理
- 43. • これは賛否分かれると思うので個⼈的意⾒にとどめておきますが、ハ ンドリングすべきエラーはResultやEitherと組み合わせて Obsevable<Result<T, Error>>としてNextで流す⽅が全体の処理 はシンプルになるかと思います。 • RxのExampleでもそうしているところがあります。 エラー処理
- 45. RxSwiftを使ったところ
- 46. • APIのリクエストは以下のように表現できる。 – (Request) -> Observable<Response> RxSwiftでの⾮同期処理
- 47. • たとえばRepositoryのようなクラス • A -> Observable<Model>のように作っておけばAPIから取って来 るのか、Realmから読むのかなどを気にする必要がない RxSwiftでの⾮同期処理
- 48. • ユーザーの⼊⼒イベント ・button.rx.tap • ViewModel -> View ・viewModel.bind(to: view) RxSwiftとUI
- 49. • Alertや⼊⼒系のViewController ・画⾯を表⽰して、⼊⼒された結果を返す ・今回のアプリでは画⾯遷移を含め A -> Observable<B>の形で 表現 ・記述量はとても少なくなる！ • が実装が複雑なのでメンテコスト有 RxSwiftとUI
- 50. • TableView / CollectionViewにはRxDataSourcesを活⽤ • Modelの配列 → Cell⽤のViewModelの配列 → RxDataSourcesを使 ってbindする RxSwiftとUI
- 51. • バリデーション ・Input ->Observable<Bool> みたいなイメージ ・複数のチェックを⾛らせる場合もmergeやreduceでいける RxSwiftとUI
- 52. RxSwiftを使った感想
- 53. • チームが⾃分⼀⼈だったら絶対に使うくらい素晴らしいライブラリ • 便利だし、楽に書けることも多いけれど… • チームに導⼊するハードルはなかなか⾼い RxSwiftは素晴らしいけれど…
- 54. • 便利ではあるし、RxSwiftで統⼀できるというメリットはあるが、な くてもだいたいのことはできる • 慣れの問題でもあるが、モナドのための構⽂がないSwiftでは可読性 は下がる • 正しく安全に使わないとすぐにメモリリークしたり、動かなくなった りする まず、本当に必要かどうか考える
- 57. Thank you.