Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Storybook駆動開発でフロントエンドリアーキテクトに立ち向かう

Yuta Takahashi
September 04, 2024
1.4k

 Storybook駆動開発でフロントエンドリアーキテクトに立ち向かう

■ 登壇イベント
各社から学ぶ!フロントエンドのためのリアーキテクチャ
https://findy.connpass.com/event/326972/

■ Googleスライド版
スライド内で掲載しているGif画像はGoogleスライドから御覧ください。
https://docs.google.com/presentation/d/18AVewQQuSQtiMtNAXqewkCXaJZ8Un2dAQeExdXmcRgA/edit?usp=sharing

■ 関連記事
『軽量なStorybook駆動開発を支えるコンポーネント設計』
https://zenn.dev/yuta_takahashi/articles/600e62c7ac7b3c

『fetchに依存しない軽量なStorybookを構築するテクニック』
https://zenn.dev/yuta_takahashi/articles/45c6ceecd6b12a

Yuta Takahashi

September 04, 2024
Tweet

Transcript

  1. 2 ⾃⼰紹介:髙橋 佑太 / Yuta Takahashi 2021年に現職に新卒⼊社 医科診療所向け業務アプリケーションの開発に従事 普段はReactやRuby on

    Railsを書いている Webフロントエンドの設計を考えるのが好き X(Twitter):@Wakeupsloth はじめに
  2. 7 Portable Stories:Storyの実⾏結果をテストする • StoryをJest, Vitest, Playwright CTなどの テストツールで利⽤できるユーティリティ [2][3][4][5]

    • インタラクションとアサーションを 実⾏レベルで分離できる • Storybook上で確認したテストケースに対してア サーションを書くだけで簡単にテストを実装で きる 1.Storybook駆動開発を始めよう
  3. 10 概要:私達のフロントエンドリアーキテクト 2.Storybook駆動開発を活⽤したフロントエンドリアーキテクト 課題 • 複数の課題が⼭積みされ、変更に時間がかかり、開発が難しいコードベースになっていた • 可読性、変更容易性、テスト容易性、モダンフロントエンドとのギャップなどが主な課題 達成したい⽬標 •

    モダンな技術スタックへの移⾏による開発体験の向上 • 持続可能なコードベースの構築による可読性、拡張容易性、内部品質の向上 採⽤したアプローチ • ページ/コンポーネント単位のリアーキテクト(ライブラリ移⾏等を含む) • 複合コンポーネント単位のStorybook駆動開発によるテストコードの整備
  4. 11 実践例:複合コンポーネント単位のStorybook駆動開発 • 単⼀責任の原則に従った複合コンポーネント(機能単位)ごとに開発 • 複合コンポーネントは⾃律的に動作するようにネットワーク処理までセットでモジュール化 • Container/Presentationで分割し、PresentationレイヤーはUIの関⼼に集中 2.Storybook駆動開発を活⽤したフロントエンドリアーキテクト 開発の流れとテスト戦略

    1. PresentationをStorybook駆動開発でテスト ◦ ビジネスロジックを含む場合は純粋関数 に切り出して単体テスト 2. Containerの実装と各要素の単体テスト 3. アプリケーションへ繋ぎこみE2Eテスト Container ネットワーク処理 データの相互変換 複合コンポーネント(例:<UserProfileEditDialog />) Presentation UI UI関連の状態管理 ビジネスロジック レガシーコードとの接続
  5. 12 実践例:巨⼤なレガシーページのリアーキテクト 2.Storybook駆動開発を活⽤したフロントエンドリアーキテクト • 複合コンポーネントごとにテストを実装しながら持続可能なコードベースへ再構築 • ページ単位で丸ごと再構築 or 機能拡張の箇所から漸進的に始めることも技術スタック次第で可能 Container

    Presentation Container Presentation Container Presentation Container Presentation 巨⼤なレガシーページ ネットワーク処理 UI UI UI UI ビジネスロジック グローバルステート UI ‧‧‧ 複合コンポーネントA 複合コンポーネントB 複合コンポーネントC 複合コンポーネントN リアーキテクト後のページ
  6. 15 参考:私達のフロントエンドリアーキテクトの詳細 2.Storybook駆動開発を活⽤したフロントエンドリアーキテクト リアーキテクト要素 As-Is To-Be UIライブラリ Mithril (jsx) React

    (tsx) コンポーネント設計 ページ単位のデータフェッチ APIやビジネスロジックが密結合で テストが難しい構造 複合コンポーネント単位のデータフェッチ Container/Presentation分割によるテストしやすい構造 ステート管理 Reduxですべてのステートを管理 「複数画面の共通ステート」によって リグレッションしやすい構造 グローバル(Redux) フォーム(react-hook-form) 非同期(TanstackQuery) テスト Unit Test(Jest) E2E Test(MagicPod) Unit Test (Vitest) UI Test(Vitest, Storybook, React Testing Library) Visual Regression Test(regsuit, storycap) E2E Test(MagicPod) ページ/コンポーネント単位で、開発体験に優れた拡張‧保守しやすいコードベースへ再構築
  7. 16 Storybook駆動開発をリアーキテクトに活⽤した効果 良かったこと • テストコードを同時に実装する⽂化が醸成できた ◦ レビューが簡単になった ◦ リファクタリングしやすくなった •

    複合コンポーネント単位での漸進的なリアーキテクトが可能になった • Storybook(Vite)による爆速な開発環境の恩恵を最⼤限受けられる ⼤変だったこと • Storybook駆動開発を軌道に乗せるために⾃分たちに合う実装⽅針‧コンポーネント設計を模索し た 2.Storybook駆動開発を活⽤したフロントエンドリアーキテクト
  8. 19 私達がAPIモックツールを使わない理由 • 当初はMock Service Workerを使ってAPIレスポンスをモックしていた • フロントエンド‧バックエンドで分業していないため、StorybookのためだけにAPIモックコードを実 装するのは開発負荷が⾼かった •

    結果、「時間がないからStorybookを作らない」という状況が発⽣してしまいStorybook駆動開発が定 着しなかった • テストがFlakyになりがちで悩みの種だった 3.Storybook駆動開発を軌道に乗せるためのアプローチ
  9. 22 実装例:Container Component 3.Storybook駆動開発を軌道に乗せるためのアプローチ • データの取得や更新処理を担当する • API通信部分はResult型を返す⾮同期関数 としてPresentationに渡す •

    API通信の結果、UIをどのように更新する かはすべてPresentationに任せる • ネットワークレスポンス/リクエストの整形 は純粋関数のセレクタに切り出して単体テ ストする
  10. 26 参考 1. Storybook: Frontend workshop for UI development 2.

    Stories in unit tests 3. Portable stories in Jest - Docs 4. Portable stories in Playwright CT 5. Portable stories in Vitest 6. Storybook 駆動開発 @ CSF3.0 おわりに