秋谷さんのビジュアル判明。悪戯好き元気スポーツ少女系でポニテ！(違)
技術同人誌の『りあクト！』３部作を読んだので、続編、追補編にあたる『りあクト！ TypeScriptで極める現場のReact開発』を読みました。
今回もキーワードは「現場」、Reactで綺麗な設計、綺麗なコードを書いて開発していくための各種ライブラリやツール、手法など、React本体を取り巻く周辺情報を押さえた本となっています。今回も本文は２人の会話形式で読みやすいです。
- 秋谷さんのビジュアル判明。悪戯好き元気スポーツ少女系でポニテ！(違)
- 第1章 デバッグをもっと簡単に
- 第2章 コンポーネントのスタイル戦略
- 第3章 スタイルガイドを作る
- 第4章 ユニットテストを書く
- 第5章 E2E テストを自動化する
- 第6章 プロフェッショナル React の流儀
- まとめ：React開発の周辺部分が網羅できる本
第1章 デバッグをもっと簡単に
- 最初はVSCodeの拡張機能
Debugger for Chromeから。実行するとセッションが繋がった別ウィンドウが開き、VSCode内のコードの好きな場所で止めたり変数を確認したりする手順が詳しく解説されています。 - こうしてみると便利そうですね。自分もこの拡張機能入れたんだけど結局いつも
console.log()で済ませていました……!(土下座)
1-2. React Developer Tools を使ったデバッグ
- 今度はChromeの拡張機能の使い方。ちゃんと見ていくとけっこう重要情報をちゃんと可視化してくれているのが分かります。
- 色合いのThemeも変えられるのが面白いですね。柴埼先輩のお気に入りは
Solarized Lightだそうです。 - 今ChromeのDevToolsの実物を見たら、ThemeはSystem preference/Light/Darkの3択に減っていました。バージョンアップしたのでしょうか。
1-3. Redux DevTools を使ったデバッグ
Redux専用のChrome拡張機能も実はあるということで、使い方が詳しく解説されています。非同期処理のRedux Thunkはこのツールと相性が悪く、Sagaの方だとその場で値を書き換えて実行したり便利な使い方ができるとのこと。- そして作中の2人はともにJoJoネタも分かる人なのが判明します……
第2章 コンポーネントのスタイル戦略
2-1. グローバルなCSSとの闘い
- HTMLが巨大な１枚絵だったころは巨大な１つのCSSファイルを弄っていた。そこでコンポーネント指向が生まれ、HTMLの中身も分解され、コンポーネントごとにCSSを解決するアプローチが登場。
CSS in JSと呼ばれる。
- CSS in JSのライブラリが多数生まれた中で有名なのが
CSS Modules。JSファイルをimportするのと同じ感覚で.cssファイルをimportし、<div className={styles.xxx}>のようにJSオブジェクトのようにCSSクラスを指定する。元のコード直書きとそれほどは変わらない。
2-3. 群雄割拠の CSS in JS ライブラリ
- いろいろ登場。
styled-componentsが、const Container = styled.div` (ここにCSS指定) `;のようにCSSを指定、JSXで対象タグを<Container>で囲む形式。 - その後2017-2018頃に登場した
Emotionが全部入りで独り勝ち状態。JSXのタグの中に<div css={css` (ここにCSS指定) `}>のようにCSSが書けたり、やり方が複数ある。
qiita.com emotion.sh tech.recruit-mp.co.jp
2-4. Emotion を UIフレームワークと組み合わせて使う
- JSXのコンパイラを
Emotionの提供するコンパイラに変える必要があり、Reactコンポーネントのコードがちょっと変わる。JSX Pragmaというワードを記述する。 - 親コンポーネントがEmotionを使っていたら子供のコンポーネントも使う必要あり。
- フラグメントが使用不可、空の
divタグが現状必要。 ESLintが余計な警告を出すので、設定追加が必要。
自分はUIデザイナーではないのでCSS周りはあまり気にしていなかったのですが、いろいろあるのだなあという感じ。Emotionのロゴの絵は面白いですね。
第3章 スタイルガイドを作る
3-1. なぜスタイルガイドが必要か
- 昔はHTMLデザインも一枚絵をフォトショでデザインしたり、CSSもデザイナーが用意されていたりで済んでいた。
- しかしJavaScriptが台頭してコンポーネント指向へ、CSSもコンポーネントの中に閉じ込められるようになるとCSSもフロントエンジニアの領分に。今はもうデザイナーはCSSを知らない場合もある。そこでコンポーネント単位のスタイルガイドが必要になってきた。
3-2. スタイルガイド作成ツールの比較
- いろいろあるが群雄割拠ではなく、
Storybookの一強状態。機能が本格的。
3-3. Storybook を使おう
- npmからインストール、
.storybook/というディレクトリを掘ってwebpack.config.jsとconfig.jsを設置、ルート直下のpackage.jsonに設定追加、追加でアドオンもインストール……と一通り手順が示されています。 - するとシャレオツな画面にコンポーネント一覧が表示……という流れ。
Storybookはデザイン寄りの記事で時々見かける割に実体がよく分かっていなかったのですが、デザイナーとエンジニアが複数人いるような、そして大量のコンポーネントを使いまわして画面を作っていくような規模のあるアプリで役に立つのですね。
第4章 ユニットテストを書く
4-1. 私たちは何をテストするべきか
- 何をどこまでテストするかは諸説あると作中でも議論されており、フロントエンドでもこのへん決めるのが難しい所だろうなあと思います。柴埼先輩流の、テストする意味についての考えは以下。
- 設計通りに機能が実現されているか：動かせば分かるのでテストコードの意味が薄い。
- 新規実装部分に破綻がないか：TypeScriptの型安全性である程度確保。
- 既存機能に影響がないか：ここにテストコードの効果あり。
Storybookのスナップショットテストも。 - モジュラリティ(独立性)の確保：
Storybookにスタイルガイドを登録することでコンポーネントの独立性が保てる。
- ここから、ロジック部分はテストコードでテスト。コンポーネント部分は
Styorybookに登録してスナップショットテスト。正常系はテストコードでE2Eテスト。というスタイルをとっているとのことです。
4-2. Jest で APIハンドラをテストする
- テスティングフレームワークも幾つかあるが、
Jestが多機能。Create React Appに内蔵されているreact-scriptsにも統合されておりTypeScriptでも使用可能、React公式で推奨なので事実上デファクト。 - 通信用の
axiosに追加でaxios-mock-adapterインストール、設定ファイル修正、そしてxx.tsに対しxx.spec.tsを書く形でテストコードが解説されています。 - TDD(テスト駆動開発)とフロントエンドはマッチしないのではという話が面白い。確かに狭義のTDDは純粋なロジックのコード以外、Reactコンポーネントに全適用みたいなやり方ははあまりそぐわない気がします。
- ここで柴埼パイセンの考えで、TDDは動的型付け言語と受託開発の文化から生まれたと語っているのはちょっと分からなかったです。(最初は
JUnitでケント・ベック大先生らが作った頃だからJava時代のような……?)
4-3. Redux Saga Test Plan で Saga をまるごとテストする
Redux Sagaを使ったロジックをうまくテストしてくれるライブラリ、柴埼パイセンのお気に入りのRedux Saga Test Planを使ったテストコードの実例が詳しく解説されています。- 秋谷さんがテストコード中で
as anyをしているところをしっかり見つけたりしていますが、やっぱりこのへん使うには幾らか工夫がいるのだなあと。
4-4. StoryShots でスナップショットテスト
- 画面のスクショ画像を撮ったりするのかと思ったらそういう話ではなく、
*.snapファイルにHTML出力を保存したようなテキストファイルが生成されて、比較でテストができるという仕組みなんですね。このアプローチは面白いと思いました。 - 幾つかライブラリを導入、設定ファイル変更、テストコードのファイル追加、
yarn testで実行……と手順が一通り解説されています。Semantec UI Reactのバグの話まで補足と行き届いています。
第5章 E2E テストを自動化する
5-1. E2Eテストツールの比較
本書ではJS界隈の主要E2Eテストツールとして３つが上げられています。
Puppeteer
Chrome DevTools開発チーム謹製のNodeライブラリでブラウザコントロールのAPIを提供。ダウンロード数では圧倒的だがスクレイピングなどにも使われるので、厳密にはE2EテストツールOnlyの物ではない。
Cypress
ダウンロード数2位。iframeは不可だがツールが見やすく、テストの実行速度も速い。テストランナーとアサーション部分が、既存のテストフレームワークMochaとChaiを使っているのでTestCafeよりテストコードが読みやすい。Cypressはイトスギの木で防虫作用があることからつけられたらしい。
TestCafe
ダウンロード数3位。マルチブラウザ対応、スマホ可能、iframeのあるページもテスト可能。
https://testcafe.io/testcafe.io
ということで本書ではCypressをイチオシしています。そして2人は攻殻機動隊ネタも分かる人なのが判明しています。くっ、守備範囲が広い……
5-2. Cypress を導入しよう
- インストール後、
ESLintの設定ファイルに追加と除外設定追加、package.jsonにcypress実行の旨を追加、cypress/ディレクトリが作成されるのでその中にTS用設定追加、このディレクトリに諸々作成……と手順が詳しく解説されています。 - テストコード自体は
Seleniumなどとあまり変わらない感じですが、本書ではテスト対象のHTML要素にはdata-testidというカスタムデータ属性を追加、これを使ってボタンを特定して押したりしています。 - このカスタムデータ属性を使うのがCypress推奨の今のベストプラクティスで、
id属性やclass属性で特定するのは変更に弱いのでもうアンチパターンなのだとのこと。CSS in JSライブラリの大手のEmotionもCSSのclass属性にハッシュ値を付けるので特定できなくなってしまうそうです。 - 今のFacebookのWeb画面では見つからなかったのですが、実際にTwitterのWeb版画面をDev Toolで見てみると、ほんとだ
data-testidがある……!! となりました。 - こういう話は本当にありがたい。Pure JavaScriptで普通に要素を特定したり、
Seleniumを使ったり、コア部分にSelenium WebDriverが入っていることの多いRPAツールなんかでも要素の特定はid属性やname属性でやるのが普通でしたが、もうそういう時代じゃないんですねえ。
第6章 プロフェッショナル React の流儀
6-1. Advanced Thinking in React
柴埼先輩も一読をオススメしているReact公式の「Reactの流儀」。
- Step 1: UI をコンポーネントの階層構造に落とし込む
- Step 2: Reactで静的なバージョンを作成する
- Step 3: UI 状態を表現する必要かつ十分な state を決定する
- Step 4: state をどこに配置するべきなのかを明確にする
- Step 5: 逆方向のデータフローを追加する
これをさらに応用する形で、Reduxを使った複雑なアプリケーションでのプロフェッショナルな設計の考え方を解説しています。Reduxを使う場合はStep5がなくなり、Step4の先でContainer ComponentとPresentational Componentの分け方を検討。ContainerがContainerを呼ぶのは設計上も危険、Propsは最大6個ぐらい、Action発行のところを考えて……という具合。
公式が以前推奨していたのはトップレベルのコンポーネントがデータを持ってReduxと繋げて……でしたがその後より柔軟に変わってきたとあります。
やはりこういう設計のより良いプラクティスの追求は年月と共に移り変わり、唯一絶対の正解がない世界なのだなあと思いました。世の中の皆さんも試行錯誤されているのではと思います。
6-2. Store のスケーリング戦略
- データの種類は同じユーザーなのに無秩序に重複して持ったりしまったりする。TypeScriptなら型を活用して、「
Storeの構造はドメインモデル(=ビジネスや問題解決の対象)である」という原則を守ろうというお話。 - JavaScriptオブジェクトの正規化をしてくれるライブラリの
normalizrを使ってUser型の配列を正規化する例が載っています。キーが生成されたID: {ユーザ1件のJSオブジェクト}に変換されることで特定可能になっており、確かに人間の見た目には分かりにくいですが正規化するとこうなるよなあと。 - フロントエンドでのセッション情報もかつては
Cookieに入れる方法もありましたが今はLocal Storageに保存するのが主流、Redux用のミドルウェアもあるとのこと。
まとめ：React開発の周辺部分が網羅できる本
作者さんのまえがき・あとがきにあるように、3部作で書き残した部分、現場の開発で役に立つ応用的な部分を一通り書いた本でした。相変わらず周辺ライブラリの動静の話などもかなり詳しく参考になります。細かなバグなども回収してサンプルが動くようかなり動作確認されたようで、苦心のほどが伺えます。
それぞれ200Pを超える3部作に比べると100Pほどなので気軽に読めて、1000円とお手軽価格です。3部作を読破したならこちらも一緒に読むと、さらにReactの極めの道を進むことができるでしょう。
エピローグでは2人の親密度がさらに上がって良きになっています。会社の文化にもよると思いますが、職場のパイセンが自分のTwitterアカウントをこっそり把握してたら、確かにビビるでしょうねえ……笑
関係書籍など
本書のサンプルコードのリポジトリ。 github.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
