読書 Atomic Design ～堅牢で使いやすいUIを効率良く設計する 後半まとめ
作業概要と実施理由
ATOMIC DESIGNの実践部分をひとまずやってみよう！と思ったけど、まずは作れるようになってから読むテストについてが大半だったのでサンプルプロジェクトを動かしながら概要を抑えるだけにした。テストの自動化は興味があったのでちょうど良かった。
作業時間/見積：5.5h / 4h
学び
- Pages層とTemplates層の違いは動的データを扱うか次第
- どのテスト手法取り込むのかという問題がありそう
- テストの種類は後述しているが、こんなに種類があると思っていなかった
- プロダクトやメンバー構成で、どのテストを自動化するのかを検討する必要がありそう
- 世のWeb制作をしている人たちは、どうやってテストを選定しているのか気になる
メモ
- Atomsは抜き出した後に抽象化する
- 番組のサムネイル → 画像を表示するデザイン要素 → Img
- 番組タイトル → 見出し情報を表示するデザイン要素 → Heading
- チーム内で共通認識取れていればOK
- これがコンポーネント・リストか…すごい
- MailChimpのコンポーネントリスト
- 初回作成時はつよつよデザイナーがリードするんだろうか…0/1の制作過程を詳しく知りたい
- 後日チームの人に自社サービスのコンポーネントリスト見せてもらった…
- properties.cssにデザインのパターンとなる具体の数値を集める
- Fluxアーキテクチャとは？
- 本編では知ってる体ででてきたので軽く調査
- Qiita - Fluxとはなんなのか
- Reduxも出てきた
- やることリストのudemyの動画で学ぶ予定なので、さっさとやろう
- Qiita - 結局FluxやらReduxやらって何なのか個人的なまとめ
- テスト手法一覧
- 単体テスト
- 1つのUIに対してどんな情報を渡しても崩れないか目視で確認するために行う
- それを確認するツールがStorybook
- 1つのUIに対する情報のセットをStoryと呼ぶ
- 1つのUIに対してどんな情報を渡しても崩れないか目視で確認するために行う
- リグレッションテスト
- 意図しない変更を防ぐために行う
- 構造でテストするときはjestのスナップテストを使う
- 開発前のスナップショットと差分が出ていないか確認する
- 意図通りであればスナップショットを撮り直して上書きする
- ビジュアルでテストするときはBackstopJSを使う
- 画像でスナップショットを保存しておき、テスト時に差分を検知する
- ロジックテスト
- インタラクションテスト
- コード・カバレッジ
- テストがどの程度網羅されているのかを確認するために行う
- istanbulを使う
- レイアウトテスト
- さまざまな画面サイズで表示が崩れないか確認するために行う
- ビジュアルテストで使ったBackstopJSを使う
- レスポンシブデザインのテスト
- レスポンシブなレイアウトを実装しているTemplates層でテストを行う
- viewportsを設定することで指定したwidthやheightでビジュアルテストを実行できる
- リキッドレイアウトのテスト
- Templates層より子の階層でテストを行う
- それぞれのコンポーネントがどんな画面幅でも崩れなければOK
- パフォーマンステスト
- 動作が重くなっていないかを確認するために行う
- ネットワーク・アクセス
- 通信の回数が適正か
- 画像のSprite化
- データサイズが適正か
- 画像のレスポンシブ化（RIaS: Responsive Image as Service）
- 画像のフォーマットの最適化
- 通信の回数が適正か
- JavaScript実行時間
- 子の不要な再描画を減らす
- React ver15.3で登場したPureComponentを使うと更新処理が必要かどうかを自動で判断してくれる
- 細かく制御した方が、パフォーマンスが出ることもあるので計測しながら使い分ける
- 子の不要な再描画を減らす
- レイアウト・ペイント処理
- 不要なレイアウト・ペイント処理を減らす
- ReactのAPIを正常に使っていれば更新範囲が最小になる
- どうしてもカスタマイズしたいときはthis.refsを使ってDOM操作をする
- 単体テスト
- デザイナーはトップダウン、エンジニアはボトムアップのアプローチで設計する
- コンポーネントの単位や種類の認識が揃えることで方向性を合わせる
- 未調査
- GraphQL
- プロトタイプベース言語
- create-react-appがやってること
