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

Move Timefilter service ⇒ NP #49491

Merged

Conversation

lizozom
Copy link
Contributor

@lizozom lizozom commented Oct 28, 2019

Summary

Move timefilter ⇒ NP

Dev Docs

Moved the timefilter service to New Platform.

Usage in old platform:

import { TimeRange } from 'src/plugins/data/public';
import { npSetup, npStart } from 'ui/new_platform';

const { timefilter } = npStart.data.timefilter;
const timeRange: TimeRange = timefilter.getTime();
const refreshInterval: RefreshInterval = timefilter.getRefreshInterval()

Usage in new platform:

class MyPlugin {
   public setup(core: CoreSetup, { data }: MyPluginSetupDependencies) {
      const timeRange: TimeRange = data.timefilter.timefilter.getTime();
   }
   public start(core: CoreStart, { data }: MyPluginStartDependencies) {
      const newTimeRange = { from: getYesterday(), to: getNow() }
      data.timefilter.timefilter.setTime(newTimeRange);
   }
}

Checklist

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

For maintainers

@lizozom lizozom self-assigned this Oct 28, 2019
@elasticmachine
Copy link
Contributor

💔 Build Failed

@lizozom lizozom force-pushed the newplatform/data-plugin/move-timefilter-to-NP branch from db7341a to a51d68d Compare October 29, 2019 10:20
@elasticmachine
Copy link
Contributor

💔 Build Failed

@lizozom lizozom force-pushed the newplatform/data-plugin/move-timefilter-to-NP branch from c164407 to cb4042b Compare October 29, 2019 13:02
@lizozom lizozom marked this pull request as ready for review October 29, 2019 13:57
@lizozom lizozom requested a review from a team as a code owner October 29, 2019 13:57
@lizozom lizozom added Feature:NP Migration release_note:plugin_api_changes Contains a Plugin API changes section for the breaking plugin API changes section. Team:AppArch v7.6.0 v8.0.0 labels Oct 29, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app-arch (Team:AppArch)

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

@lizozom lizozom force-pushed the newplatform/data-plugin/move-timefilter-to-NP branch from bfb5b76 to 6aea0e3 Compare October 30, 2019 12:39
@elasticmachine
Copy link
Contributor

💔 Build Failed

@lizozom lizozom requested a review from a team as a code owner October 30, 2019 14:28
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@lizozom lizozom changed the title Move timefilter ⇒ NP Move timefilter and PersistedLog ⇒ NP Oct 30, 2019
@elasticmachine
Copy link
Contributor

💔 Build Failed

Copy link
Contributor

@peteharverson peteharverson left a comment

Choose a reason for hiding this comment

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

ML edit to the chart_utils test LGTM

Copy link
Contributor

@streamich streamich left a comment

Choose a reason for hiding this comment

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

These two seem to be blockers:

  • Importing Index Patterns in the NP data plugin from the LP.
  • Removing type safety in mocks.

Other comments are for discussion.

@@ -44,7 +43,6 @@ export interface DataPluginStartDependencies {
*/
export interface DataSetup {
query: QuerySetup;
timefilter: TimefilterSetup;
Copy link
Contributor

Choose a reason for hiding this comment

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

Instead of removing timefilter from the shim, shall we re-export the timefilter from the NP here.

Copy link
Contributor

Choose a reason for hiding this comment

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

/cc @ppisljar

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I prefer the opposite approach and I've been using it in previous PR.
I've been working with other teams and promotes faster adaptation.
And it allows us to maintain less code.

import { TimelionPluginSetupDependencies } from './plugin';
import { LegacyDependenciesPlugin } from './shim';

const setupPlugins: Readonly<TimelionPluginSetupDependencies> = {
visualizations,
data,
data: npSetup.plugins.data,
Copy link
Contributor

Choose a reason for hiding this comment

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

If timefilter was re-exported in the shim, this change would not be necessary. Also, now if Timelion needs some other service besides timefilter from the data plugin they would need to import the shim and the NP plugin, merge those locally, also import types of both of those and merge those locally.

src/legacy/core_plugins/timelion/public/plugin.ts Outdated Show resolved Hide resolved
export const timeHistory = data.timefilter.history;
export const timefilter = data.timefilter.timefilter;
export const timeHistory = npStart.plugins.data.query.timefilter.history;
export const timefilter = npStart.plugins.data.query.timefilter.timefilter;
Copy link
Contributor

Choose a reason for hiding this comment

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

Is the double timefilter key — .timefilter.timefilter — temporary, or we are planning to keep that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ATM it's just backwards compatible.
Though I'm not a big fan as well.
I'm open to making a follow up PR updating the structure.

src/plugins/data/public/mocks.ts Outdated Show resolved Hide resolved
src/plugins/data/public/query/mocks.ts Show resolved Hide resolved
import { IndexPattern, Field } from '../index_patterns';

// TODO: remove this
import { IndexPattern, Field } from '../../../../../legacy/core_plugins/data/public/index_patterns';
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems like a no-no—importing from the Legacy Platform in the New Platform. My understanding is that we should not be doing this even with TODO comment, but maybe I'm wrong (/cc @ppisljar @joshdover ).

Copy link
Contributor Author

@lizozom lizozom Oct 31, 2019

Choose a reason for hiding this comment

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

Talked about this with @ppisljar.
We decided to go with it, because otherwise we're blocked until IndexPatterns are done. It's a temporary solution that works since it's only a type, and once IndexPatterns are migrated, we'll switch it over.

Copy link
Member

Choose a reason for hiding this comment

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

its only types that we are importing, so this should be ok

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@lizozom
Copy link
Contributor Author

lizozom commented Nov 10, 2019

retest

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@streamich streamich requested review from streamich and removed request for streamich November 11, 2019 11:41
Copy link
Contributor

@streamich streamich left a comment

Choose a reason for hiding this comment

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

Talked with @ppisljar, he is OK for this PR to import legacy Index Patterns from a New Platform plugin, thus removing request for changes.

@streamich streamich dismissed their stale review November 11, 2019 11:44

Talked with @ppisljar, he is OK for this PR to import legacy Index Patterns from a New Platform plugin, thus removing request for changes.

@lizozom
Copy link
Contributor Author

lizozom commented Nov 11, 2019

@streamich thanks, if so is this approved?

@streamich
Copy link
Contributor

@lizozom I did not approve. My understanding of the New Platform migration is that we should never import code from the Legacy Platform in a New Platform plugin.

But @ppisljar seems to be OK with the import in this PR, so I unblocked it in case he wants to approve.

@lizozom
Copy link
Contributor Author

lizozom commented Nov 11, 2019

Don't you feel it's kind of redundant? Anyway @ppisljar could you look then?

Copy link
Member

@ppisljar ppisljar left a comment

Choose a reason for hiding this comment

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

code LGTM

@lizozom lizozom merged commit a72cb85 into elastic:master Nov 11, 2019
lizozom pushed a commit to lizozom/kibana that referenced this pull request Nov 11, 2019
* Move timefilter to NP

* Fixed editor import

* added karma mocks

* More karma mocks

* Change way timefilter is mocked

* Fix timefilter passing in timelion

* attempted revert of mock types
lizozom pushed a commit that referenced this pull request Nov 11, 2019
* Move timefilter to NP

* Fixed editor import

* added karma mocks

* More karma mocks

* Change way timefilter is mocked

* Fix timefilter passing in timelion

* attempted revert of mock types
@lizozom lizozom deleted the newplatform/data-plugin/move-timefilter-to-NP branch November 14, 2019 13:03
@lizozom lizozom changed the title Move timefilter and PersistedLog ⇒ NP Move Timefilter service ⇒ NP Jan 12, 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:plugin_api_changes Contains a Plugin API changes section for the breaking plugin API changes section. v7.6.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants