Files
hpe-branding/06-components-templates.md
claude 0730557624 Initial mirror of the HPE Design System
Readable mirror of https://design-system.hpe.design, sourced from
github.com/grommet/hpe-design-system (Apache-2.0) at commit 567c4d5
(2026-07-16).

The upstream site is a client-rendered Next.js export with no sitemap; it
returns a 1.5 KB empty shell to curl. This repo is the same guidance in plain
Markdown with every value resolved, plus the assets checked in.

Docs: scope and authority model, brand foundations with resolved color and
spacing tables, the design token tiers and version map, UI copy rules,
accessibility conformance and the responsibility split, the component and
template inventory, and an adoption/review checklist.

Assets: 452 SVG icons, 5 HPE and Aruba word-marks, 282 documentation graphics.

HOWTO-mirror-the-design-system.md is a verified runbook for rebuilding this
from scratch against a newer upstream.

Colors were resolved programmatically, not transcribed: token JSON stores
references, not values.

Apache-2.0 upstream. Note that it covers copyright, not trademark; Brand
Central remains authoritative for the HPE marks.
2026-07-30 08:34:50 -04:00

4.5 KiB

06 — Components and templates

Two layers with different jobs. Components are single UI elements. Templates are compositions of components that solve a recurring product problem, with the design decisions already made.

The practical value of the template layer is that it settles arguments. When a team debates how a wizard should behave or where a destructive confirmation goes, there is an HPE answer already written down.

Components

48 documented component pages, plus an all-components index. Grouped by what they do:

Layout and structure box, grid, page, main, header, footer, pageheader, toolbar, layer

Input textinput, textarea, maskedinput, dateinput, fileinput, rangeinput, search, select, selectmultiple, checkbox, checkboxgroup, radiobuttongroup, togglegroup

Action and navigation button, anchor, menu, tabs, pagination

Content display card (with call-to-action-card and navigational-card variants), accordion, avatar, namevaluelist, tag, tip

Feedback and state notification, spinner, skeleton

Data This is the largest family and the one most relevant to any management or operations UI: data, datatable, datatablecolumns, datatablegroupby, dataview, datafilter, datafilters, datasearch, datasort, datasummary

The data component is the container that wires the others together, giving you search, filter, sort, and summary against one dataset without hand-wiring state. Worth knowing before anyone builds a filterable table from scratch.

Templates

27 template pages covering 26 topics.

Navigation (five separate patterns, each for a different information shape)

  • navigation (the overview)
  • ascending-navigation — moving up a hierarchy
  • drill-down-navigation — moving down into detail
  • side-to-side-navigation — moving between peers
  • matrix-navigation — moving across two dimensions
  • global-header

Layout

  • page-layouts
  • content-layouts
  • dashboards

Data interaction

  • filtering
  • lists
  • selector
  • datatable-customization
  • scrolling-and-pagination

Forms and flows

  • forms, with a sub-page on managing-child-objects
  • wizard
  • double-confirmation — the pattern for destructive actions
  • empty-state

Notifications (three placements, three different jobs)

  • global-notifications — system-wide, persistent
  • inline-notifications — attached to content
  • toast-notifications — transient

Other

  • status-indicator
  • popover
  • code-blocks
  • internationalization
  • user-feedback-collection

Which layer to reach for

The stated token rule applies here by analogy: start with the most specific thing that exists.

  1. Is there a template for this problem? Use it. The composition decisions are made.
  2. No template but components exist? Compose them.
  3. Neither? Build from tokens, and consider raising it in #hpe-design-system, since a gap that affects you likely affects others.

Learn

Four tutorials, aimed at people new to Grommet rather than at design decisions:

  • grid-fundamentals-part-one
  • the-box-model-part-one
  • how-to-add-additional-controls-to-a-toolbar
  • how-to-add-search-and-filter-to-datatable-with-data

The "part one" naming on two of them with no part two suggests this section was started and not finished. Treat it as a bonus, not a curriculum.

Reading component docs without the website

The site renders in the browser and returns no useful content to curl. To read a component's guidance programmatically, go to the MDX source:

https://github.com/grommet/hpe-design-system
  → apps/docs/src/pages/components/<name>.mdx
  → apps/docs/src/pages/templates/<name>.mdx

Raw file access works over raw.githubusercontent.com. The MDX carries the prose and the best-practice do/don't pairs; the live examples are React components imported from apps/docs/src/examples/.

Component API reference (props) lives on Grommet's own site, v2.grommet.io/<component>?theme=hpe, not in the design system docs. The design system says when and why; Grommet says what the props are.

Open questions

  • How much of the component set is HPE-specific versus plain Grommet with a theme applied? This decides how much of the Grommet ecosystem transfers.
  • Are the data components performant at the row counts a real usage dashboard needs, or do they assume paged server-side data?
  • Is there a template for the case of an application embedded inside another HPE console, where the global header is owned by the host?