Skip to content

Implement the dismiss action for Web Components #387

Description

@nathanacurtis

Problem

ADR 087 introduces anatomy.<element>.actions, a second annotation key for what activating an element does rather than what it is. The first concept, dismiss, is implemented for React and not for Web Components.

Today an annotated component transforms to a working React scaffold and an unchanged custom element — the action is read into the spec, and the Web Components emitter ignores it. That is safe (the vocabulary is open, so unrecognized values are ignored) but it means the two targets disagree about what the same spec means.

What React does

const [dismissed, setDismissed] = React.useState(false);
if (dismissed) return null;
…
<DeIconButton {...{ onClick: () => { setDismissed(true); p.onDismiss?.(); } }} />

Three properties worth carrying over:

  • The component removes itself and notifies the consumer through onDismiss. Its parent's state is untouched, which is why the callback exists.
  • On an instance the handler routes into the composed component rather than onto the wrapper. A handler on the wrapper works only by event bubbling and sits on an element no keyboard user can activate.
  • Where a prop is bound, it re-syncs when that prop changes, so setting it back re-shows the component. Without this, a Storybook control toggles nothing — the same defect togglebutton had.

What Web Components should do

Per the docs page, the custom element sets hidden on the host rather than calling this.remove(). Removal is irreversible and a scaffold should not do anything a consumer cannot undo; hidden disappears the component and can be reversed.

It should also dispatch a composed CustomEvent alongside the callback property, matching how togglebutton already emits <prop>-change — events are how custom elements communicate outward, and they cross the shadow boundary and frameworks in a way callbacks do not.

Out of scope

Focus management, deliberately. Activating a control that then ceases to exist drops focus to the document; where focus should go depends on what surrounded the component, which the spec does not describe. React does not handle it either, and both the docs page and ADR 087 state the limit rather than hiding it. This is a scaffold-grade decision, not an oversight.

Notes

The action is read into the spec already — specs-from-figma populates anatomy.<element>.actions for both targets. Only the Web Components emission is missing.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Fields

Priority

Low

Projects

  • Status
    Backlog

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions