フロントエンドエンジニアリング は何をしますか？
コピー、コメント、レポートを作成する前に、anti-ai-writingを読んでください。リポジトリの指示、既存の画面とコンポーネント、デザイントークン、フレームワーク/依存関係のバージョン、ルーティング、データ契約、テスト規約を確認してください。既存のスタックとユーティリティを使用し、なじみのないAPIはそのバージョンの公式ドキュメントで検証してください。無関係な作業や確立されたプロダクトの振る舞いは維持してください。
画面の役割とデザインを確立する
ターゲットユーザー、ユーザーのタスク、主要なアクション、コンテンツの階層、必要な状態、受入基準を特定してください。まずは提供されたデザインと既存のプロダクトパターンを使用してください。大規模な新しいインターフェースの場合は、欠落している重要な要件を明確にし、計画が役立つ場合はagent-planningを使用してください。小さく理解されている変更にデザインの儀式は必要ありません。
新しいビジュアル方向性が必要な場合、関連するリファレンスを研究し、その有用な階層、密度、ナビゲーション、インタラクションの原則をプロダクト自身の言語に翻訳してください。プロプライエタリなブランディング、テキスト、アセット、正確なレイアウトをコピーしないでください。1つの画面のためにデザインシステム全体を発明することなく、実装を導くのに十分なデザイン決定を記録してください。
プロジェクトのトークンから一貫性のあるタイポグラフィ、スペーシング、カラー、角丸、強調を使用してください。汎用的なヒーローセクション、均一なカード、過度に大きなスペーシング、装飾的なグラデーションをデフォルトにするのではなく、ユーザーのアクションと情報を優先してください。これらのパターンはプロダクトが求める場合には適切であり、美的な禁止を課さないでください。長いラベルや疎/密なデータを含む、現実的なコンテンツを使用してください。プロダクトコピーから無関係な実装の詳細を削除してください。すべての公開コントロールを機能的に保つか、利用不可と明確に識別してください。プレースホルダーを作動中の機能として偽装しないでください。
明確なコンポーネントと状態を実装する
変更されたフロントエンド/バックエンド契約には、api-designを使用し、サポートされているコンシューマーを維持してください。UIフィクスチャからバックエンド契約を推測しないでください。
責任の集中と正当化された抽象化には、writing-clean-simple-codeを使用してください。無関係なフラグの大きなマトリックスよりも、コンポジションと確立されたコンポーネントAPIを優先してください。任意の行数ではなく、責任で分割してください。すべてのコンポーネントに個別のコンテナやフックを強制せずに、データとプレゼンテーションの所有権を明確に保ってください。
状態をそれが属する場所に配置してください。ローカルインタラクション状態、共有状態、ナビゲーション可能/共有可能なビューのURL状態、リモートデータ用の既存のサーバー状態ツールです。重複した派生状態や矛盾するブール値を避けてください。いくつかのプロップを避けるためだけにグローバルストアを導入しないでください。安定したアイテムの同一性、履歴ナビゲーション、ディープリンク、フレームワークのレンダリング/ハイドレーション契約を関連する限り維持してください。
該当するローディング、空、成功、エラー、無効、保留中、権限の状態を処理してください。データがないこととフィルターで除外された結果を区別してください。回復可能なエラーの後は入力データを保持し、進め方を説明し、重複送信を防止してください。楽観的更新の場合は、失敗、同時変更、古いレスポンス、調整を考慮してください。共有リクエストをキャンセルする前に、キャンセル所有権をトレースしてください。非表示のコントロールを認可として使用しないでください。サーバーサイドの強制は引き続き必要です。
レイアウトとインタラクションをインクルーシブにする
アクセシビリティとレスポンシブチェックを読んでください。ネイティブなセマンティックHTMLとテスト済みのアクセシブルなプリミティブを優先してください。カスタムインタラクションは、その完全なキーボード、フォーカス、状態の契約を実装する必要があります。ラベル、エラー、ステータスフィードバックは、色やアニメーションに頼らずに理解できるようにしてください。
コンテンツが必要とする場所でブレークポイントを選択し、既存のレイアウトトークンを尊重してください。フレキシブルなレイアウト、適切な幅制限、レスポンシブアセットを使用してください。狭いビューと広いビュー、ズーム、長いテキスト、空の状態、オーバーフローを確認してください。小さな画面では、スクリーンショットに収めるために隠すのではなく、意味のあるコンテンツとアクションを維持してください。
セキュリティとパフォーマンスを維持する
リモートコンテンツとURLは信頼できないものとして扱ってください。フレームワークセーフなレンダリングを使用し、リッチHTMLが必要な場合にのみ、検証済みのメカニズムを通じてサニタイズしてください。クライアントバンドル、テレメトリ、エラーメッセージに秘密やプライベートレコードを公開しないでください。キャッシュされたデータをアイデンティティ/テナントにスコープし、関連するコンテキスト変更時にクリアまたは無効化してください。
不要なフェッチウォーターフォール、高価な繰り返し作業、過度に大きな依存関係、レイアウトシフトを避けてください。フレームワークのアセット、レンダリング、ローディング規約を使用してください。測定された証拠とプロダクトの予算から最適化し、機械的にメモ化、仮想化、コード分割を追加しないでください。ラボの結果と実際のパフォーマンスは異なる証拠であり、別々に報告する必要があります。
レンダリング結果を検証する
動作カバレッジにはtest-authoringを使用してください。関連するリポジトリチェックを実行し、利用可能なブラウザでアプリケーションを実際のデータで検査してください。影響を受けるアクションと状態遷移、キーボードナビゲーション、フォーカス、バリデーション、レスポンシブレイアウト、該当するブラウザターゲットを実行してください。変更に関連するコンソールとネットワークの障害を検査してください。スクリーンショットは外観を確立しますが、インタラクションの正確性は確立しません。自動化されたアクセシビリティスキャンは準拠性を確立しません。
レンダリング出力を承認されたデザインまたはプロジェクトの確立された画面と比較してください。発見されたクリッピング、スペーシング、コントラスト、インタラクションの問題を修正し、影響を受ける状態を再確認してください。UIを確認するためだけに破壊的なライブアクションを実行しないでください。安全なフィクスチャまたは承認されたテスト環境を使用してください。ブラウザアクセスが利用できない場合は、インターフェースを視覚的に検証済みと呼ぶのではなく、未検証のまま残っているものを正確に述べてください。
実際の変更、テストされたフロー/ビューポート、重要な制限を報告してください。独立したレビューが正当で、利用可能で、承認されている場合は、code-reviewを使用してください。コミット、プッシュ、公開には承認されたgit-deliveryを使用してください。