Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract components from `@wordpress/components` that have utility in other contexts. #17079

Open
nerrad opened this issue Aug 18, 2019 · 2 comments

Comments

@nerrad
Copy link
Contributor

commented Aug 18, 2019

This is a work in progress issue (right now mostly a placeholder) that I'm going to use to research what components exist in the @wordpress/components package that could have utility outside of the editor context.

Right now the @wordpress/components package is fairly heavy and thus including it as a dependency outside of the admin context is pretty much a no-go. However, there are a few components in this package that could be useful outside of the editor context so there may be some value in extracting them to their own package. I have no idea on naming yet or whether this is even something that will happen, but am using the issue to track candidates for extraction.

There's also some potential here for making the components package more lightweight for general use in the admin as well.

I'll make a more formal proposal/pull once I think I've got a list to work with. Note, I'm excluding input/controls from this list. For the most part, they are styled specifically for use in the WordPress admin context only.

  • Animate
  • Autocomplete (iffy, but including for consideration)
  • Dashicon
  • DateTimePicker (another iffy one. It's still too tightly coupled to the admin context - styling etc - to be easily extracted. However, included because I think something like this could be useful on the frontend for various use-cases - search filters etc).
  • Draggable (this seems like something worth extracting to it's own package)
  • DropZone (this seems like another component worth extracting to it's own package)
  • ExternalLink
  • FocusableIframe (another component I think worth extracting to it's own package)
  • navigateRegions - this is a hoc that I think would be better adding to the @wordpress/a11y (or a new @wordpress/a11y-components) package.
  • withConstrainedTabbing - a hoc I think would be better as a part of the @wordpress/a11y (or a new @wordpress/a11y-components) package.
  • withFallbackStyles
  • withFilters - this seems like a better fit for the @wordpress/compose package.
  • withFocusOutside, withFocusReturn - I wonder if this and other "focus" related components would be better extracted to a new focus specific type package @wordpress/focus-components. Arguably the focus type components would also be good candidates for landing in an a11y specific package.
  • withNotices and other notice components - seems like this would be a better fit for the @wordpress/notices package. However, I realize currently the styling is specific to the WordPress admin. So if extracted to @wordpress/notices would probably need to be super generic styling in the package that is overridden for WP admin use.
  • withSpokenMessages - a hoc I think would be better as a part of the @wordpress/a11y (or a new @wordpress/a11y-components) package.
  • Icon
  • IsolatedEventContainer - seems like a good candidate for it's own package.
  • KeyBoardShortcuts - seems like a good candidate for it's own package.
  • Modal - seems like a good candidate for it's own package
  • NavigableContainer - seems like a good candidate for it's own package.
  • ResizableBox - seems like a good candidate for it's own package.
  • ResponsiveWrapper - seems like a good candidate for it's own package.
  • Sandbox - seems like a good candidate for it's own package (possibly combined with the FocusableIframe component in the same new package)
  • ScrollLock - seems like a good candidate for it's own package.
  • slot and fill components: I think these should be in their own new package.
  • SnackBar (and related components) - I think these should be in the @wordpress/notices package. Similar caveats here as what I wrote about the vanilla notice components (and hoc) above.
  • Spinner
@noisysocks

This comment has been minimized.

Copy link
Member

commented Aug 22, 2019

See also #16709 which has a similar aim of reducing size of @wordpress/components.

@nerrad

This comment has been minimized.

Copy link
Contributor Author

commented Aug 23, 2019

See also #13910 which deals with implementing better control over tree-shaking (via webpack sideeffects config). However that really only helps for implementations directly importing @wordpress/components in builds (as opposed to using as an external via the wp.components global).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.