作業の進め方
メンバー一覧は短い名前なら問題なく動いても、メールアドレスが長いとアクションメニューが失われることがあります。Break UIは、表示される値をすべてprops、フィクスチャ、またはAPIデータまでさかのぼり、許容される上限を確認したうえで、その同じ境界でデータを置き換えます。失敗を作り出すためだけにレイアウトを変更することはありません。
比較は検証しやすい形を保ちます。デモデータと最悪ケースのデータを切り替えられ、必要に応じて空、1件、大量リストの状態も別々に用意します。レポートでは、読めない・到達できない内容、見た目の崩れ、壊れやすい前提を区別し、すでに問題なく動作した点も記録します。
想定される成果物
- ソース、上限、任意の値を記載したフィールド一覧
- 最悪ケースのフィクスチャと、開発専用のデータセット切り替え
- 優先度付きの不具合、修正案、オーナーが判断すべき事項
入力から検出結果まで
- 01表示されるすべての値をマッピングする
コンポーネント、検証ルール、APIの形状を読み取ります。テキスト入力だけでなく、件数、バッジ、画像、リストの長さを含め、上限と欠損時の挙動を記録します。
- 02現実味のあるエッジケースを作る
長い名前、短い名前、欠損フィールド、ローカライズされたラベルを、既存データと同じ形のフィクスチャに組み合わせます。上限が分かっている場合はスキーマの上限を使い、上限のないフィールドは上限を作り出さず、その旨を記録します。
- 03実際のサイズで比較する
切り替え機能は開発環境またはプロトタイプのルートに置きます。コンポーネントの実際のコンテナ、320px、最も広いレイアウト、拡大したテキストで確認し、製品が対応していればダークモードとRTLも含めます。
- 04直す前に報告する
各不具合に、重大度、引き金となった値、修正案、ファイルの場所を示します。折り返しか省略かといった判断が必要な場合は、そこで止まります。修正は依頼があった場合のみ適用し、その後でデモ状態と極端な状態を再テストします。