Créez une app TypeScript native et web en suivant les règles du dépôt

## Lancez tests, lint et builds via les scripts du dépôt Considérez le manifeste du paquet et les scripts du dépôt comme la référence pour les versions et les commandes prises en charge. Préférez les API actuelles prises en charge et remplacez les pratiques anciennes ou obsolètes lorsque le périmètre concerné permet de le faire sans risque. Utilisez les scripts du gestionnaire de paquets pour : - démarrer le serveur de développement et chaque plateforme prise en charge ; - exécuter les tests unitaires, le lint, la vérification des types et le formatage ; - produire les builds web et générer les projets natifs. N’invoquez jamais directement les outils sous-jacents de test, de lint, de vérification des types ou de formatage lorsque des scripts du dépôt existent. Ces scripts peuvent fournir une configuration ou une préparation que les commandes directes omettent. N’exécutez pas de commandes d’extraction ou de compilation de la localisation lorsque ces tâches relèvent de la CI. Ajoutez ou mettez à jour les chaînes traduisibles dans le code source, puis laissez la chaîne automatisée planifiée mettre à jour les catalogues et les traductions à l’exécution. Avant de modifier le code, déterminez les plateformes cibles, le script canonique de vérification et si les artefacts générés sont gérés localement ou par l’automatisation. ## Placez les nouveaux écrans et composants dans le bon dossier Placez les éléments d’interface partagés et indépendants de la plateforme dans `components`. Placez les routes de pages complètes dans `screens`. Utilisez `features` pour les fonctionnalités plus vastes qui combinent contexte, accès aux données, composants et utilitaires sur plusieurs écrans. Pour un écran complexe doté de composants ou d’un état privés, créez un répertoire d’écran et regroupez-y ces dépendances. Ne déplacez pas de code vers un dossier partagé avant que plusieurs consommateurs en aient besoin. Conservez les hooks d’état du serveur, les préférences simples de l’interface, l’état de session et la persistance dans des modules d’état clairement définis, ou regroupez l’état propre à une fonctionnalité avec son consommateur. Évitez les fichiers volumineux qui mêlent des responsabilités sans rapport. Utilisez `lib` pour les utilitaires réutilisables, les clients d’API, les formateurs et les constantes qui n’appartiennent pas à une fonctionnalité. Évitez d’ajouter de nouveaux répertoires source de premier niveau lorsqu’une responsabilité établie convient déjà. N’ajoutez pas de nouveau travail aux anciens répertoires de vues. Préservez le code ancien existant, sauf si la migration fait partie de la tâche, mais placez les nouveaux écrans, composants et fonctionnalités dans la structure actuelle. Utilisez PascalCase pour les noms de composants et camelCase pour les fichiers, répertoires, variables et fonctions ordinaires. Un module conséquent peut utiliser un point d’entrée `index.tsx` accompagné de composants, hooks et utilitaires voisins ; conservez un petit composant dans un seul fichier. Regroupez la documentation facultative d’une fonctionnalité et ses tests avec les modules plus importants. Les commentaires doivent expliquer pourquoi une décision existe, et non ce que le code exprime déjà. Utilisez des blocs de documentation pour les déclarations nommées, des commentaires de bloc pour les explications sur plusieurs lignes et des commentaires de ligne uniquement pour les notes courtes. ## Construisez l’interface avec le système de conception et les composants existants Utilisez le système de conception établi avant de créer des styles bruts ou des composants en double. Combinez les atomes indépendants du thème, les atomes du thème et les styles bruts exceptionnels dans cet ordre : 1. atomes de flex et de mise en page ; 2. atomes d’espacement ; 3. atomes de typographie ; 4. couleurs et surfaces du thème ; 5. styles bruts au périmètre strictement limité. Utilisez les utilitaires de style de la plateforme pour les styles conditionnels et les hooks de points de rupture pour la mise en page adaptative. Maintenez les conditions de plateforme dans la composition des styles au lieu de les disperser dans la logique des composants. Avant de créer un contrôle, recherchez dans la bibliothèque de composants partagés un bouton, une boîte de dialogue, un menu, un champ de texte ou une primitive typographique appropriée. Respectez son API composée et les usages canoniques existants. Pour les déclarations de composants : - préférez la syntaxe abrégée des fragments, sauf si un fragment doté d’une clé est nécessaire ; - préférez les déclarations de fonction ; - déstructurez les props dans la liste des paramètres ; - utilisez des types de props explicites en ligne tant qu’ils restent lisibles ; - attribuez des valeurs par défaut raisonnables aux props facultatives ; - gardez les composants réutilisables indépendants de la plateforme lorsque c’est possible. Utilisez des champs de texte non contrôlés avec `defaultValue` lorsque l’architecture de la plateforme fonctionne mal avec des entrées contrôlées. N’utilisez des valeurs contrôlées que lorsque le comportement l’exige réellement. Le texte généré par les utilisateurs peut contenir des emoji même si les exemples n’en montrent pas. Activez le comportement sécurisé pour les emoji du système typographique pour le contenu des utilisateurs et ne l’omettez que pour du texte statique connu. ## Rendez traduisible chaque texte affiché à l’écran Enveloppez chaque chaîne destinée aux utilisateurs dans la macro ou le composant de traduction du projet. Ajoutez des commentaires ou du contexte pour les traducteurs lorsqu’un mot a plusieurs sens, par exemple lorsqu’un nom et un verbe partagent la même orthographe. Utilisez le point d’entrée moderne des macros pris en charge par le framework de traduction. Attribuez un alias à sa fonction de traduction lorsqu’un autre sous-système, tel que celui des thèmes, utilise déjà le même nom de variable court. Utilisez les fonctions de pluralisation du framework de traduction pour les nombres et son formateur de date pour les dates et les heures. Le formatage du framework doit être réexécuté lorsque la langue active change ; le formatage direct selon les paramètres régionaux ne l’est souvent pas. Préférez une ponctuation Unicode typographiquement correcte dans les textes destinés aux utilisateurs. Appliquez systématiquement les conventions de ponctuation du projet, notamment les guillemets et l’espacement autour des tirets. Ne modifiez pas manuellement la sortie de localisation générée et n’exécutez pas localement les tâches d’extraction ou de compilation qui relèvent de la CI. Les modifications du code source doivent contenir les messages enveloppés et suffisamment de contexte pour permettre une traduction exacte. ## Gérez les données serveur, la navigation et les fichiers par plateforme Utilisez la bibliothèque établie de requêtes d’état du serveur pour les données distantes et un état fondé sur le contexte pour les préférences simples de l’interface. Exposez les préférences au moyen de hooks appariés de lecture et de mise à jour. Construisez les clés de requête avec l’utilitaire partagé de clés et un objet d’arguments. La racine de la clé doit correspondre au nom du hook. Utilisez des noms cohérents pour les hooks de requête, les hooks de mutation et les utilitaires de mutation limités au cache. Choisissez les délais d’obsolescence dans les constantes partagées. Pour la pagination par curseur, utilisez une requête infinie, renvoyez le curseur de la réponse comme paramètre de page suivante et n’aplatissez les pages qu’à la limite de consommation. Lorsque la structure des données de requête persistées change, incrémentez leur version persistée afin que les anciennes données sérialisées soient supprimées puis récupérées de nouveau. En cas d’échec d’une mutation : - informez les utilisateurs des défaillances réseau attendues sans les dupliquer dans les journaux d’erreurs ; - gérez explicitement les erreurs typées de protocole ou d’API ; - envoyez les défaillances inattendues à la journalisation structurée avec un message sûr. Utilisez des paramètres de route typés et l’utilitaire ou le hook de navigation du projet. Maintenez synchronisés la configuration, les définitions et les types des routes. Représentez les implémentations propres aux plateformes par des suffixes de noms de fichiers tels que `.web`, `.native`, `.ios` et `.android`. Importez le chemin du module de base et laissez le bundler sélectionner l’implémentation. N’utilisez jamais d’importations conditionnelles à l’exécution pour choisir les fichiers de plateforme. Préférez regrouper les variantes de plateforme derrière un seul répertoire de module. Utilisez les indicateurs de plateforme à l’exécution uniquement pour le comportement, et non pour la résolution des modules. Utilisez l’alias d’importation absolue du dépôt plutôt que des parcours relatifs profonds. ## Évitez les décalages à la fermeture des dialogues et la mémoïsation inutile Exécutez dans la fonction de rappel de fermeture du contrôle de la boîte de dialogue toute action qui doit avoir lieu après sa fermeture. Fermer d’abord, puis naviguer immédiatement, ouvrir une autre superposition, mettre à jour l’état concerné ou invoquer une fonction de rappel du composant parent peut provoquer une course avec l’animation de fermeture. La séquence obligatoire est la suivante : 1. appelez la méthode de fermeture ; 2. fournissez une fonction de rappel à cette méthode ; 3. effectuez la navigation, l’ouverture de superpositions, les mises à jour de l’état ou les fonctions de rappel du composant parent dans cette fonction. Respectez les composants composés propres à chaque plateforme. Une poignée de boîte de dialogue ou un élément de conteneur de menu peut être réservé aux plateformes natives, tandis qu’un contrôle de fermeture ou un séparateur de menu peut être réservé au web. Testez les plateformes qui exécutent chaque branche. Lorsque la mémoïsation automatique du compilateur est activée, n’ajoutez pas `useMemo` ou `useCallback` de manière préventive. Utilisez-les uniquement pour répondre à une exigence concrète de stabilité référentielle, telle que la dépendance d’un effet ou le contrat d’une bibliothèque extérieure à React. Ne sacrifiez pas la lisibilité à une optimisation spéculative. Mesurez un problème réel ou répondez à une exigence explicite de stabilité avant d’ajouter une mémoïsation manuelle. ## Testez chaque plateforme concernée avant de déclarer le travail terminé Avant de terminer : 1. vérifiez que chaque élément interactif possède une étiquette accessible et une indication utile lorsque cela est nécessaire ; 2. vérifiez que toutes les chaînes destinées aux utilisateurs sont localisées et que les messages ambigus contiennent du contexte ; 3. vérifiez que les styles utilisent de manière cohérente les atomes du système de conception, les valeurs de thème et les utilitaires de plateforme ; 4. vérifiez que l’état du serveur, les préférences de l’interface et l’état de session utilisent les mécanismes prévus ; 5. vérifiez qu’aucun composant partagé existant n’a été dupliqué ; 6. vérifiez que les props et les paramètres de route possèdent des types explicites ; 7. exposez des identifiants de test stables lorsque les tests de bout en bout en ont besoin ; 8. exécutez les scripts du dépôt pour les tests, le lint, la vérification des types et le formatage ; 9. testez tous les comportements natifs et web concernés. Examinez les différences pour détecter toute nouvelle utilisation d’anciens répertoires, toute importation conditionnelle de plateforme, toute modification directe de fichiers de localisation générés, toute régression entre entrées non contrôlées et contrôlées, ainsi que toute condition de course après la fermeture d’une boîte de dialogue. Signalez toute plateforme ou tout script canonique qui n’a pas pu être exécuté, en indiquant le prérequis manquant. Ne prétendez pas avoir terminé le travail multiplateforme après une vérification sur une seule plateforme.