複雑なフロントエンド（ノーコード）を堅牢に作る | TSKaigi Kansai

スピーカー

yuta-ike

エムスリー株式会社

シナリオテスト

実際のユーザのシナリオに沿ってテスト

シナリオテストのペイン

エンジニアしかアクセスできない

GUIベースのシナリオ作成ツール

パズル組み合わせるかんじ

テスト実行は担当しない

テストファイルを生成する

それをCI上で実行

--- 本題

フロントエンドの状態管理

データの出入り口でキャッシュするアプローチ

SWRなどのfetch + cache

フロントエンドで状態を保持する

今回はこっち

ノーコードのつらみ

管理する状態数が多い

各ノードの状態、座標とか、エッジ

基本的にほぼ全てがUIに関する状態なので、動作確認が大変

バグ状態の再現が大変

クラッシュするバグの場合特に毎度リセットされて大変

→ コード上でテストできることがとても大事

主要なロジックがJavaScriptに閉じていること

Reactのライフサイクルから逃れたい

E2Eテストではなくユニットテスト

ユーザのアクションを起点にして、どのように状態が遷移するかをテストしたい

ノーコードといえど、Viewの背後にはデータが存在している

ユーザのアクションを起点にしてデータが変化する

Flux

Action

Dispatcher

View

Store

今回の構成

Workflow関数（Effect）

こいつを経由してAtomの変更を行う

データストア（Jotai）

View

Jotaiの活用

Reactに依存せず動作する

Reactへの組み込みも簡単

Entity単位でAtomを作成し、Atomの集合でデータストアを構成する

PrimitiveNodeAtom

PrimitiveRouteAtom

ノードのつながりをIDの配列として保持

RouteAtom、NodeAtom

PrimitiveなAtomを合成したEntity

FooAtom

各コンポーネントで使いやすいように

これらの構造をFigJamで管理

Workflow関数

Effectライブラリを使う

Effect型をベースにしたライブラリ

FluxでいうところのAction

基本的に関数に切り出して、それを呼び出す形

Workflow関数は実行のフローだけ知っている状態にする

純関数にする

副作用のある関数はDIする

Branded Types

type NodeId = string & { [_node]: never}

同じstring型でも代入できない

まとめ

データの読み取り：Jotaiを利用して柔軟なクエリ

書き込み：Effectを使ってWorkflow関数を純粋に保つ

Entity：ドメインロジックは〜〜

テストユーザ募集中