-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
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.
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?
There was a problem hiding this comment.
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. 🙂
There was a problem hiding this comment.
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.
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.
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.
There was a problem hiding this comment.
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
There was a problem hiding this 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kertal thanks for the good catch, fixed in the last commit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code LGTM
There was a problem hiding this 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'; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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'; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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'; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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'; |
There was a problem hiding this comment.
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(), []); |
There was a problem hiding this comment.
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
There was a problem hiding this 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 🦕 !
There was a problem hiding this 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'; |
There was a problem hiding this comment.
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
# 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 <[email protected]> Co-authored-by: Elastic Machine <[email protected]> # 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 <[email protected]> Co-authored-by: Elastic Machine <[email protected]> # 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.ts
andsrc/legacy/core_plugins/kibana/public/discover/plugin.ts
were merged into one;Field
constructor insrc/plugins/data/public/index_patterns/fields/field.ts
was changed to accept dependencies{ fieldFormats, toastNotifications }
instead of usinggetter/setter
, as well asFieldList
insrc/plugins/data/public/index_patterns/fields/field_list.ts
, since it's statically used indiscover
andmanagement
(which is still in legacy, but would have the same problem while migrated);discover
prefix;Checklist
Delete any items that are not applicable to this PR.
For maintainers