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

Remove SavedObjectRegistryProvider from codebase #53455

Conversation

kertal
Copy link
Member

@kertal kertal commented Dec 18, 2019

Summary

Follow up of #51562, cleanup SavedObjectRegistryProvider from the codebase. Part of this PR is also moving ui/directives/saved_object_finder to timelion, since it's only used there. `
Note: should be reviewed after merging : #53293

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

- [ ] This was checked for cross-browser compatibility, including a check against IE11
- [ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
- [ ] Documentation was added for features that require explanation or tutorials
- [ ] Unit or functional tests were updated or added to match the most common scenarios
- [ ] This was checked for keyboard-only and screenreader accessibility

For maintainers

- [ ] This was checked for breaking API changes and was labeled appropriately
- [ ] This includes a feature addition or change that requires a release note and was labeled appropriately

@kertal kertal self-assigned this Dec 19, 2019
@kertal kertal changed the title remove saved object registry provider Remove SavedObjectRegistryProvider from codebase Dec 19, 2019
@kertal kertal marked this pull request as ready for review December 19, 2019 10:58
@kertal kertal requested a review from a team December 19, 2019 10:58
@kertal kertal added the release_note:skip Skip the PR/issue when compiling release notes label Dec 19, 2019
@flash1293
Copy link
Contributor

@elasticmachine merge upstream

@kertal
Copy link
Member Author

kertal commented Dec 20, 2019

jenkins, test this (unrelated error before)

return {
dashboardConfig: injector.get('dashboardConfig'),
savedObjectRegistry,
savedDashboards: injector.get('savedDashboards'),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like we also don't need to inject saved dashboards anymore because we can create the class inside the app using the helper (might be done in a separate PR)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thx, I've taken care of this, planned to do it in a 2020 PR, but the time is now!
did it the same way with visualize, so the injected variables are just used for savedObjectManagementRegistry. now the first 2020 PR will be cleanup of this 🔨

Copy link
Contributor

@flash1293 flash1293 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall fine, but we should resolve the import issues with visualize/dashboard explained in the comments

@@ -33,6 +33,7 @@ import { DashboardListing, EMPTY_FILTER } from './listing/dashboard_listing';
import { addHelpMenuToAppChrome } from './help_menu/help_menu_util';
import { registerTimefilterWithGlobalStateFactory } from '../../../../ui/public/timefilter/setup_router';
import { syncOnMount } from './global_state_sync';
import { savedObjectLoaderDashboard } from './saved_dashboard/saved_dashboards';
Copy link
Contributor

@flash1293 flash1293 Dec 20, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This import isn't allowed because it uses services directly without going through plugin.ts (the linting PR will start flagging this).

Suggestion to do this cleanly:

  • Create the saved_dashboard class and service in the start phase of the dashboard plugin and
  • expose it through the contract.
  • Then have a little wrapper in legacy world registering the class from the shimmed contract into angular for the management view.

This would put the class creation where it belongs, doesn't cross legacy/shimmed boundaries, wouldn't block moving the dashboard app into NP and is still compatible with the angular setup.

Basically it would mean moving this part into the plugin.ts:

const savedObjectsClient = npStart.core.savedObjects.client;
const services = {
  savedObjectsClient,
  indexPatterns: npStart.plugins.data.indexPatterns,
  chrome: npStart.core.chrome,
  overlays: npStart.core.overlays,
};

const SavedDashboard = createSavedDashboardClass(services);
return {
  savedObjectLoaderDashboard: new SavedObjectLoader(
  SavedDashboard,
  savedObjectsClient,
  npStart.core.chrome
)
};

And keeping just this part in legacy saved_dasboard:

// This is the only thing that gets injected into controllers
module.service('savedDashboards', () => dashboardStart.savedObjectLoaderDashboard);

Copy link
Member Author

@kertal kertal Dec 20, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thx, yes, the upcoming linting improvement will complain about this changes. So I've solved it the "Discover way"™" for now, services created twice, and will clean this by removing module.service('savedDashboards'... in a follow up PR

};
return createSavedSearchesService(services);
});
module.service('savedSearches', () => savedSearches);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use the same pattern as suggested above for dashboard here (only creating the service once and exposing through the contract, but that way is also fine because it's just created twice, once for "inside" the app and once for the global registry. That approach would also be OK for me for dashboard.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

♩ ♪ ♫ ♬ ♭ ♮ ♯ 🎼 🎵 🎶 I did it discover way ♩ ♪ ♫ ♬ ♭ ♮ ♯ 🎼 🎵 🎶

@@ -25,6 +25,7 @@ import { i18n } from '@kbn/i18n';

import { getServices } from '../kibana_services';
import { wrapInI18nContext } from '../legacy_imports';
import { savedObjectLoaderVisualize } from '../saved_visualizations/saved_visualization_register';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same problem as with dashboard here

const Private = injector.get<IPrivate>('Private');

const savedObjectRegistry = Private(SavedObjectRegistryProvider);

return {
dashboardConfig: injector.get('dashboardConfig'),
Copy link
Contributor

@flash1293 flash1293 Dec 20, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉Down to one, nice! We should probably just move that flag into kibana_legacy, then dashboard is almost ready to go (not in this PR though)

Copy link
Contributor

@flash1293 flash1293 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't test again but code changes LGTM once green CI. We should add a dec docs section here explaining the change as 3rd party plugin might use the registry to integrate with visualizations/dashboards.

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@elastic elastic deleted a comment from elasticmachine Dec 21, 2019
@kertal kertal merged commit b921987 into elastic:master Dec 21, 2019
kertal added a commit to kertal/kibana that referenced this pull request Dec 21, 2019
jloleysens added a commit to jloleysens/kibana that referenced this pull request Dec 30, 2019
…le-saved-objects

* 'master' of github.com:elastic/kibana: (250 commits)
  Allow chromeless applications to render via non-/app routes (elastic#51527)
  Add server rendering service to enable standalone route rendering (elastic#52161)
  Possibility to filter when testing scripted fields (elastic#35379) (elastic#44220)
  Update maps telemetry mappings to account for recent updates (elastic#53803)
  [Maps] Only show legend when layer is visible (elastic#53781)
  remove use of experimental fs.promises api (elastic#53346)
  [APM] Add log statements for flaky test (elastic#53775)
  [APM] Transaction page throws unhandled exception if transactions doesn't have  `http.request` (elastic#53760)
  Licensing plugin functional tests (elastic#53580)
  [Lens] Disable saving visualization until there are no changes to the document (elastic#52982)
  [Monitoring] Added safeguard for some EUI components (elastic#53318)
  [Vega] Shim new platform - cleanup vega_visualization dependencies (elastic#53605)
  Display changed field formats without requiring hard page refresh. (elastic#53746)
  Upgrade EUI to v17.3.1 (elastic#53655)
  [APM] Fix missing apm indicies (elastic#53541)
  Disable inspector for timelion (elastic#53747)
  Clean up search servie (elastic#53701)
  [Dashboard] Grid: removing double handler (elastic#53707)
  Remove SavedObjectRegistryProvider from codebase (elastic#53455)
  Move ui/courier into data shim plugin (elastic#52359)
  ...
jkelastic pushed a commit to jkelastic/kibana that referenced this pull request Jan 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:NP Migration release_note:skip Skip the PR/issue when compiling release notes Team:Visualizations Visualization editors, elastic-charts and infrastructure v7.6.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants