Nommage

• Suivez les lignes directrices de cette feuille de triche de nommage .

• Utilisez camelCase pour les variables, fonctions, méthodes et props. Utilisez PascalCase pour les composants React, les classes et les noms de types exportés.

• Utilisez kebab-case pour les noms de fichiers et de dossiers.

• Les composants doivent contenir le suffixe .component dans leur nom (par exemple user.component.tsx). Cette nomenclature est utilisée pour distinguer les composants des autres fichiers tels que les ressources, les feuilles de style et les tests, et détermine où l’outil i18next-parser extrait les clés et chaînes de traduction. Les clés et chaînes de traduction ne seront pas extraites des fichiers qui ne correspondent pas aux globs dans le script extract-translations du package.

• Les composants spécialisés utilisent des suffixes propres à leur objectif au lieu du suffixe de base .component. Ils incluent :

  • .extension pour les composants qui rendent des extensions par exemple lab-order-basket-panel.extension.tsx  pour l’extension Lab Order Basket panel.
  • .modal pour les composants qui rendent des modales par exemple delete-condition.modal.tsx  pour la modale Delete Conditions.
  • .workspace pour les composants qui rendent des formulaires dans l’espace de travail par exemple order-basket.workspace.tsx  pour l’espace de travail Order Basket.

• Gardez le script extract-translations aligné avec les suffixes utilisés dans le package. Les modules générés analysent .component.tsx, .extension.tsx, .modal.tsx et src/index.ts par défaut ; ajoutez src/**/*.workspace.tsx si un fichier d’espace de travail contient des chaînes traduisibles.

• Les fichiers de test unitaire et d’intégration doivent contenir le suffixe .test dans leur nom (par exemple user.test.tsx). N’incluez pas le mot component dans le nom du fichier de test.

• Les tests e2e Playwright doivent contenir le suffixe .spec dans leur nom (par exemple user.spec.ts).

• Les feuilles de style ne doivent pas contenir .component dans leur nom. Nommez-les d’après le composant ou la fonctionnalité qu’elles stylent, généralement avec l’extension .scss (par exemple user.scss pour user.component.tsx). Utilisez .module.scss uniquement lorsque le package utilise intentionnellement les modules CSS.

• Les fichiers de ressource qui encapsulent la logique de récupération de données doivent contenir le suffixe .resource dans leur nom (par exemple user.resource.ts). C’est pour les distinguer des autres fichiers tels que les composants, les feuilles de style et les tests.

• Utilisez les extensions appropriées pour les fichiers TypeScript :

  • Utilisez l’extension .tsx pour les fichiers qui contiennent du JSX.

  // user.component.tsx
  function UserComponent(props: UserComponentProps) {
    return <div>User Component</div>;
  }

  • Utilisez l’extension .ts pour les fichiers qui ne contiennent pas de JSX.

  // user.resource.ts
  export async function fetchUser() {
    const response = await openmrsFetch<User>('/ws/rest/v1/user');
    return response.data;
  }

  Dans la plupart des cas, vous ne devriez pas avoir besoin d’utiliser l’extension .tsx pour les fichiers en dehors du répertoire src.

• Suivez le guide de nomenclature du système d’extensions lors du nommage de vos extensions et emplacements d’extension.

• Utilisez le nom du fichier comme nom du composant. Par exemple, user.component.tsx doit contenir un composant nommé UserComponent. Cela facilite la recherche du composant dans la base de code.

• Évitez d’utiliser les noms de props de composants DOM à des fins différentes. Par exemple, évitez d’utiliser la prop style pour passer des options de configuration. Utilisez plutôt un nom de prop descriptif qui correspond à son objectif, tel que config ou options.

• Utilisez camelCase pour les noms de props. C’est cohérent avec la convention de nommage pour les variables, fonctions et méthodes.

• Les clés de traduction doivent être en camelCase tandis que les chaînes de traduction doivent être en sentence case. Par exemple, firstName est une clé de traduction tandis que First name est sa chaîne de traduction correspondante.

• Les modules frontend dans les monorepos doivent avoir des noms qui commencent par le préfixe esm-. Le nom du module doit décrire ce que fait le module. Par exemple, esm-user-management est un bon nom pour un module frontend gérant les préoccupations de gestion des utilisateurs et esm-patient-chart est un bon nom pour un module frontend gérant les préoccupations du dossier patient.

• Les props de gestionnaires d’événements doivent être nommées d’après l’événement qu’elles gèrent, par exemple onClick pour un gestionnaire de clic. Par convention, les props de gestionnaires d’événements doivent commencer par le préfixe on, suivi d’une lettre majuscule.

• Les fonctions de mise à jour d’état doivent être nommées d’après l’état qu’elles mettent à jour. Par exemple, setFirstName est un bon nom pour une fonction de mise à jour d’état qui met à jour l’état firstName.

• Le nommage de vos branches est généralement une question de préférence personnelle. Cependant, en cas de doute, nommez vos branches en utilisant le type de commit conventionnel  auquel votre travail se conforme, suivi d’un slash et d’une courte description séparée par des tirets du travail. De bons exemples incluent : feat/debounced-order-basket-search, fix/missing-translation, chore/bump-dependencies et test/add-order-basket-coverage.