Zenn
Open6

りあクトを読むんだ（TypeScriptで極める現場のReact開発編）

なる💡ideee代表なる💡ideee代表

TypeScriptで極める現場のReact開発

前編があったみたいだが、これから読み始める。
けど、これから読んでも大丈夫そうな内容かな。

デバックをもっと簡単に

知らなかった単語
ボイラープレート:
使い回す前提で用意されたテキスト（文言）の通称

Debugger for Chromeのインストール
This extension is deprecated. が出てきていて困っていた。
けど去年からインストールが不要になっているみたい
https://zenn.dev/chida/articles/a12f72ed8153b0

Redux DevTools
知らなかった Store State を直接書き換えられるのは便利そう！

なる💡ideee代表なる💡ideee代表

コンポーネントスタイル戦略

BEM とか OOCSS とか FLOCSS とか SMACSSが生まれた後に
まず頭ひとつ抜け出したのが CSS Modules

/* style.css */ .common {
font-size: 10px; }
.normal { composes: common; color: green;
}

import styles from "./style.css";
const MyAwesomeComponent = () => (
<div className={styles.normal}>Awesome!</div>
);

<div class="style-normal__227xg">Awesome!</div>

実際のクラス名は<ファイル名>-<クラス名>__<ハッシュ> というフォーマットで自動生成され、末 尾に付与されるランダムなハッシュ値によって一意であることが保証される。だから開発者は何も考えなくても、クラス名をローカルなものとして安心して使うことができる

CSS in JS

単一ファイル型の CSS in JSが人気が出てきているらしいが個人的に好きになれない。

最近のライブラリの比較
https://reactjsexample.com/performance-comparison-of-css-in-js-libraries/

改めての言葉
Semantic UI：
美しいWebサイトを素早くデザインするためのCSSフレームワークです。
BootstrapやMaterializeやBulmaなど

今後使いたいUIフレームワーク
https://mantine.dev/

なる💡ideee代表なる💡ideee代表

スタイルガイドを作る

フロントエンジニアがCSSを触るようになった経緯

  1. スマートフォンのネイティブアプリの普及により、Web アプリも同様に高度な UI・UX を 求められるようになる。
  2. その要求に応えるために JavaScript による SPA が登場、さらにその開発における複雑さを 解決するためにコンポーネント指向が導入されていった。
  3. ロジックと見た目が融合したコンポーネントは、フロントエンドエンジニアにしか手を出 せない。
  4. デザイナーはもっぱら見た目だけを厳密に定義する本来の役割に戻り、CSS はフロントエ ンドエンジニアの領分になる。

Storybook を使おう

Eject：
Rejectとほぼ同じ。npm run eject で create-react-app コマンドでパッケージされた状態を外す。

公式にない情報をの調べ方

まず最初に公式ドキュメント通りにやってみる。
うまくいかなければエラーメッセージで ググって GitHub Issue や Medium の記事や Stack Overflow とかに行き当たる。
困ってる実況中継を Twitter でやってたら、たまに経験者 が教えてくれることもある。
教えてくれる人が見つからなくても、困ってる状況を書き出す ことは自分がやってることを客観的に見つめることが重要
なる💡ideee代表なる💡ideee代表

ユニットテストを書く

フロントエンドの難しさ

  • Reactの関心ごとはView
  • 下手にテストを書きまくると効用の低い変化に弱いテストになる

テストを書く意味

  • 設計者の意図通りに機能が実現されているかの確認
  • 新規に追加した全ての処理に破綻がないかの確認
  • 既存の機能を破壊していないかの確認
  • モジュラリティの確保
    • ネットワークから、モジュールやコミュニティへの分割の「質」を定量化するもの
    • 疎結合かどうか

テスト方針

  • ロジックのテストはちゃんとやる。
  • コンポーネントに関しては費用対効果を考えて最小限。
    • Storybookを活用
  • 全体の動作の保証のために自動化されたE2Eテストを正常形に限って行う。

JestでAPIハンドラをテストする

Jest：
オールインワンのテストフレームワーク
Made by Facebook
現在テストフレームワークとして１強
https://jestjs.io/ja/docs/testing-frameworks

書き方がRSpecと似ているのでRails書いてる人にとって優しい！
describe() があって it()があって expect()でアサーションす る形

面白いTDDへの見解

  • 通らないことをテストするテストなんて何も嬉しくない
  • テストが落ちたときの赤い文字を見るとMPが削られるので見たくないw
  • 不要なテストまで書きがちになるので必要最小限になりずらい
なる💡ideee代表なる💡ideee代表

E2Eテストを自動化する

E2Eテストの主な選択肢

  • Puppeteer
    • GoogleのChrome DevToolsチームが開発したNodeのライブラリで
    • Chrome 系のブラウザをコントロールするAPIを提供
    • 一番人気
  • Cypress
    • タイムトラベルデバッギングができる
    • ハイライトで見れたりとブラウザ上で使いやすい
    • 実行速度が TestCafe より体感で 二倍は速い
  • TestCafe
    • マルチブラウザ対応
    • スマホなどの実機を操ってテストできる
なる💡ideee代表なる💡ideee代表

プロフェッショナル React の流儀

ReactのサマリーStep

  1. ページをコンポーネントの階層構造に落とし込み、併せて各コンポーネントの Props を決 定する
  2. どのコンポーネントを Container にするかを決め、その Local State および connect する Props を決定する（重要！）
  3. ページを構成する主要なコンポーネントを、スタイルガイドとして Storybook に登録する
  4. Container が発行する Action と発行に使う Action Creator を作成、それに対応する Reducer
    も併せて作る
  5. その Action が必要とする API ハンドラを作成、ユニットテストも併せて書く
  6. 4 と 5 による Saga を作成、ユニットテストも併せて書く
  7. Container Component を作成する
  8. 正常系の E2E テストを作成する

normalizr
JSオブジェクトの正規化を行ってくれるライブラリ

セキュリティの問題から SPA もセッション情報は Cookie に持たせるべきという言説もあった。
今はLocal Storage に格納するのがメジャー（Cookie は格納できる情報が少ない）