Is your feature request related to a problem? Please describe.
This issue is part of a review on the naming, structure, and composition of the UI components as brought up in #16367
Non-UI components
Audit
While reviewing the components, it was clear that some components were not UI components, and it made browsing them confusing and hard to understand, especially those with empty documentation.
During the audit, I categorized each component into one of 4 buckets:
- Utility: non-visual component that didn't make sense to categorize with base UI components
- Specific UI: did not seem general enough for a base UI set. The components were too specific to a certain part of the product.
- Atomic UI: these are supportive UI components that are not useful in isolation (e.g. popover). These should not be listed with the other base UI components on the doc site.
- HTML: these appear to be helper components for creating basic HTML elements.
Suggestions
Generally, I think there are some improvements to the way we publish npm packages or splitting components into separate folders.
- Utility: I would put these in a “utility” folder or some other way of separating them. This assumes that these utilities are required for the base components to function and that it doesn’t make sense to make them a general-use utility available in a separate package (e.g. @wordpress/components-utilities).
- Specific UI: Move the component into a separate npm package (e.g. @wordpress/components-editor)
- Atomic UI: These seem like lower level components that shouldn't be listed alongside other base UI components. Some design libraries have an "API" section. Some don't list it at all on their site.
- HTML: These could be grouped in their own folder and in their own section on the website.
| Component |
Category |
| Popover |
Atomic UI |
| BaseControl |
Atomic UI |
| Dropdown |
Atomic UI |
| BlockQuotation |
HTML |
| HorizontalRule |
HTML |
| Svg |
HTML |
| ColorIndicator |
Specific UI |
| ColorPalette |
Specific UI |
| ColorPicker |
Specific UI |
| FocalPointPicker |
Specific UI |
| FontSizePicker |
Specific UI |
| Placeholder |
Specific UI |
| Animate |
Utility |
| Disabled |
Utility |
| Draggable |
Utility |
| Focusablelframe |
Utility |
| NavigateRegions |
Utility |
| HigherOrder |
Utility |
| WithConstrainedTabbing |
Utility |
| WithFallbackStyles |
Utility |
| WithFilters |
Utility |
| WithFocusOutside |
Utility |
| WithFocusReturn |
Utility |
| WithNotices |
Utility |
| WithSpokenMessages |
Utility |
| IsolatedEventContainer |
Utility |
| KeyboardShortcuts |
Utility |
| NavigableContainer |
Utility |
| QueryControls |
Utility |
| ResizableBox |
Utility |
| ResponsiveWrapper |
Utility |
| Sandbox |
Utility |
| ScrollLock |
Utility |
| ServerSideRender |
Utility |
| Slotfill |
Utility |
Feedback
The feedback I'm looking for is related to naming, structure, and composition. I'm not looking for visual feedback of the components. I'm also not examining each prop for each component; only the ones that I think are relevant for the audit. I know this issue is a lot to take in, and I appreciate any feedback you have.
Is your feature request related to a problem? Please describe.
This issue is part of a review on the naming, structure, and composition of the UI components as brought up in #16367
Non-UI components
Audit
While reviewing the components, it was clear that some components were not UI components, and it made browsing them confusing and hard to understand, especially those with empty documentation.
During the audit, I categorized each component into one of 4 buckets:
Suggestions
Generally, I think there are some improvements to the way we publish npm packages or splitting components into separate folders.
Feedback
The feedback I'm looking for is related to naming, structure, and composition. I'm not looking for visual feedback of the components. I'm also not examining each prop for each component; only the ones that I think are relevant for the audit. I know this issue is a lot to take in, and I appreciate any feedback you have.