Décidez où la modale doit apparaître : page de liste (ex. tableau de projets) ou page détaillée. Privilégiez une position logique proche du bouton d’action (ex. “Nouveau projet”).

Créez un état local qui contrôle si la modale est ouverte ou fermée. Ce contrôle se lie au composant Dialog pour l’ouverture/fermeture (par exemple via une variable d’état ou une propriété d’interface).

Avant d’ouvrir la modale, préparez les valeurs par défaut : si l’utilisateur clone un repo ou reprend une configuration, passez ces valeurs pour éviter la ressaisie.

Dans la modale, utilisez un Loader lorsque vous lancez des actions asynchrones (création, import, validation). Le Loader doit couvrir uniquement la partie en cours pour éviter de bloquer la modale entière si vous avez des sections indépendantes.

Affichez les erreurs près des champs concernés et, en cas d’erreur serveur, montrez un message global. Si l’opération échoue, laissez la modale ouverte pour que l’utilisateur corrige.

Quand la création réussit, fermez la modale et mettez à jour la liste principale (rafraîchissement local). N’oubliez pas de réinitialiser les valeurs du formulaire pour la prochaine ouverture.

Assurez-vous que le focus entre dans la modale à l’ouverture, qu’il est piégé à l’intérieur et qu’il revient au contrôle déclencheur à la fermeture. Proposez raccourcis clavier (Esc pour fermer) et libellés clairs pour les lecteurs d’écran.

Pour les dialogues en chaîne (ex. création puis configuration), fermez la modale initiale uniquement si l’action est complète, ou ouvrez une modale secondaire depuis la principale en conservant l’état de la première.

Déterminez si vous souhaitez copier un composant pour l’adapter localement (copy) ou maintenir une relation avec l’origine (fork/clone). Copier est simple mais entraîne une duplication de maintenance ; cloner/fork permet des mises à jour centralisées.

Avant de copier un composant, listez ses dépendances : styles globaux, utilitaires (ex. gestion thème, gestion d’état), et ressources (icônes, traductions). Rassemblez-les pour éviter les erreurs manquantes.

Si vous copiez, extrayez uniquement le markup et les assets nécessaires. Supprimez ou remplacez les liaisons spécifiques au projet d’origine (noms d’état, appels directs à services).

Au lieu de modifier le composant copié, créez un petit “wrapper” qui traduit les props et évènements entre votre application et le composant externe. Cela facilite les mises à jour ultérieures.

Vérifiez que le composant utilise les variables de thème et classes CSS de votre projet. Uniformisez les couleurs, espacements et typographies pour une intégration homogène.

Notez les changements effectués lors de la copie (champs modifiés, dépendances ajoutées) pour faciliter la maintenance et d’éventuels retours au dépôt d’origine.

Testez le composant dans les cas d’usage réels : dans une liste, en mobile, avec thèmes sombres/clairs. Vérifiez accessibilité, performance et comportements asynchrones.

Si vous clonez un composant depuis un projet partagé, définissez une process pour appliquer les mises à jour : validation, tests d’intégration et éventuelle adaptation des breaking changes.

Confirmez que votre application fonctionne comme SPA (rendu côté client). Ces composants attendent de manipuler le DOM côté client (ex. lecture/écriture de préférence thème).

Au chargement de l’application, restaurez la préférence de thème depuis le stockage local utilisateur et appliquez-la. Assurez-vous que cette initialisation s’effectue uniquement côté client pour éviter des différences d’état à l’affichage.

Pour réduire le poids initial, chargez les dialogues et composants lourds au moment où l’utilisateur peut en avoir besoin (ex. au clic sur “Nouveau projet”) plutôt que systématiquement au chargement.

Si votre SPA navigue entre routes, conservez les états essentiels (ex. préférences thème) de façon persistante. Pour les dialogues, utilisez un état local par page ou un gestionnaire partagé si la modale doit survivre à la navigation.

Testez les composants dans différents écrans : mobile, tablette, desktop. Vérifiez que les modales s’adaptent et que les Loaders n’empêchent pas l’interaction (ex. bouton Annuler accessible).

Anticipez les pertes de réseau : permettez d’annuler, de réessayer et de conserver les données du formulaire temporairement (sauvegarde locale) pour éviter perte d’entrée utilisateur.

Validez les scénarios de bout en bout avec des tests utilisateur ou scénarios manuels : ouvrir/fermer modale, soumission réussie/échouée, bascule thème et rechargement de la page.