Skip to main content

Constants and Configuration

Use const​

Always use const for values that should not be reassigned.

Avoid Literal Display Values​

Never hard-code display strings, types, or labels directly in components. Use constants and i18n values instead.

Example:

// Bad
<Button>Submit</Button>

// Good
<Button>{t('buttons.submit')}</Button>

Multi-Value Constants​

When a constant has multiple attributes, use an object map:

export const taxIdentificationType = {
  ein: { label: "EIN", value: "ein" },
  ssnItin: { label: "SSN/ITIN", value: "ssnItin" },
  foreign: { label: "Foreign", value: "foreign" },
};

export const taxIdentificationTypeOptions = Object.values(
  taxIdentificationType,
);
export const taxIdentificationTypeValues = Object.keys(taxIdentificationType);

Error and Response Codes​

Never compare status codes or messages directly. Use error or response codes:

export const ERROR_CODES = {
  invalidToken: "INVALID_TOKEN_ERR",
  userNotVerified: "USER_NOT_VERIFIED",
  onlyCompanyAllowed: "ONLY_COMPANY_ALLOWED",
};

Example usage:

if (errorCode === ERROR_CODES.invalidToken) {
  return logout();
}

Paths and Route Builders​

Use central route builders for paths:

export const AUTH_ROUTES = {
  login: path(AUTH_ROOT, "/login"),
};

export const DASHBOARD_ROUTES = {
  approval: (approvalId: string) =>
    path(DASHBOARD_ROOT, `/approvals/${approvalId}`),
};

i18n Usage​

All user-facing text should come from i18n values, including tabs and table headers.

Example:

const TABS = [
  { id: "summary", label: t("tabs.summary") },
  { id: "details", label: t("tabs.details") },
];

Frontend and Backend Constants​

Frontend and backend constants do not need to match. The API should translate between them based on business rules.

Last updated on