Add a status component to the examples design system - #231
Conversation
The 51Did creator context example reports one outcome per check and an overall verdict, and there was nothing in the examples layer to style that, so it would have carried its own colours inline and drifted from the design system. Four states rather than two, because a pass and a fail do not cover what these examples report. A check that could not be judged on the connection is not a failure, so it is grey and unweighted, and a verdict where some checks held and others did not is not the same as one where nothing held, so it is amber. An example that only ever passes or fails uses the first two states and ignores the rest. Colours come from the existing palette, being lime-darker, red, orange and grey-darker, so nothing new enters the token set. A value class is included for identifiers and other verbatim strings that have to wrap rather than stretch the table they sit in. Written for the 51Did example but named generally, so any example reporting a pass or a fail uses it rather than inventing its own.
|
Rollout note, so the vendored copies do not drift. These assets are consumed as a vendored build, not as a live link. The device detection and IP intelligence example repositories carry fifteen copies of So this change reaches consumers only when a new One gap worth knowing: 51Degrees/cloud does not currently run the |
A full size button in a table cell forces the column wide enough to wrap its own label, which is what happens to the copy button beside each identifier in the 51Did example. This keeps the control to the row's height and stops the label breaking across lines. Sits with the table it belongs to rather than as a button modifier, because it is about the cell it sits in, and keeping it in the examples layer means the documentation and conference builds are untouched.
|
Second commit adds A full size button in a cell forces the column wide enough to wrap its own label, which is what happens to the copy button beside each identifier in the 51Did example. The action keeps the control to the row's height and stops the label breaking across lines. It sits in
|
1 participant
Adds a status component to the examples layer of the design system, so
an example reporting the outcome of a check uses house classes rather
than its own inline colours.
Why
The 51Did creator context example (51Degrees/cloud#224) reports one
outcome per check and a single overall verdict. The examples layer has
an alert, a table, a form, a map, a layout and a message, but nothing
for "this check passed" or "this check failed", so the example would
have carried its own colours in a
<style>block and drifted from thedesign system the moment either changed.
What
06-examples/07-status.scss, with four states rather than two:.c-eg-status--pass$colour-lime-darker.c-eg-status--fail$colour-red.c-eg-status--part$colour-orange.c-eg-status--none$colour-grey-darker, unweightedTwo of those states need explaining. A check that could not be judged
on the connection is not a failure, so it is grey and deliberately
unweighted, which stops a reader scanning a column from reading an
absence as an outcome. A verdict where some checks held and others did
not is not the same as one where nothing held, so it is amber rather
than red. An example that only ever passes or fails uses the first two
and ignores the rest.
There is also
.c-eg-valuefor identifiers and other verbatim strings,which have to wrap rather than stretch the table they sit in.
No new tokens. Every colour comes from the existing palette in
00-abstract/00-colours.scss.Checked
Built with
npm run build:cssinpattern-library. The rest ofexamples-main.min.cssis byte-identical to the copy currentlyvendored in the example repositories, and the file grows from 12,215 to
12,553 bytes, so this adds the component and changes nothing else.
Written with AI assistance and needs human review before merge.