RxSwiftをさらに学習するための技術系同人誌「RxSwift研究読本4」を4月にリリースしました

y.imajo
12 min readApr 28, 2020

2020年4月に技術系同人誌の電子書籍「RxSwift研究読本4 自作して理解するリアクティブプログラミングフレームワーク編」をリリースしました。

RxSwift研究読本シリーズ

RxSwift研究読本シリーズとして4作目です。BOOTHではPDF/EPUBセット版の他、無料サンプル版もダウンロードできるので購入前にお試しください。

今回は、RxSwift研究読本がどのような方に向けて書いたものなのか、どのような内容が書いているのかという話をここに書いておきます。

新作: RxSwift研究読本4の概要

RxSwift研究読本4はより深くリアクティブプログラミングフレームワークについて理解するため、最小限の機能しかないRxSwiftクローンを作る過程を解説します。

ということでRxSwiftっぽい何かを作る過程をテストコードを交えて解説していく内容です。RxSwiftを使う上では、RxSwiftのコードを読むことは避けては通れないのですが、結構複雑な処理もあるので読みづらいはずです。最低限のことだけ知りたくても様々な知識を必要とするはずです。そのため、最低限作っていくという過程だけを見てその大雑把な輪郭を掴めれば、Hot変換さえも何が起こっているのかがわかるはずです。

そしてこの内容は、2019年のiOSDCというカンファレンスで発表した内容を書籍にしたものです。

カンファレンスの様子は次の記事にしてます。
http://curiosity.co.jp/iosdc2019jisaku/

話がややこしくなるのですが、本来はカンファレンスの前にRxSwift研究読本のシリーズ最新作として書籍化しようと準備していた内容をカンファレンスで先に話すことになったというわけです。カンファレンスが終わって燃え尽きていたことでこの内容の書籍化が遅れていたわけです。

その間に色々あってVIPER研究読本を書いたりもしていました。

最近のRxSwift事情とRxSwift研究読本のターゲット読者

WWDC2019でiOS13以降で使えるSwiftUI+Combineが発表され、新規のアプリでRxSwiftを導入するケースは少なくなったと思います。しかし2016年から一気に広がったRxSwiftの既存コードは様々なプロジェクトで使われていることでしょう。我々はまだまだRxSwiftと付き合う必要があるわけです。

そのような既存コードと付き合っていく際、メンバーに「これ読んでおいて」と紹介できる基礎を固める内容を目指して書いています。さらにRxSwiftで必要になるViewModelの設計についても紹介しています。これはRxSwiftを使ってもViewModelをきちんと設計しないとカオスな設計となってしまうものをいくつも見てきたからです。RxはPromiseのような非同期イベントの代替として使ってはいけないのです。そのように利用することは学習コストがかさみ、カオスな設計が負債となって残るはずです。

RxSwift研究読本の想定する読者は「RxSwiftを使っているがリアクティブプログラミングというジャンルに入門し、さらにうまく使いたい人」を想定としています。まったくRxSwift自体を知らない人には本シリーズは難しい内容かもしれません。しかし、まったくRxSwiftを知らない人にとって良いRxSwiftの本なんていうのは存在していない気もします。

整理すると、次のような方々をターゲットしています

  • RxSwiftを使っているがリアクティブプログラミングというジャンルに入門し、さらにうまく使いたい人
  • 既存のプロジェクトを改善したい人
  • メンバー間でコンセンサスを取りたい人

そもそもRxSwiftを知るためには

全くRxSwiftを知らない人が何を参考にすればよいのかというと、ReactiveXのサイトにはドキュメントのリンク集があります。

そのなかで公式のチュートリアルもあります。

Functional Programming in Javascript

これはRxの根本となる考え方を学ぶためにmapやfilterを自作していくという内容となっており、かなり勉強になりますがJSでブラウザで入力していくタイプです。iOSではないし、初っ端これから手を出すには向いてないでしょうね。

上記のリンク集にはないですが、RxSwiftの概要を抑えたいなら下記のカンファレンス動画が良いでしょう。

SwiftConf ‘18 – Shai Mishali: RxSwift: debunking the myth of hard

動画の中で、disposeBagに使われている画像の表現見たことあるぞ、と思った人は正解です。RxSwift研究読本1でもかなり参考にした動画です。

なぜRxSwift研究読本が必要なのか

Rxは先程述べたリンク集のように公式が用意してくれる情報だけでもかなり膨大です。とにかく、このリアクティブプログラミングのための流儀を理解するためには様々な説明が必要なんですよね。リアクティブプログラミングといいつつ、関数型プログラミングの要素もあるので様々な角度から見た説明が必要になるわけです。同じことを表現を変えて繰り返す必要があるでしょう。

そうしないとRxSwiftで可読性低いコードも書くことが出来ます。そうしてしまうと本当に読みづらいコードになってしまって本末転倒です。

ここで読者の方のツイートを紹介します。

ツイート内容から勝手に察するに、RxSwiftをプロジェクトで取り入れて可読性が大変になっていたパターンなのではないかと思います。

他にはRxをさらに知るためにテストコードを絶対書くようにしているので、読んでくれた方に伝わっていて報われた感じです。

テストコード書かずにRxSwift使おうとするのは本当にやばくておすすめできないですよね。たいていそういう場合、たまたま期待通りの動きになっているだけです。

RxSwift研究読本シリーズについてのおさらい

RxSwift研究読本1

  • RxSwiftを勉強したてのころに疑問になる内容に注力
  • RxSwiftで関数型プログラミング(参照透過性、純粋関数)を意識するとなぜ役に立つのか
  • 公式のサンプルプロジェクト、RxExamplesのViewModelを徹底的に解説

RxSwift公式のサンプルプロジェクトRxExamplesはGitHubログイン等を実装してるのですが本当に見たほうがいいです。初学者はこれをベースとしてカスタマイズしていくことが一番良いと思います。

こういう生きたコードを読んでいって、「RxSwiftが分からない」という抽象的な言葉から、「combineLatestのオペレータがわからない」など具体的な疑問に変わるはずです。

RxSwift研究読本2

  • エラーが起こったらどうなるか解説
  • エラーをハンドリングする基礎的なオペレータを紹介
  • 実践的にどのようにハンドリングするかを解説

RxSwift研究読本2はRxSwiftのようなリアクティブプログラミングにおけるエラーについての特殊な知識の準備なので、知っていれば必要がないかもしれませんし、おさらいとして読むのも良いかもしれません。

RxSwift研究読本3

  • 何も考えないViewModelは何が悪いのかを説明
  • 複数のViewModelを紹介

おそらくプロジェクトでRxSwiftが読みづらくなってしまうのは、ViewModelの設計で可読性を考えていないためです。ViewModelがModelとなってしまっていたり、入力と出力の見分けがつかなかったり、作用と副作用の分離を意識していなかったりするのではないでしょうか。

これはそもそも関数型プログラミングを基礎として知っていなければいけません。なので、RxSwift研究読本1の内容とRxSwift研究読本2のエラーハンドリングの知識を前提としています。その上で、世の中のViewModel設計の良さを紹介する内容となっています。

その他、RxSwift研究読本3を参考にしていただいた例は次の記事になります。

RxSwiftでUXを考慮した(Gmailアプリライクな)詳細画面を実装する
https://qiita.com/yoko-yan/items/205b5e8777da0ccffdfd

SwiftUI時代にCombineは必要なの?

完全に蛇足ですが、Combineについても今思っていることを書いておきます。

SwiftUI時代にCombineを理解することが必須かどうかでいうと、きっと必須ではないでしょう。SwiftUIの@ObservedObjectは変化をSwiftUIに伝えてくれる仕組みで、そのタイミングでViewを更新します。それさえあればCombineのオペレータでストリームを合成しなくてもなんとでもなると思います。

RxCocoaの仕組みのようにユーザイベントをストリームにしてくれる仕組みはSwiftUIにはありませんし将来的にApple公式でもやらないでしょう。

テストの書きやすさ/読みやすさで言うと、RxSwiftではテストがRxTestやRxBlockingがあり、イベントを発生させる時間に応じたテストが書きやすくなっています。そのため、Combineでテストを書くのは少しかったるい気がします。そもそもXCTestでもwaitする仕組みがあるので、RxBlockingについてはそこまで必要ではないかもしれませんが、RxTestがないとテストの表現力が落ちる気がします。

つまり、SwiftUIになったとしてもあんまり無理してリアクティブプログラミングをする必要はないと思います。ただ、リアクティブプログラミングでユーザ入力を捌いていく処理が楽になったり、ViewModelの設計を固めてテストコードを書いていくというのはアプリ開発の品質向上には繋がるはずです。

スペシャルサンクス

RxSwift硏究読本シリーズはTwitterなどでレビューして頂ける方を募集していました。より丁寧な記述になっている箇所は下記の方々の指摘を受けて補強されました。感謝です。

以下敬称略 —

  • tamadon3776
  • yuta24
  • kitwtnb
  • yukin_557188
  • takesek
  • kazu0620
  • k191k
  • hirothings
  • akeome
  • shmdevelop
  • sugoi_wada
  • KUROSAKI Ryota

特にRxSwift研究読本4では第一章と第二章を一般公開してフィードバックをコメントしてもらえるようにしてみました。最初はそんなやり方をすることが怖かったんですが、完成が楽しみという意見をもらったのがとても励みになりました。次回Combine研究読本などをやる場合には早めに同じようなやり方をしてみたいと思っています

--

--