-
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
Spaces -> Client to NP #54298
Spaces -> Client to NP #54298
Conversation
@elasticmachine merge upstream |
@azasypkin I'm going to pause work on this until #53880 merges, so that you're not waiting on two of my PRs to get yours in 😄. I'm torn between using the NP management service here, or doing that move in a different PR. Do you have an opinion from a review perspective? I expect I'll have to introduce a router of some sort when I migrate to the NP version. I'm hoping it won't introduce a ton of extra complexity, but I haven't dug too far into this yet. |
Both options would work for me. The only reason you'd want to keep these separated is that we're the only consumers of the brand new Management API and it's still a bit buggy. I'm testing it and reporting the issues I found at the moment, nothing super critical though, just minor things here and there.
Yep, we'll need a router, I started to use |
Resuming work on this! |
...lugins/kibana/public/management/sections/settings/components/default_component_registry.d.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/spaces/public/advanced_settings/advanced_settings_service.tsx
Outdated
Show resolved
Hide resolved
Pinging @elastic/kibana-security (Team:Security) |
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 great! I've left a couple of nits and questions and also noted a minor i18n issue. I haven't tested it thoroughly yet as I expect you're going to incorporate latest changes from advanced settings NP migration, so I'm planning to test with these (but tell me if you're not going to do that, it's fine by me too).
...lugins/kibana/public/management/sections/settings/components/default_component_registry.d.ts
Outdated
Show resolved
Hide resolved
@@ -154,6 +154,9 @@ export const npSetup = { | |||
}), | |||
}, | |||
}, | |||
spaces: { |
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.
note: can you please explain why we need this? I seems spaces
is the only x-pack plugin mentioned here and I'm wondering if we should have something similar in x-pack.
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 was a while ago..I had Karma test failures, so I followed the instructions in the migration guide to "fix" it. I have a lot less in the LP plugin now though, so maybe I'm already past the issue. I'll remove and see what happens. If it fails, I should be able to introduce a mock within the spaces plugin itself.
Lines 1564 to 1570 in 5d6dbf0
#### What about karma tests? | |
While our plan is to only provide first-class mocks for Jest tests, there are many legacy karma tests that cannot be quickly or easily converted to Jest -- particularly those which are still relying on mocking Angular services via `ngMock`. | |
For these tests, we are maintaining a separate set of mocks. Files with a `.karma_mock.{js|ts|tsx}` extension will be loaded _globally_ before karma tests are run. | |
It is important to note that this behavior is different from `jest.mock('ui/new_platform')`, which only mocks tests on an individual basis. If you encounter any failures in karma tests as a result of new platform migration efforts, you may need to add a `.karma_mock.js` file for the affected services, or add to the existing karma mock we are maintaining in `ui/new_platform`. |
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.
Update: the LP spaces plugin runs its legacy.ts
as part of a hack
, so that it runs for all LP plugins. The goal of legacy.ts
is to call the NP registerLegacyAPI
, so that the plugin can finish its initialization. In the case of these Karma tests, we need the npSetup
static import provided by new_platform.karma.mock
to have the spaces
plugin registered, so that legacy.ts
can call registerLegacyAPI
.
So an alternative to placing this here, is to place a guard within legacy.ts
, to only call registerLegacyAPI
if the spaces
plugin is actually defined. What do you think about that approach?
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.
So an alternative to placing this here, is to place a guard within legacy.ts, to only call registerLegacyAPI if the spaces plugin is actually defined. What do you think about that approach?
On the surface it sounds like a better workaround to me, do you have any concerns regarding it?
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.
And thanks for the explanation!
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.
On the surface it sounds like a better workaround to me, do you have any concerns regarding it?
None at all! Resolved in 3f24902
@@ -17,10 +17,20 @@ | |||
* under the License. | |||
*/ | |||
|
|||
const createSetupContract = () => ({ |
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.
optional nit: can we use (): jest.Mocked<ManagementSetup> => ({
to make sure these are up to date when interface changes?
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 causes the following to fail:
const managementSetup = managementSetupMock.createSetupContract();
managementSetup.sections.getSection.mockReturnValue(foo);
Because managementSetup.sections
is of type SectionsServiceSetup
, rather than jest.Mocked<SectionsServiceSetup>
.
Do you know of a way to tell TS what we really want to do here? I couldn't get it to work, but didn't spend more than 15 minutes on it.
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.
Hmm, I see. IIRC Platform team used something like DeeplyMockedKeys
instead of jest.Mocked
for cases like this, maybe that would work for us too... But feel free to ignore if it takes too much time to fix Management's mocks and types.
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.
That worked perfectly, thanks for the tip!
private managementService?: ManagementService; | ||
|
||
public setup(core: CoreSetup, plugins: PluginsSetup) { | ||
const serverBasePath = core.injectedMetadata.getInjectedVar('serverBasePath') as string; |
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.
question: as far as I remember it's equivalent of core.http.basePath.get()
?
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.
Good catch, yes!
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.
Ah, actually it's not the same. There doesn't appear to be any logic to distinguish between the server base path and the space-aware base path in the client-side basePath
service.
@elastic/kibana-platform does the client-side basePath service need the equivalent serverBasePath
property that the corresponding server-side basePath service defines?
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 doesn't appear to be any logic to distinguish between the server base path and the space-aware base path in the client-side basePath service.
Oh, that's a bummer. I think we were asking this question before ping @restrry
x-pack/plugins/spaces/public/management/management_service.test.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/spaces/public/management/spaces_management_app.tsx
Outdated
Show resolved
Hide resolved
...lugins/spaces/public/copy_saved_objects_to_space/copy_saved_objects_to_space_service.test.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/spaces/public/management/edit_space/delete_spaces_button.test.tsx
Outdated
Show resolved
Hide resolved
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.
Kibana app changes LGTM. Thanks a lot for the mocks!
Co-Authored-By: Aleh Zasypkin <aleh.zasypkin@gmail.com>
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
@azasypkin I've addressed all feedback, with the exception of the missing |
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.
LGTM, great job! Tested locally and haven't noticed anything wrong apart from one thing related to manual edits of Edit Space page URL.
x-pack/plugins/spaces/public/management/edit_space/manage_space_page.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/spaces/public/management/edit_space/enabled_features/enabled_features.tsx
Show resolved
Hide resolved
@elasticmachine merge upstream |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
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.
ML edit 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.
I did a scan of the scss changes. They look to be all renames with no code changes. Did not look at any of the other code.
* moves * updates to support spaces client in NP * fixing MLs import * update karma mock * remove unnecessary setup license * fix merge from master * moving management app registration to NP * move space selector app to NP * remove unused xpackMain legacy dependency * hide spaces management if not authorized * additional testing * additional cleanup * additional testing * use NP advancedSettings plugin * Apply suggestions from code review Co-Authored-By: Aleh Zasypkin <aleh.zasypkin@gmail.com> * start addressing PR feedback * reverting logic to determine serverBasePath * removing spaces mock * mantain BWC with old management links * add types to management mock * address remaining PR feedback Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Summary
Migrates the bulk of the spaces client-side application to the New Platform
Out of scope: The "enter space path" is blocked on #50658