Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
できるところからやっていく React長期案件の課題とリアルな落とし所
Search
mish
October 23, 2023
1
370
できるところからやっていく React長期案件の課題とリアルな落とし所
2023/10/20に行われたクラスメソッドのReact事情大公開スペシャルで発表した内容の資料です。
https://classmethod.connpass.com/event/297198/
mish
October 23, 2023
Tweet
Share
More Decks by mish
See All by mish
Static Web Development Powered by HUGO with AWS
mish2018
0
1.1k
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Code Review Best Practice
trishagee
66
17k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Docker and Python
trallard
44
3.3k
Unsuck your backbone
ammeep
669
57k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
8
270
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
31
2.1k
Building Adaptive Systems
keathley
40
2.4k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.2k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.3k
Being A Developer After 40
akosma
89
590k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
Transcript
できるところからやっていく React長期案件の課題とリアルな落とし所 CX事業本部 mish 1
2 自己紹介 mish (@mrobot_) フロントエンド - ReactとTypescript - LINE ミニアプリ、管理画面
好きなAWSサービス:AWS CDK 入社:2018年6月(5年5ヶ月) 所属:福岡オフィス 趣味:犬吸い 12冠まであと2つ・・・
- 2018(入社) - AngularでWebアプリ開発 - 2019(LINEミニアプリブーム到来) - LINEミニアプリをReact Native for
Webで開発 - 2020 - Reactで大規模Webアプリを開発 - 管理画面、ダッシュボード - 2021-2023 - ReactでLINEミニアプリの開発 - ホームセンター会員証ミニアプリ - レシピ検索アプリ - 鉄道会社のミニアプリ 3 年表(ざっくり) サーバーサイドエンジニアとして入社したよ フルスタックエンジニアになりたいので フロントエンドを担当しつつ、バックエンドのタ スクももらったりしているよ
4 小規模〜大規模なアプリの React開発を数年やってきた感想
5 Reactは海
6 油断するとすぐちらかる
7 Reactは自由 フレームワークではなくライブラリ 自由気ままなファイル構成 フロントエンドはやることが多い 理にかなったUIの見た目を造る(Style) 必要な情報の取得(Fetch) 必要な情報の保持(Store) 不要なレンダリングを行わない(Lifecycle) 意図しない変更が発生していないことを担保する(UI
Test) ライブラリのアップデート CI/CDとか多分もっとある 何をどこに置いても良い
8 そこそこ複雑なものを 複数人で作るのでちらかりやすい
9 なので片付けやすい環境があると良い
10 本日のお品書き 肥大化したCSSをなんとかしたい Emotionを部分的に導入してみた SnapShot Testを導入した E2Eテストが便利だよ
11 これはCSSの森
12 大盛り なにがどこで定義されているのか追いづらい →全体のStyleとPageごとのStyleと 部品ごとのStyleがある →メンテできておらず使っていない定義が たくさんある →UIテストがないので整理できない
13 解決したいこと - CSSをコンポーネントに閉じたい - 大きいCSSファイルを探索したくない - 何がどこにあるかもっとわかりやすくできるはず - 軽率にリファクタリングしたい
- 意図しない変更が反映されていないことを効率がいいやり方 で確認したい
14 実際にやってみたこと - CSSをコンポーネントに閉じたい - クラス名を迷いたくない →Emotionを導入 - 軽率にCSSをリファクタリングしたい →Playwrightを使ったSnapshotTestを
導入
15 部分的にEmotionを導入 Emotion:CSS-IN-JSのライブラリ CSSをコンポーネントに閉じることができる MUIなどでも内部で利用されている メリット: - Styleをコンポーネントに閉じることができる - 柔軟な書き方ができる
- Styled Componentライクな記述 - テンプレート文字列、Object形式の記法
16 Emotion利用例 Styled Componentライクな書き方例
17 Emotion利用例 テンプレート文字列での書き方例
18 Emotion VSCode拡張で補完してくれる https://marketplace.visualstudio.com/items?itemName=styled-components.vscode-styled-components
19 Emotion使ってみて よかったこと - Styleをコンポーネントに閉じられる - Global Styleの定義やThemeの設定などあると嬉しい機能 は大体備わっている -
CSSでできることは大体できる - 書き方に慣れるまでは大変かも
20 Emotion使ってみて 反省点 - 既存のCSSファイルが膨大で一度に移行することが不可能 - なので一時的あるいは今後しばらく混在した状態になる CSSのリファクタの際にUIの変更を検知したいのでSnapshot Testも同時に導入しました
21 Snapshot Testとは ブラウザを自動操作して任意の画面のスクショを取得 Pixelのずれや要素の変更などを検知してくれる - 差分があるとテストが落ちて変更があることを教えてくれ る - --update-snapshot
オプションを渡して再実行するとスナッ プショットを更新してくれる
22 Snapshot Testを導入 SnapshotをGitの管理下におくことでUIの変更状態をPRと一 緒に確認できる MSWと組み合わせてAPIのレスポンスをモックする方法もあ り - バックエンドの変更に合わせたりメンテナンスが大変なので工 数と要相談
- BEの実装を待たずにFEの実装を進めたい時便利 TEST環境のAPIとLocal起動したReactプロジェクトでスナップ ショットを取得する方法を使っています
23 Snapshot Testがすごく便利だった例 とにかく種類が多いエラー画面の実装要件 - 遷移元画面3種によってそれぞれ5種類づつ違ったメッセージが含まれるエラー画面の 実装 - 一つ一つのエラー発生条件を再現してUIを確認するのが地味に大変 x3
24 UIの状態をPRと一緒に確認 - コードの変更とUIの状態をチェックできる - レビュワーの作業負荷を減らす
25 UIテストツールの選定について - 画面のバリエーションが多い時はSnapshotテストが便利 - 要素の一つ一つが凝っている時はStoryBookの方がはまりそう(グラ フやアニメーションを含む要素など) Storybookもあってもいいと思いましたが全部盛りにすると実 装とメンテの負担になりそうなので一旦見送り -
アプリの性質とかけられる工数と相談して選ぶのが良い
26 ライブラリアップデートの時間です
27 解決したい問題 ライブラリアップデートの心理的負荷を下げたい - 影響範囲が大きいので最低限壊れてないことを確認したい - ビルドできない等あからさまでない場合気づきにくい 修正した箇所以外でバグが出ていないことを確認したい - バグ修正のたびにテストケースを網羅するのは実質不可能
リリース直前にどこか壊れてないか確認したい
28 対策 E2Eテストを拡充しました
29 E2Eテストとは エンドユーザーの視点に立って現実世界で 想定されるシナリオをシュミレートする シナリオ例: ログイン<利用規約同意<会員登録<モーダル表示<ホーム画面
30 E2Eテストとは シナリオ1:新規ユーザー ログイン<利用規約同意<会員登録<モーダル表示<ホーム画面 シナリオ2:登録済みユーザー ログイン<利用規約同意<会員登録<モーダル表示<ホーム画面
31 E2Eテストとは シナリオ1:新規ユーザー ログイン<利用規約同意<会員登録<モーダル表示<ホーム画面 シナリオ2:登録済みユーザー ログイン<利用規約同意<会員登録<モーダル表示<ホーム画面 1. SDKでDBにユーザーデータを登録 2. Playwrightでブラウザ自動操作
3. 画面要素が想定通り表示されているかチェック 4. Snapshotを残すこともできる 5. テストが終わったらSDKでDBをクリーンアップ
32 E2Eでカバーできない箇所の例 SMS認証 - プロバイダによってはテスト用にマジックナンバーを用意してくれている ので工夫すれば突破できるかも 一瞬の画面のちらつき - たまにあるデータをFetchしてStateを更新する一瞬の間にちらつくエラー 画面など
- エラーとして想定してない挙動は人が見つけるしかない 外部サービスとの連携部分 - DB操作などで回避 デバイス依存の挙動チェック - LINEブラウザの挙動は実機でしか確認できない
33 E2Eテストがあってよかったと思う時 - 実機テスト後のバグ修正後の動作確認を自動化 修正が入るたびに全部のテストケースを手動で網羅することは不可 能 - リリース直前の動作確認を行う時 - ライブラリアップデートなど影響範囲が読みづらい作業を行う時
- 新しい人が参入してアプリの仕様を整理したい時 - テストケースから裏側の仕様が読み取れる
34 まとめ - ミスのない完璧なコードを書くことはできない - 気楽にリファクタできる環境があると良い - UIテストツールはアプリの性質と工数と相談して何を導入 するかを決めると良い -
面倒な作業はなるべく自動化できると良い - スナップショットで画面の差分確認 - システムとして壊れている箇所がないか自動で確認
35 うちではこんな運用でやってるよ! こうしたらいいよ! このツールいいよ! などありましたらぜひ懇親会で教えて欲しいで す 🍺
36