[sharedUX] Move to Package-based Architecture - #127546
Conversation
d27684c to
13efeb8
Compare
|
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.
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.
This should really be prioritized imho.
majagrubic
left a comment
There was a problem hiding this comment.
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>
spalger
left a comment
There was a problem hiding this comment.
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: |
* [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>
* [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_uxwas refactored and moved to these packages.Plugin
The Shared UX plugin provides stateful, Kibana-specific implementations of the services in
@kbn/sharedux-servicesand 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_uxa 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
NoDataViewdecoupled, 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:
servicesvalue.Pre-wired Context
The Shared UX plugin imports the
SharedUxServicesProviderand populates theservicesusing aservicesFactorythat uses Kibana dependencies to fulfill the contract. This is how consumers of the hooks get to the Kibana version of these services: theSharedUxServicesProviderprovides 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: