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
350
できるところからやっていく 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
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Side Projects
sachag
452
42k
The Cult of Friendly URLs
andyhume
78
6k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
840
Navigating Team Friction
lara
183
14k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.3k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
[RailsConf 2023] Rails as a piece of cake
palkan
52
4.9k
Producing Creativity
orderedlist
PRO
341
39k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Ruby is Unlike a Banana
tanoku
97
11k
Six Lessons from altMBA
skipperchong
27
3.5k
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