-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[sharedUX] Move to Package-based Architecture #127546
Conversation
d27684c
to
13efeb8
Compare
src/plugins/shared_ux/public/components/empty_state/no_data_views/no_data_views.stories.tsx
Show resolved
Hide resolved
src/plugins/shared_ux/public/components/empty_state/no_data_views/no_data_views.test.tsx
Show resolved
Hide resolved
src/plugins/shared_ux/public/components/empty_state/no_data_views/no_data_views.stories.tsx
Show resolved
Hide resolved
I didn't mean to "request changes", just wrote some comments 😬 But since it's already there, it can read as "no merging until Maja understands how are the services wired" 😅 |
@elasticmachine merge upstream |
15785cb
to
dddafc0
Compare
* plugins-- we have to set this to `unknown`. If and when `DataView` is exported from a | ||
* stateless package, we can remove this. | ||
*/ | ||
type DataView = unknown; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I accidentally left a comment in the PoC PR, so I'll just leave it here 😅
https://github.com/elastic/kibana/pull/127419/files#r826252775
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should really be prioritized imho.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The architectural change looks good. I would just suggest moving that comment to my question to the PR description itself, for easier reference later on.
* [shared-ux][packages] 2. Create Storybook Package * [shared-ux][packages] 3. Create Utility Package (#127549) * [shared-ux][packages] 3. Create Utility Package * [shared-ux][packages] 4. Create Components Package (#127551) Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for moving more to packages!
beda172
to
26b25e3
Compare
@elasticmachine merge upstream |
@elasticmachine merge upstream |
💛 Build succeeded, but was flakyTest Failures
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
async chunk count
ESLint disabled in files
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sass file move LGTM 😉
* [shared-ux][packages] 1. Create Services Package * Address review feedback * [shared-ux][packages] 2. Create Storybook Package (elastic#127548) * [shared-ux][packages] 2. Create Storybook Package * [shared-ux][packages] 3. Create Utility Package (elastic#127549) * [shared-ux][packages] 3. Create Utility Package * [shared-ux][packages] 4. Create Components Package (elastic#127551) Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> * Merging * Adding docs * A few fixes * Fix TS types * Fix TS types * Fix i18n Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Summary
This PR moves portions of the SharedUX plugin out of the plugin and into packages.
Why?
With only a few components, we've run into issues with circular dependencies. The reason being our plugin is consuming code and types from other plugins, and once we do, that plugin can't use our plugin or its components. To mitigate this, we need to keep Shared UX as dependency free as possible.
One of the approaches @majagrubic explored was moving pure components to another plugin to be consumed by dependency plugins. While it worked, we all agreed it wasn't ideal.
Talking with ops, it became clear our assets don't actually need a plugin lifecycle to operate. So I took some time this evening to decouple our components, services and utilities to packages.
Packages
@kbn/sharedux-services
- Our base service abstraction definitions and mocks.@kbn/sharedux-storybook
- All storybook-related code, including a SB-impl of our service layer.@kbn/sharedux-utility
- A home for utility code.@kbn/sharedux-components
- React componentsCode from
src/plugins/shared_ux
was refactored and moved to these packages.Plugin
The Shared UX plugin provides stateful, Kibana-specific implementations of the services in
@kbn/sharedux-services
and a React context provider that wires components from@kbn/sharedux-components
. Any plugin that is not a dependency for our services can makesrc/plugins/shared_ux
a dependency and consume a pre-wired context that will make components from@kbn/sharedux-components
"just work". To make life even easier, the Shared UX plugin re-exports these components, so this becomes an implementation detail.The nice thing is, dependency plugins that still need to use components from Shared UX but need to avoid the circular dependency can either work with us to hoist the dependency, or consume the pure component from
@kbn/sharedux-components
, (as we attempted with #126491). I have no doubt there is a better work-around in the medium term, but we need to start somewhere.I'll flesh out the rest of the details shortly, but I wanted to get this architecture out for feedback before we create more components. I know there's a pressing need to get
NoDataView
decoupled, so this PR becomes pressing, as well.How to use services and components after this change
When a consumer of our components and services wants to use them, they have two choices:
services
value.Pre-wired Context
The Shared UX plugin imports the
SharedUxServicesProvider
and populates theservices
using aservicesFactory
that uses Kibana dependencies to fulfill the contract. This is how consumers of the hooks get to the Kibana version of these services: theSharedUxServicesProvider
provides the API to those hooks, (and thus the components).Wiring Manually
You can consider the code in the Shared UX plugin to be a manual wiring of the Provider for components, but Storybook and Jest are also examples: