RxSwiftを“チーム開発に”導入する話
•
5 likes•5,344 views
RxSwiftを“チーム開発に”導入する話/髙橋祐記 (ukitaka) LINE Developer Meetup in Fukuoka #18 https://line.connpass.com/event/60580/
Recommended
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 (10)
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.