[NP][Discover] Move discover into new platform#63473
[NP][Discover] Move discover into new platform#63473sulemanof merged 42 commits intoelastic:masterfrom
Conversation
|
This is currently blocked by #62624 |
# 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
|
retest |
|
Pinging @elastic/kibana-app (Team:KibanaApp) |
|
@elasticmachine merge upstream |
src/legacy/core_plugins/kibana/public/__tests__/discover/legacy.ts
Outdated
Show resolved
Hide resolved
src/plugins/data/public/index_patterns/index_patterns/index_patterns.test.ts
Outdated
Show resolved
Hide resolved
| SortDirection, | ||
| } from '../../../../../plugins/data/public'; | ||
| } from '../../data/public'; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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. 🙂
There was a problem hiding this comment.
I don't think there's anything wrong with this, I recommend this approach in many cases.
| 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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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
flash1293
left a comment
There was a problem hiding this comment.
Tested in Chrome and didn't notice any issues. LGTM once green.
@kertal thanks for the good catch, fixed in the last commit |
lizozom
left a comment
There was a problem hiding this comment.
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'; | |||
There was a problem hiding this comment.
You can load this directly form NP IMO
There was a problem hiding this comment.
I would wait for a comment from @kibana-design here, because I'm not sure whether this still needed. Maybe could be simply removed.
There was a problem hiding this comment.
@elastic/kibana-design
I agree,
not a blocker to merge though
There was a problem hiding this comment.
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
| 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'; |
There was a problem hiding this comment.
Could you use IIndexPattern here?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
It's not urgent.
IIndexPattern is actually a narrower interface than IndexPattern
We will take care of that in another iteration. 👍
| * under the License. | ||
| */ | ||
|
|
||
| import { Filter, IndexPatternsContract, IndexPattern } from 'src/plugins/data/public'; |
There was a problem hiding this comment.
// brain pick
Should we stick with the relative paths for consistency?
The absolute paths still don't work for non type imports.
There was a problem hiding this comment.
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.
|
|
||
| import _ from 'lodash'; | ||
| import { IndexPattern } from '../../../../../../../../../plugins/data/public'; | ||
| import { IndexPattern } from '../../../../../../data/public'; |
There was a problem hiding this comment.
Could you use IINdexPattern?
| const [fields, setFields] = useState<IndexPatternFieldList | null>(null); | ||
| const [fieldFilterState, setFieldFilterState] = useState(getDefaultFieldFilter()); | ||
| const services = getServices(); | ||
| const services = useMemo(() => getServices(), []); |
There was a problem hiding this comment.
This looks rather weird, because this means the services could change, but we won't get a fresh version?
@kertal
kertal
left a comment
There was a problem hiding this comment.
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 🦕 !
cchaos
left a comment
There was a problem hiding this comment.
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'; | |||
There was a problem hiding this comment.
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
# Conflicts: # src/plugins/data/public/public.api.md
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
* 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
* [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


Summary
Part of #60097
Most of the changes are file transfer into new platform and related paths changes.
The main changes are:
src/plugins/discover/public/plugin.tsandsrc/legacy/core_plugins/kibana/public/discover/plugin.tswere merged into one;Fieldconstructor insrc/plugins/data/public/index_patterns/fields/field.tswas changed to accept dependencies{ fieldFormats, toastNotifications }instead of usinggetter/setter, as well asFieldListinsrc/plugins/data/public/index_patterns/fields/field_list.ts, since it's statically used indiscoverandmanagement(which is still in legacy, but would have the same problem while migrated);discoverprefix;Checklist
Delete any items that are not applicable to this PR.
For maintainers