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

[NP][Discover] Move discover into new platform #63473

Merged
merged 42 commits into from
May 4, 2020

Conversation

sulemanof
Copy link
Contributor

@sulemanof sulemanof commented Apr 14, 2020

Summary

Part of #60097

Most of the changes are file transfer into new platform and related paths changes.

The main changes are:

  • both plugin initializers src/plugins/discover/public/plugin.ts and src/legacy/core_plugins/kibana/public/discover/plugin.ts were merged into one;
  • Field constructor in src/plugins/data/public/index_patterns/fields/field.ts was changed to accept dependencies { fieldFormats, toastNotifications } instead of using getter/setter, as well as FieldList in src/plugins/data/public/index_patterns/fields/field_list.ts , since it's statically used in discover and management (which is still in legacy, but would have the same problem while migrated);
  • translations was changed to use discover prefix;

Checklist

Delete any items that are not applicable to this PR.

For maintainers

@sulemanof
Copy link
Contributor Author

This is currently blocked by #62624

@flash1293 flash1293 mentioned this pull request Apr 14, 2020
69 tasks
# Conflicts:
#	src/legacy/core_plugins/kibana/index.js
#	src/legacy/core_plugins/kibana/public/discover/plugin.ts
#	src/legacy/core_plugins/kibana/public/index.scss
#	src/legacy/core_plugins/kibana/public/kibana.js
#	src/plugins/discover/public/build_services.ts
#	src/plugins/discover/public/kibana_services.ts
# Conflicts:
#	src/plugins/discover/public/application/angular/context/api/_stubs.js
#	src/plugins/discover/public/application/angular/context/api/context.ts
#	src/plugins/discover/public/build_services.ts
# Conflicts:
#	src/legacy/core_plugins/kibana/public/management/sections/index_patterns/edit_index_pattern/edit_index_pattern.js
#	src/plugins/discover/public/kibana_services.ts
@sulemanof
Copy link
Contributor Author

retest

@kertal kertal mentioned this pull request Apr 27, 2020
7 tasks
@kertal kertal added Feature:NP Migration Team:Visualizations Visualization editors, elastic-charts and infrastructure labels Apr 27, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app (Team:KibanaApp)

@kertal kertal added v8.0.0 release_note:skip Skip the PR/issue when compiling release notes labels Apr 27, 2020
@kertal
Copy link
Member

kertal commented Apr 27, 2020

@elasticmachine merge upstream

.github/CODEOWNERS Show resolved Hide resolved
Comment on lines 79 to +80
SortDirection,
} from '../../../../../plugins/data/public';
} from '../../data/public';
Copy link
Contributor

@pgayvallet pgayvallet May 1, 2020

Choose a reason for hiding this comment

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

I think re-exporting from other KP plugins/bundles was causing some problems a few month back. I remember an issue with kibana_react re-exporting things from core. But maybe that was only with concrete types, or maybe only when these re-exports were exposed in the entry point. @spalger is there any issue with 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.

Since this code exists for a long, I didn't notice any problems with that.
If the issue you mentioned exists, I think we could create a separate fix for it and let this PR go further. 🙂

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think there's anything wrong with this, I recommend this approach in many cases.

Comment on lines +209 to +214
await this.initializeInnerAngular();

// make sure the index pattern list is up to date
await dataStart.indexPatterns.clearCache();
const { renderApp } = await import('./application/application');
const unmount = await renderApp(innerAngularName, params.element);
Copy link
Contributor

@pgayvallet pgayvallet May 1, 2020

Choose a reason for hiding this comment

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

I know you are already doing some ping-pong between setup and start for this initializeInnerAngular call, but ideally, initializeInnerAngular would be included in the async import instead just the app (await import('./application/application'))

That would avoid

import { getInnerAngularModuleEmbeddable, getInnerAngularModule } from './get_inner_angular';

to be present in the root plugin file. Seing all the things this get_inner_angular module imports, that would probably drastically reduce the discover plugin initial bundle's size.

I see that getInnerAngularModuleEmbeddable is used outside of the mount function, so this change seems really non-trivial, but that would really be a nice performance improvement.

That could be done in a follow-up PR though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@pgayvallet This is a really good point!
But if you don't mind, I would do it in a follow up PR in scope of #63596

# Conflicts:
#	docs/development/plugins/data/public/kibana-plugin-plugins-data-public.search.md
#	src/plugins/data/public/public.api.md
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.

Tested in Chrome and didn't notice any issues. LGTM once green.

@kertal kertal requested review from kertal and ppisljar May 4, 2020 10:10
Copy link
Member

@kertal kertal 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, tested locally in Chrome an found a problem with the single doc view, showing an empty screen:

Bildschirmfoto 2020-05-04 um 12 17 15

image

@sulemanof
Copy link
Contributor Author

sulemanof commented May 4, 2020

Code LGTM, tested locally in Chrome an found a problem with the single doc view, showing an empty screen:

Bildschirmfoto 2020-05-04 um 12 17 15

seems to be a problem with usage of an arrow function as a constructor, faced the same while migrating Dashboard to NP.

@sulemanof
Copy link
Contributor Author

found a problem with the single doc view, showing an empty screen:

Bildschirmfoto 2020-05-04 um 12 17 15

@kertal thanks for the good catch, fixed in the last commit

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

Copy link
Contributor

@lizozom lizozom left a comment

Choose a reason for hiding this comment

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

Looks good overall
Added couple of questions

@@ -1,4 +1,4 @@
@import '../../../../../core_plugins/kibana/public/discover/np_ready/mixins';
@import '../../../../../../plugins/discover/public/application/mixins';
Copy link
Contributor

Choose a reason for hiding this comment

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

You can load this directly form NP IMO

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 would wait for a comment from @kibana-design here, because I'm not sure whether this still needed. Maybe could be simply removed.

Copy link
Contributor

Choose a reason for hiding this comment

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

@elastic/kibana-design

I agree,
not a blocker to merge though

Copy link
Contributor

@cchaos cchaos May 4, 2020

Choose a reason for hiding this comment

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

There are some very generic selectors in this file, I'd be very worried about removing it without doing a full search for all the selectors. I'd leave this as-is and we'll do an audit before 8.0

@@ -24,8 +24,8 @@ import { FieldEditor } from 'ui/field_editor';
import { EuiFlexGroup, EuiFlexItem } from '@elastic/eui';
import { i18n } from '@kbn/i18n';
import { HttpStart, DocLinksStart } from 'src/core/public';
import { IndexPattern, DataPublicPluginStart } from 'src/plugins/data/public';
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you use IIndexPattern here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Of course I could 🙂
But before changing this, I'd like to know details why it is necessary?
AFAIK the usage of I prefixes is no longer necessary since we update typescript to 3.7 (this thing was discussed on kibana app migration meeting, @flash1293 please correct me if I'm wrong).
If it's still relevant, then we should get rid of exporting the IndexPattern from the data start and export the only interface, because IndexPattern continues to be used as interface in many places.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In addition, changing this to IIndexPattern will cause a lot of changes in data plugin itself, since the Field class constructor expecs the IndexPattern type: https://github.com/elastic/kibana/blob/master/src/plugins/data/public/index_patterns/fields/field.ts#L53
the same is about FieldList:
https://github.com/elastic/kibana/blob/master/src/plugins/data/public/index_patterns/fields/field_list.ts#L49
and this chain is quite big :)

Copy link
Contributor

Choose a reason for hiding this comment

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

It's not urgent.
IIndexPattern is actually a narrower interface than IndexPattern
We will take care of that in another iteration. 👍

@@ -17,17 +17,13 @@
* under the License.
*/

import { Filter, IndexPatternsContract, IndexPattern } from 'src/plugins/data/public';
Copy link
Contributor

Choose a reason for hiding this comment

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

// brain pick
Should we stick with the relative paths for consistency?
The absolute paths still don't work for non type imports.

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'm not aware of any restrictions to use absolute imports for types.
This wouldn't work for static js of course,
but I prefer using absolute one for types only, this is extremely helpful in context of our endless files migration, where you have to change paths in every PR as this one.

@@ -18,7 +18,7 @@
*/

import _ from 'lodash';
import { IndexPattern } from '../../../../../../../../../plugins/data/public';
import { IndexPattern } from '../../../../../../data/public';
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you use IINdexPattern?

@@ -98,12 +94,12 @@ export function DiscoverSidebar({
const [showFields, setShowFields] = useState(false);
const [fields, setFields] = useState<IndexPatternFieldList | null>(null);
const [fieldFilterState, setFieldFilterState] = useState(getDefaultFieldFilter());
const services = getServices();
const services = useMemo(() => getServices(), []);
Copy link
Contributor

Choose a reason for hiding this comment

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

This looks rather weird, because this means the services could change, but we won't get a fresh version?
@kertal

@kertal kertal self-requested a review May 4, 2020 13:44
Copy link
Member

@kertal kertal 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, doc view now works correctly 👍 . Tested locally with Chrome 81, Mac OS 10.14.6. No regressions. Thx for taking care of the last Kibana App 🦕 !

Copy link
Contributor

@cchaos cchaos left a comment

Choose a reason for hiding this comment

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

I did a quick scan of the different Discover views and the table vis and I didn't see any errors from the styles side.

@@ -1,4 +1,4 @@
@import '../../../../../core_plugins/kibana/public/discover/np_ready/mixins';
@import '../../../../../../plugins/discover/public/application/mixins';
Copy link
Contributor

@cchaos cchaos May 4, 2020

Choose a reason for hiding this comment

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

There are some very generic selectors in this file, I'd be very worried about removing it without doing a full search for all the selectors. I'd leave this as-is and we'll do an audit before 8.0

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

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

@sulemanof sulemanof merged commit f126e61 into elastic:master May 4, 2020
@sulemanof sulemanof deleted the np/discover branch May 4, 2020 20:34
sulemanof added a commit to sulemanof/kibana that referenced this pull request May 4, 2020
* Move discover into NP

* Convert doc_table tests to jest

* Move rows_headers to use jest

* Move fixed_scroll.test

* Clean up

* Revert jest changes

* Pass down deps into IndexPatternFieldList

* Fix conflicts

* Pass env vars

* Remove LegacyCoreStart

* Update generated doc

* Fix canvas type

* Fix i18n

* Improve stub_index_pattern code

* Add fieldFormats to mocked services

* Skip failing tests
- while still working on them, to find out if other tests fail in jenkins

* Unskip sidebar test

* Move mocha tests to legacy

- delete jest tests, can be converted later on

* Fix Scss imports
- Seems functional tests didn't build because of them?

* Remove another invalid SCSS import

* Pass deps as last argument

* Move field list into data start contract

* Move create field into data start contract, fix tests

* Update docs

* Fix duplicating fields

* Update snapshots in management

* Fix review comments

* Update docs

* Fix angular compilation

* Update docs

Co-authored-by: Matthias Wilhelm <matthias.wilhelm@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
# Conflicts:
#	.github/CODEOWNERS
#	x-pack/plugins/translations/translations/ja-JP.json
#	x-pack/plugins/translations/translations/zh-CN.json
@sulemanof sulemanof added v7.9.0 and removed v7.8.0 labels May 6, 2020
sulemanof added a commit that referenced this pull request May 6, 2020
* [NP][Discover] Move discover into new platform (#63473)

* Move discover into NP

* Convert doc_table tests to jest

* Move rows_headers to use jest

* Move fixed_scroll.test

* Clean up

* Revert jest changes

* Pass down deps into IndexPatternFieldList

* Fix conflicts

* Pass env vars

* Remove LegacyCoreStart

* Update generated doc

* Fix canvas type

* Fix i18n

* Improve stub_index_pattern code

* Add fieldFormats to mocked services

* Skip failing tests
- while still working on them, to find out if other tests fail in jenkins

* Unskip sidebar test

* Move mocha tests to legacy

- delete jest tests, can be converted later on

* Fix Scss imports
- Seems functional tests didn't build because of them?

* Remove another invalid SCSS import

* Pass deps as last argument

* Move field list into data start contract

* Move create field into data start contract, fix tests

* Update docs

* Fix duplicating fields

* Update snapshots in management

* Fix review comments

* Update docs

* Fix angular compilation

* Update docs

Co-authored-by: Matthias Wilhelm <matthias.wilhelm@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
# Conflicts:
#	.github/CODEOWNERS
#	x-pack/plugins/translations/translations/ja-JP.json
#	x-pack/plugins/translations/translations/zh-CN.json

* Fix intl conflicts
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backported Feature:Discover Discover Application Feature:NP Migration release_note:skip Skip the PR/issue when compiling release notes Team:Visualizations Visualization editors, elastic-charts and infrastructure v7.9.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.