りあクト！

　技術同人誌のりあクト！、【Ⅱ. React基礎編】の読書記録と感想です。

• りあクト！
• 【Ⅱ. React基礎編】
• 第5章　JSX で UI を表現する
• 第6章　Linter とフォーマッタでコード美人に
• 第7章　React をめぐるフロントエンドの歴史
• 第8章　何はなくともコンポーネント
• 第9章　Hooks、関数コンポーネントの合体強化パーツ
• まとめ：IIでディープにReact入門できる書
  • 関係書籍など

oukayuka.booth.pm

【Ⅱ. React基礎編】

第5章　JSX で UI を表現する

　5-1. なぜ React は JSX を使うのか

　表面的には「JSXキモい」とか言われがちでもあるこのあたりの本質が、本章でしっかり解説されています。

JSX の本質を理解する：
Rails思想が根本にある秋谷さんはERB(Embedded Ruby)のようなテンプレート言語を連想するが、これは誤り。JSXはTypeScript的にはReact専用の型のオブジェクトを作るための式で、「JavScriptの拡張リテラル」が近い。だから変数に入れたり関数に渡したり様々な操作ができる。

なぜ見た目とロジックを混在させるのか：
伝統的なMVCアーキテクチャでの関心の分離は、「技術」の役割でレイヤーを分けている。しかしフロントエンドで適切なのは「機能」での分離なのが徐々に分かり、機能単位で分割された細かなコンポーネントでそれぞれの仕事をするスタイルがReactの設計思想になった。ゆえに、ひとつの小さなコンポーネント内でロジックとレンダリングを無理やり分割すると非効率になるというのがReactの考え。

なぜ React はテンプレートを使わないのか：
HTMLテンプレート派がAngular,Vue.js。ReactはあくまでJavaScriptの純粋な式で解決しており、JSファースト派。HTMLに固執せず単にブラウザが今回のプラットフォームなだけで、一貫した言語で開発する。

• HTMLテンプレートは簡単なアプリでは最初は便利だが、複雑になってくると独自の制御構文など覚えることがどんどん多くなる。Reactは覚えるべき独自の決まりは実は少なく、JavaScriptの高い表現力を活かせる。
• コンポーネントが大きくなると、テンプレートとロジックが分けられているとリファクタリングが難しくなり肥大化の傾向がある。Reactの方が機能で細分化しやすい。
• テンプレートの仕組みを挟むとコンパイルが入ってエラーが分かりづらい。Reactは純粋なJSのエラーしか出ない。
• JSXはあくまでJavaScriptの式なので、開発時にLint系などツールのサポートが受けやすい。テンプレートを使うと型チェックが難しく苦戦してきた。
• フレームワークがその言語で作られていることとその言語で開発しやすいかはまた別の話。TypeScript製のAngularより、JSXを使うReactはTypeScriptと親和性が高く開発しやすい。
• JSXは実はReact専用ではなく他でも独立して使えるライブラリであり、TypeScriptが最初から手厚くサポートしていたのも大きい。

なぜ React は View をタグツリーで表現するのか：

• 様々なFWやライブラリで他の書き方も様々に実現されているが、結局コード上で見る時は、囲みタグ形式の方が人間の視認性からは優れている。
• React本体から分離されたレンダラーはよく使うReact DOMがHTMLのレンダリング担当。スマホアプリ向けの有名なReact Nativeを始めレンダラーはほかにもいろいろ開発が続いており、JSXは最初から様々な用途を見据えて汎用的に考えていたから。

　自分はフロントエンドに入門してからAngular/React/Vue.jsとも本を読んだり実際に作ってみたり色々してきましたが、現在の知識からすると本章の説明がなるほど……!と腑に落ちました。
　JSXでの({({ みたいになる独特の書き方は最初黒魔術に見えるのですが慣れてくるとまあ書けるようになるし、言われてみるとテンプレートがない分Reactは実はディレクティブの書き方とか独自ルールは少ないし、JavaScript自体のパワーを活かすコードになります。前に試しに作ってみた時もReactだとコンポーネントを分割していくリファクタリングはけっこうスッと行けるんですよね……なるほどなるほど。

　Vue.jsが特徴として掲げているProgressive Frameworkの思想をパイセンが「物は言いようだよね」と評していたり、おっこれは宗教戦争勃発不可避!?的なところもあります。本書の作者さんはReact推進派ですのでそれを踏まえつつ読む必要がありますが、それを差し引いてもReactの本質に迫った、非常に役立つ章でした。Qiitaにもこの話が載っています。

qiita.com

　5-2. JSX の書き方

• TypeScript4.1以降はReact17.0以降の新しいJSX変換方式に対応しているので、tsconfig.jsonがデフォルトのままならコードのimport React from 'react'; は実は省略してよいとのこと。これは全く知りませんでした……!
• JSXは自分が式なのでその中に式も埋め込める。null, undefined, true, false は出力なしになる。なので&&演算子のショートサーキットや三項演算子を表示表示の切り替えによく使う……と順序だてて説明してくれてありがたい。
• 親コンポーネントから子供にPropsに定義されていない値が渡ると暗黙のpropsとして扱われる話も知りませんでした……!
• 小文字始まりのHTMLタグを書くとReact内では組み込みコンポ―ネントと扱われ、TypeScriptでは全タグ分がinterfaceとして定義されて処理してされていく話も仕組みを交えながら解説されています。
• 属性のchecked, disabled, selected はReactでは文字列型でなくBoolean型として扱われるのもちゃんとは知りませんでした。
• textareaとselectもvalue属性を持てるのも知らなかった……!
• 細かいネタでは守備範囲の広い秋谷香苗さん、ベネチアっぽい火星で女の子が舟を漕ぐ『ARIA』も好きらしいのが判明します。

ariacompany.net

第6章　Linter とフォーマッタでコード美人に

　6-1. ESLint

• 静的構文チェッカーのlint、語源は乾燥機の糸くずフィルターでUNIXコマンドからだったという小噺が面白い。
• 2008年のオライリー本『JavaScript: The Good Parts』の作者さんがJSLintという最初のツールを作成。
  その後→JSHint→ESLint→JSCS→TypeScript用には一度TSLintが作られたが非推奨になってESLintに統合→現在はこのESLintの一強、という歴史的経緯の話もしてくれるのがありがたい。
• フレームワークのAngularはまだTSLintからESLintに完全に移行できていないのですね。
• そしてCreate React Appでプロジェクトを作ると最初から入っているESLintをベースに、設定フィルの.eslintrc.jsをコマンドから作成、ルールをカスタマイズ、関連するプラグインをインストール……でかなりしっかり設定していく方法が解説されています。大規模なチームの開発標準策定には大きな助けになることでしょう。
• 一方、個人でちょっと触るレベルでここまでやるのはけっこう重いなあという印象です。

#"http://d.hatena.ne.jp/keyword/Douglas%20Crockford">Douglas Crockford

オライリージャパン

Amazon

　6-2. Prettier

• ESLintもコードフォーマッターぽい機能を持っているのがややこしいですが、別にあるコードフォーマッターツールの代表格Prettier。こちらも誕生当時からReactのJSX変換機能と縁があり、他の言語までカバーを広げてフロントエンド全般を網羅するようになった...という歴史的経緯も解説されていてありがたい。
• スタイルを巡る不毛な議論をやめさせて、みんな同じフォーマットにさせるという思想が面白いですね。
• prettierの他にeslint-config-prettierをインストール、設定ファイルeslintrc.jsを変更、package.jsonに設定追加してコマンドから実行できるように、VSCodeの設定settings.jsonも変えて……とコード保存時に一括整形する方法がかなり細かく解説されています。

prettier.io

　6-3. stylelint

• ESLintのCSS版的なstylelintの設定方法。これは存在自体を知りませんでした。

www.webprofessional.jp

　6-4. さらに進んだ設定

• より細かな設定、Gitへのコミット時にチェックを走らせる方法も解説されています。

第7章　React をめぐるフロントエンドの歴史

　7-1. React 登場前夜

• フロントエンド元年と呼ばれる2005年から始まる歴史の話。2005年のGoogle Map、Ajax登場、最初のフレームワークのprototype.js、2006年のjQuery、2008年のHTML5ドラフト公開、かつては一世を風靡したFLASHも2011年開発中止。ECMAScript仕様のES5が2009年。
• いやはや懐かしい。回顧ネタですが自分もFLASHムービーとかよく作ってました……本書の秋谷さんはFLASHアニメで育った世代のようです。
• そしてフロントエンド第2世代と呼んでいるのが2010年代前半、MVCアーキテクチャをクライアントサイドにも適用したBackbone.js,Knockout,AngualarJS(バージョン1のほう)で当時3大フレームワークと呼ばれていたんですね。KnockoutがM-V-VMアーキテクチャを使っていて実はVue.jsの先祖にあたるという話も面白い。
• バージョン2のAngularが名前も変えて後方互換性を捨ててアーキテクチャも全面入れ替えしたのは有名な話ですが、大規模SPAでの性能的な限界が主だった……という話も詳しく載っています。そして2013年にいよいよReact登場。

　7-2. Web Components が夢見たもの

• 2011年頃に新しいWeb標準として構想された、開発者がカスタムでタグを作って中を実装できるWeb Componentの考えの話。良い構想だったもののブラウザベンダー同士の合意などで難航して結局主要ブラウザ実装が2018年頃とかなり時間がかかってしまった。
• その間にReactがこの考え方をUIライブラリの実装で実現して進化させてきたReactコンポーネントが、結局はWeb Componentと似たようなものになっていた...という歴史の話がとても興味深いです。

　7-3. React の誕生

• 最初はFacebookの内部向けフレームワークや個人プロジェクトから始まり、プロトタイプ最初はFBoltという名前だったけど同僚とネーミングを相談してReactになったという裏話が面白い。
• 2020年代に我々が今見ている公式サイトや関連ライブラリの名前、コマンド、日本語で声で発音する時のワードも「エフボルト」とか「フボルト」だったかもしれないという訳ですね……えふぼると……ふぼると……。確かに「リアクト」の方がなんとなくかっこいいですね……
• Facebookは内部でPHPをカスタマイズしたHackという言語を使っているという話は、FBが有名になったころよく聞きました。PHPでもHackでも両方使えるのでしょうか、コード内でXMLを書けるXHPという内部向けフレームワークがあり、これをJS版にしたものが実はJSXのネーミングの元になったという話も面白い。
• そしてInstagramを買収した時にインスタのUIもReactで作り直したのがReactオープンソース化のきっかけになり、React公式サイトやロゴもInstagramのデザイナーの人が作ったという話もめっさ面白い。
  自分はAngularもVue.jsもReactもロゴみんなかっこいいと思いますが、黒地に青で核反応のあのアイコンにこんな裏話があったとは。最初からインスタ映えするデザインだったわけですね！(嘘)

　7-4. React を読み解く 6 つのキーワード

トップに３つ掲げられてきたキーワードも不変でなく実は入れ替わりがあるという話自体が面白いですが、それぞれを深掘りしています。

Declarative（宣言的）：
関数型プログラミングとも繋がる、最終的な出力や状態をHTMLに宣言しておけば中のデータ変更はReactが上手くやってくれるスタイル。
構想段階から関数型プログラミング指向があったがReact最初はクラスコンポーネントしかなかったため一旦はキーワードから取下げられ、関数コンポーネントが追いついてきてから復活した模様。

Component-Based、Just The UI(コンポーネントベースでUIしかない)：
過去のフロントエンド史での様々な挑戦から、MVCをそのまま持ってくるのは良い設計でないのが分かったため。MVCアーキテクチャでいうとVだけしか扱わない。Controller層やModel層に当たるものはない。
またUIだけで状態管理や様々な機能は外出しにしている。Facebook製のライブラリは敗れて、ReduxやTypeScriptなどFacebook外で作られた技術がデファクトになって取り込まれたりした経緯が、実はReactを強くしていった理由になっている。

Virtual DOM（仮想DOM）：
各FWの中で様々なアイデアが試行錯誤されてきたが、メモリ上で差分だけ更新していく仮想DOMの考えが画期的だった。なお単純なレンダリングの速度だけの話ではなく、独自技術で進んでいるAngularも今はパフォーマンスはほぼ同等になっている。

One-Way Dataflow（単方向データフロー）：
制御ロジックの値<->view上の値が同時に反映される「双方向データバインディング」は直感的でもあり多くのFWで採用された。しかし親子コンポーネントを大量に使う複雑化した大規模なSPAではこれが逆に問題になると考え、Reatは単方向データフローを採用。
常に親から子へpropsが流れていく。コード量は増えるがコンポーネントの独立性が保て、またReactの当初の構想からある関数型プログラミング指向とマッチ。

Learn Once, Write Anywhere (一度習えばどんなプラットフォームでも開発できる)：
React本体と分離されているレンダラー部分はブラウザで動かす仮想DOMならreact-domだが、他のプラットフォームにも差し替え可能。モバイル開発のReact Nativeが代表。これらでもReactの知識が活かせる。同種ではAngularをベースにしたIonic Frameworkがあるが勢いでは負けている。またReact NativeのVue.js版であったWeexは開発が止まってしまった。

　本書ではモバイル開発もReact Nativeが一番よ！的な記述になっていますが、2021年現在ではGoogle発のFlutterもいよいよv2が出て勢いを増していますね。
また、この"Learn Once, Write Anywhere "キャッチフレーズがJavaの"Write once, run anywhere"のもじりであるのは有名な小噺ですが、作中の秋谷さんがこれを知らないのに世代の差を感じました……(Java世代おぢさんの悲しみｗ

　7-5. 他のフレームワークとの比較

第3世代のフレームワーク情勢としては、主要な３つの後のものに技術的な目新しい革新はないとして、Ember.js、Preact、LitElement、Svelteが登場しています。

Angular：
v2の大幅刷新で多くのユーザー離反を招いてしまった。フルスタックなのでコンポーネントを作るのも色々大変。実装もTypeScriptだが、特定バージョンに固定されてしまっていたりする。公式が提供するものを使えばよいので頻繁な変化に追随しなくてよい安心感はある。保守性も高い。

angular.jp

Vue.js：
ネーミングはviewのフランス語のvueから。(これは知りませんでした!)
Angularを使っていたGoogleエンジニアのEvan Youさんが不満点を感じて作ったのが始まり。中国圏から熱烈な支持。今までのFWのよいところを取り入れているがHTMLテンプレートの制約を引きずっている。サーバーサイドがメインの考え方を保っている人向け。大規模開発には向かないが分業はやりやすい。後発のSvelteが軽量級としてはその立場を脅かしている。

jp.vuejs.org

LitElement、そして Web Components：
Polymerの後継として切り出されたのがLitElement。紆余曲折いろいろあるが、Web Componentsという技術自体は残っていくと思われる。
フロントを機能ごとに分割、別々のFWで作っても一緒に動かせるような「マイクロフロントエンド」という考え方が実現すれば使えるかもしれない。

lit-element.polymer-project.org

このへんも割と主張が強く、特定のFW推しの熱心な人からしたら「戦じゃぁ……」となりそうなぐらいAngularやVue.jsをけっこう批判していたり、なかなか刺激に満ちています。(笑)
React推しの立場からの本であることは踏まえる必要があるかと思いますが、差し引いてもこうしたReact前夜やフロントエンドの歴史の経緯の話はすごく面白い。とても学びになる章です。

第8章　何はなくともコンポーネント

　8-1.コンポーネントのメンタルモデル

• コンポーネント：propsが引数でReact Elementsを戻り値で返すJSの関数のようなもの。しかしクロージャの技を使って関数なのに状態が持てる。これがstate。propsとstateどちらかが変わったら再レンダリングされる。戻り値のReact Elementsが変わったらその子要素、孫要素も順番に連鎖して変更されていく。
• ゲームの「ぷよぷよ」の多段の連鎖のようなイメージ……と解説されています。あ～確かに。テトリスなどの落ちゲーでもいいですが、これは確かに連想しやすいかも。

　8-2.コンポーネントと Props

• できる限りコンポーネントは純粋関数に近い方がよいので、stateは少ない方が良くpropsの方が重要。2015年10月のv0.14でStateless Functional Component(SFC)登場、その後名称がFunction Component(FC)になり、2019年2月のv16.8では関数コンポーネントが正式に推奨、React Hooksも公式推奨に……となります。
• 実際の例としてSemantic UIを入れた一覧表示画面で、今度は『SLAM DUNK』の面々一覧表示を題材にしています。スラダンはメジャーなので世代問わず知っていそうですね。
• FCの他にVFCという型もあるのは初めて知りました。紹介されている『React TypeScript Cheatsheets』というサイトがめっちゃ役に立ちそうです。自分もJSXやイベントの型とかけっこう悩みました……くっこのサイトを知っていれば……

react-typescript-cheatsheet.netlify.app

• 関数コンポーネントだとアロー関数形式で一文ならreturnを省略できるので、return( )なしで直接JSXを書いても通るんですね。?? の構文を利用した省略法含め、モダンなReactの書き方はだいぶスッキリしている印象です。

　8-3. クラスコンポーネントで学ぶ State

• オブジェクト指向の考え方でクラスは基本ですがJavaScriptとReactの世界ではまた事情が違い、公式で『クラスは人間と機械の両方を混乱させる』とあるようにReactの思想では関数コンポーネントを推奨している理由の話。

ja.reactjs.org

• とはいえクラスコンポーネントもまだまだ使われているので、前節のスラダン一覧表示を例にTypeScriptでクラスコンポーネントで書いた例を解説してくれています。対比がありがたいです。
• クラスで書いた場合のrender()メソッドの戻り値がReactElement型になってるのですが、JSX.Element型とどっちが良いのでしょうか……？

　8-4.コンポーネントのライフサイクル

• このへんはサーバーサイドの各種フレームワークでもよく出てくるところ。TypeScript版で引数、戻り値を表で整理しています。
• 今後廃止されるライフサイクルとしてcomponentWillMount,componentWillReceiveProps,componentWillUpdate があるとのこと。進化が速いフレームワークはこのへんが怖いですね……古いReactの本だと思いっきり載ってそうです。

　8-5. Presentational Component と Container Component

• 表現に関するコンポーネント=Presetational Component
• ロジックや状態や表現コンポ―ネントを持つコンテナの役割のコンポーネント=Container Component
• この2種類に分けると良い設計になるというReact特有のデザインパターンの話。
• 表が載っていて言いたいことはよく分かるのですが、本書の秋谷さんの疑問のように、MVC関係なくJust The UIなんだというReactの基本思想と矛盾してないか？と自分も最初は思いました。

• この考えはReact Hooksを使えば解消できるとして後に撤回されたそうですが、柴崎パイセンの談ではよいコンポーネント設計の観点では常に役立つとのこと。設計の領域は唯一の解のない世界なので両方正しそうでもあります。medium.com

• 公式の「Reactの流儀」にこのPresentational ComponentとContainer Componentを当てはめる考え方が解説されており、ここを読むとちょっと分かってきた気がします。React力の高まりを感じた……！

ja.reactjs.org

第9章　Hooks、関数コンポーネントの合体強化パーツ

　9-1. Hooks に至るまでの物語

　複数コンポーネントで同じロジックを共通化したりする方法。Hooks登場までの歴史的な経緯も解説してくれてありがたいです。

• mixin(ミックスイン)：クラスコンポーネントしかなかった初期のReactで、共通化して注入する方法。mixinというプロパティに、別途定義したクラスを[]付きで書く。一見分かりやすいが依存性があり名前の衝突も起きやすく、アプリケーションが複雑化するとさらに深刻になる。
• HOC(Higher Order Component)：関数を引数に取ったり返したりする高階関数を活用する方法がコミュニティ内で発案、HOCライブラリのRecomposeが作られたりで意識の高い開発者には人気だった。
• Render Props：React Elementを返す関数を受け取り、自分のレンダリングに使う特殊なコンポーネントを使う方法。renderメソッドとはまた別。HOCとRender Propsのどちらがよいか、React公式のコアチーム内や開発コミュニティで意見が分かれて論争があったり諸々。
• そしてRecomposeの作者がReact公式チームに招かれたりして開発が進み、2019年2月に正式にReact Hooksが登場。これまでの課題を安全に解決し、過去の手法は不要になった。
• 設計パターンではなく正式なReactの機能として提供。既存のコンポーネントシステムの中途半端な拡張でなく外側に状態やロジックを持てる。クラスコンポーネントが不要になり、スマートな関数コンポーネントだけで完結する。
• コンポーネントの外側に引っ掛けるから"Hooks"と呼ぶ(らしい)。

　フレームワーク同士の衝突もあったでしょうし、Reactという括りの中でもまた衝突や論争があったわけで、まるで戦国時代のようです。いろんな試行錯誤や苦労や迷走があって現在があるのだな……としみじみ思います。

logmi.jp

　9-2. Hooks で State を扱う

• const [friendList, setFriendList] = useState<Friend[]>([]); のように書くStateの使い方。TypeScriptの場合は<>内に型引数を渡すと型推論してくれる。
• HOCライブラリのRecomposeの作者さんが開発に加わっているので、実はインターフェースが若干似ている。
• よくあるカウンタアップのアプリだと、クラスコンポーネントではthis.state.count は最新の値を常に持っているが、関数コンポーネントでHooksを使う時はレンダリングされるタイミングで一定の値。従って前の値を直接変更しようとsetCount(count) してもうまく動かず、setCount((count) => {count+1}) と引数に無名関数を入れるのが正しい。同じstateという考え方でも内部は違うので注意。

　既存のやり方を知った後アンラーンしてHooksを学び直すのが良いよ、という話で、グランドマスター・ヨーダ様の名言が出てきます。確かにこれから学ぶ初心者から見たらなんだそらって思いますね。こういうところがフロントエンドは厄介ですね……

overreacted.io

　9-3. Hooks で副作用を扱う

• 関数型プログラミングの文脈でよく使われるside-effectの意味で使う。関数コンポーネントなら結果はいつも不変となるが、この結果が変わるような処理を実行するAPI。日本語の「注射の副作用」のようなネガティブな意味とは全く違う。
• useEffect内部の処理で処理に問題がある時はESLintがエラーを出すときがある。公式提供のeslint-plugin-react-hooks にreact-hooks/exhaustive-deps というルールがある。
• ライフサイクルのcomponentDidMount はブラウザへのレンダリング前に行われるが、useEffect だとレンダリング後に処理される。これによってコンテンツのロード前の初期表示処理などが簡単になった。
• クラスコンポ―ネントの内部の変数や関数はずっと生き続けるが、関数コンポーネント内の変数や関数は関数実行でレンダリングされるごとに毎回破棄。State Hookはこの仕組みの外側で保存されているので、レンダリング時は不変の値になり、タイムラグ等のエラーを防げる。
• 従来のライフサイクルメソッドは、例えばcomponentDidMount時に関係するデータ全部の初期処理を入れなければならなかったり、時間的な凝縮度が高かった。useEffectを使うと機能ごとにこれを分けられるので、時間的な凝縮度でなく機能的な凝縮度が高まり、よりよい設計になり再利用もしやすくなる。Reactの思想の「宣言的」になる。

　9-4. Hooks におけるメモ化を理解する

• 関数型プログラミングの文脈の用語で、関数の呼び出し結果や関数そのものをとっておいて高速化する手法。必要な時だけ再計算して結果をメモに残していくから「メモ化」という。Reactの世界でも同じ意味。
• useMemo、useCallbackというAPI。リアルDOMへの参照を残しておくuseRef もある。

　9-5. Custom Hook でロジックを分離・再利用する

• 内部でReact Hooksの機能を使ったロジックを純粋関数として切り出し、ネーミングはsetXxx。サンプルコードではuseTimer。
• <App>から親のcontainer component である<EnhancedTimer> を呼ぶ。EnhancedTimerの中でuseStateのようにしてカスタムフックのuseTimer を呼び出し。戻り値でpropsでこのuseTimerの実行結果を渡しながら<Timer>を指定。
• 子供の<Timer>コンポーネントがpresentational component で、ロジックなしでpropsを受け取って描画するだけ。
• ...というコンポーネント設計にするととても綺麗になるよ、という例が解説されています。確かにこの文脈だとcontainer component/presentational componentの使い分けも理解できるし、良いコンポーネント構成だと分かります。

　「メモ化」ってなんでメモなんだろうとずっと不思議に思っていたのですが、関数型プログラミングの文脈とつながるわけですね…難しいけど学びになる章です。

まとめ：IIでディープにReact入門できる書

この【Ⅱ. React基礎編】がReact入門本体。後半だんだん難しくなっていくのでサンプルコードのお遊びネタも少なくなっていきますが、ディープにReactを知ることができます。ある程度基本が分かった上だとJSXの概念の話も納得がいきます。他のフレームワークの批判のあたりは主張が強いですが、React自体の歴史や裏話もすごく面白い。
　果たして柴埼パイセンと秋谷さんの世代設定の情報は得られるのか、我々はりあクト！のさらに奥地へと向かった......

関係書籍など

本書のサンプルコードのリポジトリ。github.com

頒布時のtogetterまとめ。togetter.com

りあクト！ TypeScriptで始めるつらくないReact開発 第3.1版【Ⅰ. 言語・環境編】oukayuka.booth.pmりあクト！ TypeScriptで始めるつらくないReact開発 第3.1版【Ⅱ. React基礎編】oukayuka.booth.pmりあクト！ TypeScriptで始めるつらくないReact開発 第3.1版【Ⅲ. React応用編】oukayuka.booth.pm

りあクト！ TypeScriptで極める現場のReact開発booth.pmりあクト！ Firebaseで始めるサーバーレスReact開発booth.pm

Reactをはじめとするフロントエンドフレームワークの入門本まとめ記事最新版が、このブログ内のこちらにあります。

iwasiman.hatenablog.com