Why now
Five components joined Common in a short period — ComboBox, ToggleGroup, Tabs, TagGroup, Breadcrumbs (#279, #287) — every one of them requested by a single application migrating away from hand-rolled widgets. Each was individually justifiable. Nothing written down says which of them the library should own, so the effective rule was "a consumer asked and the implementation was sound".
The documentation states a narrow purpose — React composition around Arc proxies and selected interaction primitives — and tells consumers to use native HTML or a product-owned presentational component for a one-off element that has no Cratis behavior. That is a boundary in prose, but it does not decide a case: Breadcrumbs, for instance, owns almost no behaviour beyond marking the current page.
The existing classification decision (Documentation/decisions/0002-component-classification.md) records what kind of thing each component is. It does not say whether a new one should exist.
Proposed
A short decision record answering the admission question, in the same series. A starting proposal:
Components owns a primitive when both hold: its correct implementation requires focus, keyboard, overlay, collection or internationalization behaviour that an application would otherwise reimplement and get wrong; and it is needed either by an Arc-bound composite in this library or by more than one application.
A component that is only markup and tokens stays with the application, however often it is asked for.
Against that rule, of the recent five: ComboBox, ToggleGroup and TagGroup clearly qualify on behaviour; Tabs qualifies; Breadcrumbs is the marginal case and would need the second limb to carry it.
The point is not to relitigate those five. It is that the next request should meet a written standard, and the answer to a reasonable request should sometimes be no.
Why now
Five components joined
Commonin a short period —ComboBox,ToggleGroup,Tabs,TagGroup,Breadcrumbs(#279, #287) — every one of them requested by a single application migrating away from hand-rolled widgets. Each was individually justifiable. Nothing written down says which of them the library should own, so the effective rule was "a consumer asked and the implementation was sound".The documentation states a narrow purpose — React composition around Arc proxies and selected interaction primitives — and tells consumers to use native HTML or a product-owned presentational component for a one-off element that has no Cratis behavior. That is a boundary in prose, but it does not decide a case:
Breadcrumbs, for instance, owns almost no behaviour beyond marking the current page.The existing classification decision (
Documentation/decisions/0002-component-classification.md) records what kind of thing each component is. It does not say whether a new one should exist.Proposed
A short decision record answering the admission question, in the same series. A starting proposal:
Against that rule, of the recent five:
ComboBox,ToggleGroupandTagGroupclearly qualify on behaviour;Tabsqualifies;Breadcrumbsis the marginal case and would need the second limb to carry it.The point is not to relitigate those five. It is that the next request should meet a written standard, and the answer to a reasonable request should sometimes be no.