API Design Guidelines

What this document is

This document outlines the API best practices and guidelines for creating highly reusable UI components/elements that work in any framework or library. The best practices defined here target low level leaf components and may not apply to all use cases of an application or plugin.

What this document is not

This document is not intended to define the best practices and API design of higher level UI components used at the micro-frontend/plugin/application level. While some of the recommendations and best practices outlined in this document are applicable, not all apply outside of the reusable UI element library use case.

Legend

Terminology

• Element: a Web Component defined within the public API of the library
• Component: higher level UI web/framework components in plugins/apps
• Pattern: combination of elements to create a UI rather than creating new extra elements
• Pattern Library: packaged library of patterns/behaviors composed of low level elements
• Plugin/Application: code that consumes or uses the elements
• Consumers: developers/designers that use the UI elements within their products

Deprecation and removal

Breaking removals are eligible for a major release only after the deprecation cycle is complete.

• Add @deprecated JSDoc to the old API with the replacement and removal target.
• Add lint coverage that flags consumer use of the deprecated API.
• Add runtime diagnostics when the deprecated behavior is detectable at runtime.
• Document the migration path and replacement API before removal.
• Keep the old and new APIs side-by-side until downstream consumers have had a full deprecation window.
• Remove the deprecated API only when release notes can point to the deprecation, lint rule, runtime diagnostic, and replacement.

Philosophy

Web standards over frameworks

• Stateless over Stateful
• Composable Patterns over Custom Features
• Common Design Language for developers and designers
• Internationalizable by default
• Accessible by default
• Automated conventions and best practices

Consistent element APIs provide consistent developer experience. The recommendations in this document provide a path of optimal compatibility with other framework integrations, including

• routing/linking
• native form controls / validation
• key navigation
• property/event binding/content projection
• i18n/a11y

<!-- HTML/JavaScript -->
<nve-alert status="success">
  <p nve-text="body">hello there!</p>
</nve-alert>

<script type="module">
  import '@nvidia-elements/core/alert/define.js';
  const alert = document.querySelector('nve-alert');
  alert.closable = true;
  alert.addEventListener('close', (e) => console.log(e))
</script>

<!-- Angular -->
<nve-alert status="success" [closable]="boolProp" (close)="handle($event)">
  <p nve-text="body">hello there!</p>
</nve-alert>

<!-- Lit -->
<nve-alert status="success" ?closable=${boolProp} @close=${e => this.handle(e)}>
  <p nve-text="body">hello there!</p>
</nve-alert>

<!-- Vue -->
<nve-alert status="success" :closable="boolProp" @close="handle">
  <p nve-text="body">hello there!</p>
</nve-alert>

<!-- React/Preact -->
<nve-alert status="success" closable={this.state.boolProp} onClose={this.handle}>
  <p nve-text="body">hello there!</p>
</nve-alert>