Slide 1

Slide 1 text

© DressCode Inc . XStateを用いた堅牢な React Components設計 ~複雑なClient Stateをシンプルに~ React Tokyo Meetup #2 Dress Code株式会社 古庄 和也

Slide 2

Slide 2 text

● React歴 ○ 約3年 ● 業務 ○ BtoB SaaS「DRESS CODE」のプロダクト開発 ● 経歴 ○ 2020年 レバレジーズ新卒入社 ○ 2024年 - Dress Code株式会社 ● 趣味 ○ React / ゴルフ / 競馬 / ポーカー 自己紹介 ふるしょう(@k_furusho_)

Slide 3

Slide 3 text

© DressCode Inc . 1. XStateとは 2. 複雑なReactComponentsの事例 3. 状態遷移の流れ 4. UIと状態の連携 5. まとめ Agenda

Slide 4

Slide 4 text

© DressCode Inc . XStateとは

Slide 5

Slide 5 text

XStateとは ● TypeScript/Vanilla JSで使えるState Machine/Chartライブラリ ○ 有限状態とイベントを用いて状態遷移を厳密に管理 ○ Backendでも活用可能 ○ @xstate/reactでは、専用のフックuseMachineを使用 ● 推しポイント ○ DMMF本で提唱されている「Make Illegal States Unrepresetable」の実現容易性 が高く、「有り得る状態の型定義」に加えて状態遷移が明確に定義可能。ガード条 件で不正な状態遷移を防げる ● XStateに関するおすすめ資料 ○ Xstate Stately ○ Xstate Catalogue ○ susiyakiさんのJS/TSで堅牢な状態管理を可能にするXStateの解説

Slide 6

Slide 6 text

実装例:SimpleCounterMachine ● 状態の定義 ○ active状態のみ ○ INCREMENTとDECREMENTの2つ イベントで状態を管理 ● ガード条件 ○ DECREMENTイベントにはガード条 件を設定し、valueが0よりも大きい 場合のみ減算を許可 ○ valueが負の値になる状態を防ぐ

Slide 7

Slide 7 text

© DressCode Inc . 複雑な React Componentsの事例

Slide 8

Slide 8 text

「企業における汎用的なルール策定に必要なフィルタリングの実現」 ● 条件設定 ○ 検索対象(Subject), 演算子(Operator), 値(Object)から構成 ○ 条件の組み合わせはAND/OR条件で個別に指定可能 ○ 条件毎のグルーピング可能 ● 状態のUIへの反映 ○ ユーザーの入力に応じて、動的にフィルタリング結果を更新 ○ フィルタリング条件の変更が即時反映されるインタラクションの実現 ● 不正な状態の防止 ○ ex: 検索対象の選択前に演算子を選択, 同一リソースに対する複数操作の同時実行 複雑な機能要件例

Slide 9

Slide 9 text

© DressCode Inc .

Slide 10

Slide 10 text

© DressCode Inc . 状態遷移の流れ

Slide 11

Slide 11 text

© DressCode Inc . Xstateとは

Slide 12

Slide 12 text

© DressCode Inc . Xstateとは MainStates

Slide 13

Slide 13 text

© DressCode Inc . Xstateとは MainStates SubStates

Slide 14

Slide 14 text

© DressCode Inc . UIとClient Stateの連携

Slide 15

Slide 15 text

具体的なディレクトリ構成例と依存関係

Slide 16

Slide 16 text

UIと状態の連携フロー Server State Client State

Slide 17

Slide 17 text

© DressCode Inc . まとめ

Slide 18

Slide 18 text

● 堅牢なClient Stateの管理が実現できる ○ 状態遷移が明確に定義され、予期しない状態遷移を防止 ● 開発効率の改善 ○ 状態遷移ロジックをコンポーネントから分離できるため、 テストしやすく際利用 可能なロジックの構築が可能 ○ StateMachine × LLM テスト生成の相性が良い ○ 仕様の認識齟齬防止にも繋がる ■ 可視化したStateMachineをベースにPdMや関係者と仕様を擦り合わせやすい ● 拡張性と保守性 ○ 状態遷移が一元化できるため、追加要求が生じた場合にも品質保証しやすい ○ ドメインモデリングとの相性も良いため、featruesベースの開発にも相性が良い まとめ

Slide 19

Slide 19 text

© DressCode Inc . End