Naming

• Follow the guidelines in this naming cheatsheet .

• Use camelCase for variables, functions, methods, and props. Use PascalCase for React components, classes, and exported type names.

• Use kebab-case for file names and folder names.

• Components should contain the .component suffix in their name (e.g. user.component.tsx). This nomenclature is used to distinguish components from other files such as resources, stylesheets, and tests, and determines where the i18next-parser tool extracts translation keys and strings from. Translation keys and strings will not be extracted from files that do not match the globs in the package’s extract-translations script.

• Specialized components use purpose-specific suffixes instead of the base .component suffix. They include:

  • .extension for components that render extensions e.g. lab-order-basket-panel.extension.tsx  for the Lab Order Basket panel extension.
  • .modal for components that render modals e.g. delete-condition.modal.tsx  for the Delete Conditions modal.
  • .workspace for components that render forms in the workspace e.g. order-basket.workspace.tsx  for the Order Basket workspace.

• Keep the extract-translations script aligned with the suffixes used in the package. Generated modules scan .component.tsx, .extension.tsx, .modal.tsx, and src/index.ts by default; add src/**/*.workspace.tsx if a workspace file contains translatable strings.

• Unit and integration test files should contain the .test suffix in their name (e.g. user.test.tsx). Do not include the word component in the test file name.

• Playwright e2e tests should contain the .spec suffix in their name (e.g. user.spec.ts).

• Stylesheets should not contain .component in their name. Name them after the component or feature they style, usually with the .scss extension (for example, user.scss for user.component.tsx). Use .module.scss only when the package is intentionally using CSS Modules.

• Resource files that encapsulate data fetching logic should contain the .resource suffix in their name (e.g. user.resource.ts). This is to distinguish them from other files such as components, stylesheets, and tests.

• Use appropriate extensions for TypeScript files:

  • Use the .tsx extension for files that contain JSX.

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

  • Use the .ts extension for files that do not contain JSX.

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

  In most cases, you shouldn’t need to use the .tsx extension for files outside the src directory.

• Follow the extension system nomenclature guide when naming your extensions and extension slots.

• Use the file name as the component name. For example, user.component.tsx should contain a component named UserComponent. This makes it easier to find the component in the codebase.

• Avoid using DOM component prop names for different purposes. For example, avoid using the style prop to pass configuration options. Instead, use a descriptive prop name that matches its purpose, such as config or options.

• Use camelCase for prop names. This is consistent with the naming convention for variables, functions, and methods.

• Translation keys should be in camelCase whereas translation strings should be in sentence case. For example, firstName is a translation key whereas First name is its corresponding translation string.

• Frontend modules in monorepos should have names that start with the esm- prefix. The name of the module should describe what the module does. For example, esm-user-management is a good name for a frontend module handling user management concerns and esm-patient-chart is a good name for a frontend module handling patient chart concerns.

• Event handler props should be named after the event they handle, such as onClick for a click handler. By convention, event handler props should start with the on prefix, followed by a capital letter.

• State updater functions should be named after the state they update. For example, setFirstName is a good name for a state updater function that updates the firstName state.

• What to name your branches is typically down to personal preference. However, when in doubt, name your branches using the conventional commit  type that your work conforms to, followed by a slash and a short dash-separated description of the work. Good examples include: feat/debounced-order-basket-search, fix/missing-translation, chore/bump-dependencies, and test/add-order-basket-coverage.