Move ui/index_patterns code to data plugin.#42994
Move ui/index_patterns code to data plugin.#42994lukeelmers merged 14 commits intoelastic:masterfrom
Conversation
|
Pinging @elastic/kibana-app-arch |
This comment has been minimized.
This comment has been minimized.
40037bc to
2a5fa46
Compare
This comment has been minimized.
This comment has been minimized.
src/legacy/core_plugins/data/public/index_patterns/index_patterns_service.mock.ts
Outdated
Show resolved
Hide resolved
lizozom
left a comment
There was a problem hiding this comment.
Looks good.
Just a few questions and LGTM.
...management/sections/index_patterns/edit_index_pattern/create_edit_field/create_edit_field.js
Outdated
Show resolved
Hide resolved
2a5fa46 to
5d01797
Compare
|
@elastic/kibana-platform FYI, the codeowners review here is for a small change to a test in |
There was a problem hiding this comment.
This was no longer consistent with the actual IndexPattern class, and is only used directly in a few places, so I updated the args
There was a problem hiding this comment.
Since code was moved into the shimmed data plugin, a bunch of tests failed due to stuff that needed to be mocked now that the whole data plugin was getting kicked off.
So the approach here was to mimic jest.mock('ui/new_platform')... basically if your plugin is still importing from the legacy location in ui/index_patterns, you can use the new platform mock along with jest.mock('ui/index_patterns'), and everything will be taken care of for you; no need to worry about what downstream dependencies the data plugin has.
This comment has been minimized.
This comment has been minimized.
5d01797 to
f7b7d9e
Compare
This comment has been minimized.
This comment has been minimized.
rudolf
left a comment
There was a problem hiding this comment.
ui/public/saved_objects changes LGTM
f7b7d9e to
599327c
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
lizozom
left a comment
There was a problem hiding this comment.
Added two minor questions but otherwise LGTM
There was a problem hiding this comment.
Shouldn't these two guys be in __LEGACY?
There was a problem hiding this comment.
I see you added the stateful initializer! So cool. :-)
I guess we're going to have one in many components.
Do you have an idea for a common name? (not necessarily for this PR!)
There was a problem hiding this comment.
Do you have an idea for a common name? (not necessarily for this PR!)
Yeah I think that's a good question. One possibility (which is the approach I took here for the time being) would be the use the same name in both places. If it's in the lifecycle, you can assume it is "pre-wired", and if it is exported statically, assume it isn't.
There are a number of reasons this isn't ideal, however (could lead to confusion when suddenly a component with the same name has a different contract when imported statically). I don't have any great ideas on that right now, but worth thinking about.
I'm more interested in how many people will prefer to have a static import which requires more configuration, vs a stateful one which doesn't. I think that remains to be seen still.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Does this mock have to be here? It might be unexpected if user wants to themselves mock ui/chrome, but it is already mocked.
There was a problem hiding this comment.
Yeah I debated whether to mock ui/chrome in each of the individual tests that were using index patterns, vs mocking it in one place here.
The reason I settled on this implementation was because I felt we should minimize the amount of stuff people need to know about dependencies of their dependencies. Each of the tests knows it is using index patterns, so it is reasonable to ask them to use jest.mock('ui/index_patterns'). And they know they are (eventually) moving over to new platform, so it's reasonable to ask them to jest.mock('ui/new_platform').
But they don't necessarily know that index patterns have moved to the data plugin, which starts up some legacy stuff, which relies on chrome. It felt unfair to ask them to figure this out, which is why I moved the mock here instead.
There are a few scenarios where this has downsides though:
- Case you mentioned: Users want to provide custom mocks for
chrome, or require the "real"chrome. In this case they'd need to unmock orrequireActual. - Users writing tests with index patterns have other code that needs
chrometo be mocked as well. Their tests are "magically" working, but may break sometime in the future when we removechrome(and the mock) from index patterns.
Overall I think scenario 1 will be relatively uncommon for most users. Scenario 2 could be more common, but is still something we can fix in the PR where we remove chrome from index patterns.
…rnSelect components.
|
I tested this firefox smoke test failure locally, and I was seeing it on master too -- so it may not be related. Going to push and let CI run again to see how it goes |
a49c490 to
75cf732
Compare
💚 Build Succeeded |
Closes #40555
Summary
Initial pass at moving the contents of
ui/index_patternsinto thedataplugin, while re-exporting the contracts fromui/index_patternsto preserve backwards compatibility.This also introduces mocks for the
dataplugin, which are used to provide a mock for the entire legacy contract ofui/index_patterns. This means tests relying onui/index_patternscan just usejest.mock('ui/index_patterns')without worrying about the fact that it's talking to the data plugin under the hood.There should be no breaking changes as a result of this PR.
There are a lot of follow-up tasks that will need to happen to prepare index patterns for the new platform, including finishing TS conversion and cleaning out legacy dependencies. This PR is solely focused on reshaping the code and moving into the data plugin with a proper
setuplifecycle contract, which will make further changes easier to manage.Dev Docs
No functional or breaking changes were introduced here, however, the file structure of index patterns was changed somewhat from how it was structured in the original module: