「りあクト！ TypeScriptで始めるつらくないReact開発」を読んだ

電子版で読みました。

booth.pm

本の情報

項目 情報
ページ数 188P
章数 全10章
著者 @oukayukaさん

全体的な感想

Webフロントエンドのとても良い教科書です。歴史的背景や思想に関してもしっかり触れられているので、これからWebフロントエンドを触る人は必読と言っても過言ではないのでしょうか。研修として使うのにも非常に有用だと思います。

Railsなどのフルスタックなフレームワークでよく使われるテンプレートエンジンを使ったフロントエンドの構築の限界と、その問題へ対処するためにReactを使うという選択肢に関して説明してあります。なお、RubyやRailsとの対比表現が多かったので、Ruby on Railsを使ったことがある人には読みやすいと思います。

こんな人が読むと良さそう

以下に挙げるキーワードに気になるものがある人は買うと楽しめると思います。

  • Reactの思想
  • 仮想DOM、コンポーネント指向、単方向データフロー
  • HCO
  • recompose
  • Redux

この本を買った理由

実は、この本の登場人物である秋谷香苗そのままの理由です。サーバーサイドを主にやっていた私がReactを書くことになり、既知の知識では太刀打ちできなかったためです。

自分の開発経験

普段サーバーサイドを触ることが多い人です。が、最近フロントエンドを触る機会がやたらと増えています。

Reactを書いたことはあって、2016年くらいから1年半くらいBoostnoteというOSSでReactを書いてました。しかし「HOC？なにそれ？」みたいな感じのコードを思いつくままに書いていましたって感じだったので、「要件に沿った動作をするコンポーネントは書けるけど綺麗な設計のコードは書けない」というレベルです。なおここ2年くらいはずっとVue.jsを書いていました。

1章

環境構築の章です。create-react-appを使ってReact + TSの環境を構築しています。

2章

モダンJSの文法の章です。普通にJS書いていたらだいたい知ってると思います。「プロパティ名のショートハンド」は初めて名前を知りました。

3章

高階関数やカリー化など、関数型にまつわるよしなにごとが分かりやすく説明されています。最近普通に書かれているJSのコードもだいぶ関数型っぽいですよね。他にも実際に今やってるプロジェクトではHOC使っていますし。他にも最後の方にステートレスコンポーネントに関しても言及されてました。

関数型言語なんか書きたい気分になってきました。

4章

TypeScriptの章です。まず、RubyやPythonなどの動的型付言語と比較して、型付言語の有用性が説明されています。静的型付言語はVSCodeなどのIDEを使うと便利に補完などをしてくれます。これはvimにはない機能なので、私もVSCodeなどのIDEをいい感じに使いこなしたいと思っておもむろに起動するのですが気づいたらvimでコードを書いています・・・

この章は習うより慣れろな部分が多くて、読むだけではなく実際にTSを書いてみるのが早いです。

5章

Webアプリケーションのフロントエンド層におけるテンプレートエンジンの弱点と、コンポーネントに分割するという手法でこの弱点を克服することに関して説明されています。この章はやたらと熱が籠もっていてとても熱いです。 この章にはWebフロントエンドそのものに関する思想が入っているので、Webフロントエンドを書く人は必読です。この章は繰り返し読もうと思います。

6章

LintとPrettierの紹介です。省略。

7章

ようやくReactの章です。まず最初に仮想DOM、コンポーネント指向、単方向データフローに関する説明が書かれています。このあたりはReactを使うにあたって基礎となるReactそのものの基本思想なのでよく理解しておく必要があると思います。この章の前半は本当に読む価値が高いです。

後半はReactコンポーネントに関する話でpropsやライフサイクルの説明がされています。ここはReactを触ったことがある人ならサクッと読めると思います。最後にはちょこっとStateless Componentにも言及されています。

8章

Presentational Component(コンポーネント)とContainer Component(コンテナ)のお話です。ちなみにコンポーネントとコンテナの概念はもともとは以下の記事で言われていたもので、本文中でも言及されていました。簡単にまとめると、見た目がPresentational Componentで、見た目のためのふるまい(HTTPリクエストとか)を含むのがContainer Componentみたいです。

medium.com

この2つのコンポーネントの作り方に関して簡単に言うと、HOCでContainer Componentを作り、関数コンポーネントでPresentational Componentを作る、ということみたいです。そして本文では

「React らしくて一番きれいなやり方は、関数コンポーネントで Presentational Component を作り、HOC で必要な機能を追加していって Container Componentを作る形だというのが私の考え。交流のある他の開発者の人たちの話を聞いても、意識高くて技術力も高い会社ではそのやり方をやってるみたい」 (P111)

と書かれており、どうやらモダンな(?)Reactを書くための必修事項のようです。

ここでHOCなContainer Componentを作るためにはrecomposeというライブラリを使います。本文中では「Reactの技術書でrecomposeのことに言及している本は少ない」と言われているように、自分も現場のコードを見て初めて存在を知りました。

これらの2つのコンポーネントに関してざっくり言うと「stateを持ちたくないからstateを別のコンポーネントに分けて、かつそのコンポーネントも関数コンポーネントとして書けるようにrecomposeを使う」といった感じでしょうか。ここ辺りはたぶんReactの中でも慣れるのに時間がかかる部分なのでしょうが、きっと諦めずにコードを追い(書き)続けていれば綺麗さに気づく部分のはずだと思っています。

感想: コンポーネントとコンテナに分割すると、Clean Archtectureの分割とちょっと競合する気がするのでうまく乗せにくそうだなと思いました。そもそもReact自体に結構いろんな思想が乗っかっているのでやはりキツいんでしょうか。みんなどうやっているのだろう・・・

実際にrecomposeを使うにあたっては以下の記事を読んでました。

blog.kyanny.me

qiita.com

9章

SPAのルーティングの話です。ここ辺りの話はReactに限らずSPAでWebアプリケーションを構築するときには必須の知識です。歴史的敬意も含めて説明されていてとても分かりやすかったです。

10章

Fluxアーキテクチャの話です。まずMVCアーキテクチャとの対比でFluxの説明がされていました。MVCアーキテクチャには、ViewとModelで双方向に通信すると機能追加を続けた時複雑さが跳ね上がるという問題がありました。これを単方向データフローにして複雑さが跳ね上がることを防ぐのがFluxアーキテクチャです。で、このFacebookが提唱したアーキテクチャの実装において覇権争い`が起こった結果Reduxが勝ったみたいです。

さて出てきましたRedux。慣れが必要で最初は結構難しいReduxも、基本となる思想から実際の使い方まで分かりやすく説明されています。

業務で開発するアプリに、コンポーネントをまたいで共有したいデータがないことなんてまずないから、最初から Redux を入れておいたほうが後からの軌道修正コストもなくていい。 (P179)

そうですよね、「まあ最初は規模も小さいし学習コスト高いから使わなくていっか」ってなりがちですよね。。。やるなら最初からいれねば。

印象に残った文

読んでて思わずメモしてしまった文章です。

  • 「あー、Rubyist は Vim 大好きだからねえ。でもウチでは VisualStudioCode、長いので略して『VSCode』って呼ぶけど、それを使ってもらいます」 (P14)
  • 『オレが…、オレこそが関数型プログラミングだ！』 (P45)
  • Rubyst の人たちは CoffeeScript に振り回された過去があるせいで、AltJS にあまりいいイメージを持ってないのかもしれないね (P48)
  • Web コンポーネントがこの先、実用段階になって普及していけば、React も Vueも Angular もそこに吸収されていく、と主張する人たちもいる (P79)
  • 『Model と View の間に双方向のデータフローが作られるため、新しい機能を追加しようとするたびに、システムの複雑度はが指数関数的に増大し、そのコードは《壊れやすくて予測不能なもの》になってしまう』 (P144)
  • 本当に React って原則を徹底させますよね (P145)
  • フロントエンド、特に React はドキュメントの和訳を待ってると技術の進歩についていけないよ。 (P149)
  • バックボーンを理解していれば書かれたものは読みやすいし、テストやデバッグも容易だけど、自分で一から書くのは難儀する、それが React や Redux だから。 (P162)
  • 業務で開発するアプリに、コンポーネントをまたいで共有したいデータがないことなんてまずないから、最初から Redux を入れておいたほうが後からの軌道修正コストもなくていい。 (P179)
  • 「背景となった歴史やその思想、そしてその技術がもたらすメリットをきちんと理解もできないまま、短絡的に『React も Redux も不要だ、あんなのすぐ廃れる』などと主張する開発者が特に日本には多くて、私はつねづね憤慨しているのですよ」 (P180)

まとめ

技術的な部分の充実はもちろんのこと、本としての体裁も綺麗に整っていてとても良い本でした。大事だと思った部分はしっかり染み付くまで繰り返し読もうと思います。

最近は個人開発でVue.jsを使うことが多かったのですが、これからはReactも使ってみようかなと思います。