Que fait Ingénierie Frontend ?
Lisez anti-ai-writing avant de rédiger des textes, commentaires ou rapports. Lisez les instructions du dépôt, les écrans et composants existants, les tokens de design, les versions du framework/dépendances, le routage, les contrats de données et les conventions de test. Utilisez la stack et les utilitaires existants ; vérifiez les API inconnues par rapport à la documentation officielle de cette version. Préservez le travail non lié et le comportement établi du produit.
Établir l'Objectif et le Design de l'Écran
Identifiez le public, la tâche utilisateur, l'action principale, la hiérarchie du contenu, les états requis et les critères d'acceptation. Utilisez d'abord les designs fournis et les modèles de produits existants. Pour les nouvelles interfaces substantielles, clarifiez les exigences manquantes importantes et utilisez agent-planning lorsqu'un plan est utile. N'exigez pas une cérémonie de design pour un changement petit et compris.
Lorsqu'une nouvelle direction visuelle est nécessaire, étudiez les références pertinentes et traduisez leur hiérarchie, densité, navigation et principes d'interaction utiles dans le langage propre du produit. Ne copiez pas l'image de marque propriétaire, les textes, les actifs ou les dispositions exactes. Enregistrez suffisamment de décisions de design pour guider l'implémentation sans inventer un système de design entier pour un seul écran.
Utilisez une typographie, un espacement, des couleurs, des rayons et une emphase cohérents à partir des tokens du projet. Priorisez l'action et l'information de l'utilisateur plutôt que de recourir par défaut à des sections héros génériques, des cartes uniformes, un espacement surdimensionné ou des dégradés décoratifs. Ces motifs peuvent être appropriés lorsque le produit le demande ; n'imposez pas d'interdictions esthétiques. Utilisez un contenu réaliste, y compris des étiquettes longues et des données clairsemées/denses. Supprimez les détails d'implémentation non liés des textes du produit. Gardez tous les contrôles exposés fonctionnels ou clairement identifiés comme indisponibles ; ne déguisez jamais un espace réservé en fonctionnalité fonctionnelle.
Implémenter des Composants et États Clairs
Pour les contrats frontend/backend modifiés, utilisez api-design et préservez les consommateurs pris en charge. Ne déduisez pas un contrat backend à partir de fixtures UI.
Utilisez writing-clean-simple-code pour des responsabilités ciblées et des abstractions justifiées. Préférez la composition et les API de composants établis à une grande matrice de drapeaux non liés. Divisez par responsabilité, pas par nombre arbitraire de lignes. Gardez la propriété des données et de la présentation claire sans forcer un conteneur ou un hook séparé pour chaque composant.
Placez l'état là où il est détenu : état d'interaction locale, état partagé, état URL pour les vues navigables/partageables, et outils d'état serveur existants pour les données distantes. Évitez l'état dérivé dupliqué et les booléens contradictoires. N'introduisez pas un store global uniquement pour éviter quelques props. Préservez l'identité stable des éléments, la navigation dans l'historique, les liens profonds et les contrats de rendu/hydratation du framework lorsque cela est pertinent.
Gérez les états applicables : chargement, vide, succès, erreur, désactivé, en attente et permission. Distinguez l'absence de données des résultats filtrés. Préservez les données saisies après des erreurs récupérables, expliquez comment procéder et empêchez les soumissions en double. Pour les mises à jour optimistes, tenez compte des échecs, des changements concurrents, des réponses obsolètes et de la réconciliation. Tracez la propriété d'annulation avant d'annuler des requêtes partagées. N'utilisez pas de contrôles cachés comme autorisation ; l'application des règles côté serveur reste nécessaire.
Rendre la Mise en Page et l'Interaction Inclusives
Lisez les vérifications d'accessibilité et de réactivité. Préférez le HTML sémantique natif et les primitives accessibles testées. L'interaction personnalisée doit implémenter son contrat complet de clavier, focus et état. Les étiquettes, erreurs et retours de statut doivent être compréhensibles sans dépendre de la couleur ou de l'animation.
Choisissez les points de rupture là où le contenu en a besoin et respectez les tokens de mise en page existants. Utilisez des mises en page flexibles, des limites de largeur appropriées et des actifs réactifs. Vérifiez les vues étroites et larges, le zoom, le texte long, les états vides et le débordement. Préservez le contenu et les actions significatifs sur les petits écrans plutôt que de les cacher pour correspondre à une capture d'écran.
Préserver la Sécurité et les Performances
Traitez le contenu distant et les URL comme non fiables. Utilisez un rendu sécurisé par le framework ; ne sanitisez que via des mécanismes validés lorsque du HTML riche est nécessaire. N'exposez pas de secrets ou d'enregistrements privés dans les bundles client, la télémétrie ou les messages d'erreur. Limitez les données mises en cache à l'identité/locataire et effacez ou invalidez-les lors de changements de contexte pertinents.
Évitez les cascades de fetch inutiles, le travail répété coûteux, les dépendances surdimensionnées et les décalages de mise en page. Utilisez les conventions d'actifs, de rendu et de chargement du framework. Optimisez à partir de preuves mesurées et de budgets produit ; n'ajoutez pas de mémoïsation, virtualisation ou découpage de code mécaniquement. Les résultats de laboratoire et les performances sur le terrain sont des preuves différentes et doivent être rapportés séparément.
Vérifier le Résultat Rendu
Utilisez test-authoring pour la couverture comportementale. Exécutez les vérifications pertinentes du dépôt et inspectez l'application dans un navigateur disponible avec des données réalistes. Testez les actions affectées et les transitions d'état, la navigation au clavier, le focus, la validation, la mise en page réactive et les cibles de navigateur applicables. Inspectez les échecs de console et de réseau pertinents pour le changement. Les captures d'écran établissent l'apparence, pas la correction de l'interaction ; les scans automatisés d'accessibilité n'établissent pas la conformité.
Comparez le résultat rendu avec les designs acceptés ou les écrans établis du projet. Corrigez les problèmes de découpage, d'espacement, de contraste ou d'interaction découverts et revérifiez les états affectés. N'exécutez pas d'actions destructrices réelles uniquement pour vérifier une UI ; utilisez des fixtures sécurisées ou un environnement de test autorisé. Si l'accès au navigateur n'est pas disponible, indiquez exactement ce qui reste non vérifié plutôt que de qualifier l'interface de validée visuellement.
Rapportez les changements réels, les flux/testés, et les limites matérielles. Utilisez code-review lorsqu'une révision indépendante est justifiée, disponible et autorisée. Le commit, le push et la publication utilisent git-delivery autorisé.