Component Naming Conventions

Consistent naming keeps a component library usable as it grows, especially once multiple people are contributing. Here is the naming approach used across Niagara UI components.

 

Use a clear hierarchy: name components from general to specific, for example Button, then ButtonPrimary or ButtonIcon, so related components sort and scan together.

 

Describe function, not appearance: prefer names like AlertBanner over RedBox, since visual details change over time but the component's purpose usually doesn't.

 

Be consistent with prefixes: group related pieces with a shared prefix, such as CardHeader, CardBody, and CardFooter, so their relationship is obvious at a glance.

 

Avoid abbreviations: a name like NavigationMenu is clearer than NavMenu or NvMnu, and the extra characters rarely matter with modern editors and autocomplete.

 

Version carefully: if you need a new variant of an existing component, prefer a clear suffix like ButtonV2 or a documented replacement rather than silently changing existing behavior.

 

A little discipline in naming up front saves a lot of confusion later when a library has hundreds of components.