-
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
Reorganizing spaces client-side plugin #53644
Conversation
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
Pinging @elastic/kibana-security (Team:Security) |
ACK: reviewing... |
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, just few very minor questions/nits!
Rather wordy, but this service is responsible for the entire "copy saved objects to space" functionality that exists on the client-side.
That looks good to me, if/once we have more Space related saved objects actions (and screens) we can make it a sub-folder of saved_objects_actions
or something, but for now it feels reasonable to have a very specific name.
Removed unnecessary lib folders
💯 Navigation through folder structure is much more intuitive now!
|
||
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.
note: hmm, I'm surprised that we don't have serverBasePath
as a property of core basePath
service on the client side like we have on the server side. Is it intentional @elastic/kibana-platform or we just haven't had a chance to implement that yet?
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 is a naming inconsistency. It's available under http.basePath.get()
.
@@ -0,0 +1,3 @@ | |||
@import './components/confirm_delete_modal/confirm_delete_modal'; | |||
@import './edit_space/enabled_features/index'; | |||
|
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: I see we don't import ./edit_space/section_panel/_section_panel.scss
here (or anywhere else). Do we still need it or there is some magic that imports it automatically? I also noticed similar case with _collapsible_panel.scss
in security plugin.
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.
Great catch -- it turns out that the Spaces SectionPanel
does not rely on the styles in that stylesheet, because Spaces does not make use of the optional iconType
prop, whereas the Security panel does. I'll see if we need it for security since you mentioned we're not importing it there either.
I'll update to import this .scss
file, as that's the least invasive change to this PR.
We should consider removing the optional iconType
prop from the spaces version since it's not used at all, but I'll leave that for another PR.
@@ -403,7 +403,7 @@ describe('CopyToSpaceFlyout', () => { | |||
type: 'visualization', | |||
id: 'my-viz', | |||
error: { | |||
type: 'missing_references', | |||
type: 'missing_references' as any, |
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.
nit: maybe just add blocking: [],
error property to make TS happy and not resort to any
?
export class CopySavedObjectsToSpaceService { | ||
public setup({ spacesManager, managementSetup }: SetupDeps) { | ||
const action = new CopyToSpaceSavedObjectsManagementAction(spacesManager); | ||
if (!managementSetup.savedObjects.registry.has(action.id)) { |
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: out of curiosity, what is the use case when this will evaluate to false
?
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, the original legacy location for this code block would execute whenever the management
route was resolved, so we needed this check in place to prevent duplicate registration. I expect we don't need this anymore. I'll remove and verify before merging.
const service = new ManagementService(); | ||
service.start(deps); | ||
|
||
expect(deps.managementStart.legacy.getSection).toHaveBeenCalledTimes(1); |
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: this expect
doesn't seem to be very useful - we already checked that it's called with the right section name in the previous test and here we can either omit it entirely (+1) or we should check that it was called with the right section name.
const service = new ManagementService(); | ||
service.start(deps); | ||
|
||
expect(deps.managementStart.legacy.getSection).toHaveBeenCalledTimes(1); |
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: shouldn't we check here that register
wasn't called instead?
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!
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.
Actually, since the Kibana section isn't available on this scenario, there isn't a register
function to assert against.
@@ -42,6 +42,7 @@ describe('NavControlPopover', () => { | |||
disabledFeatures: [], | |||
}, | |||
]); | |||
// @ts-ignore readonly check |
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: looks like we need a separate ISpaceManager
that all consumers can rely on and then we won't have to cast to jest.Mocked<SpaceManager>
in spacesManagerMock.create()
and hence can change properties here without ts-ignore
. Obviously it's out of scope of this PR, just wanted to note.
|
||
const module = uiModules.get('spaces_selector', []); | ||
module.controller('spacesSelectorController', ($scope: any) => { | ||
$scope.$$postDigest(async () => { | ||
const domNode = document.getElementById('spaceSelectorRoot'); | ||
|
||
const { spacesManager } = await spacesNPStart; | ||
const { spacesManager } = spacesNPStart; |
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: looks like we can remove async
from the postDigest
callback function now.
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.
The SCSS organization looks good, thanks for cleaning this up.
One nitpicky consideration, the ...copy_saved_objects_to_space/components/_index.scss
file has styles directly in it as opposed to importing another file (e.g. we could add a _copy_to_space.scss
). For comparison, the ...nav_control/components/_index.scss
file imports other scss files with names aligned to the corresponding component.
That said, no other components in the ...copy_saved_objects_to_space/components/
directory have styles, so maybe this is a pattern we follow when there is only one component with styles.
Thoughts?
@ryankeairns based on #53880 (comment), I think we should move all the styles out of the |
x-pack/legacy/plugins/spaces/public/copy_saved_objects_to_space/_index.scss
Outdated
Show resolved
Hide resolved
💚 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.
👍 LGTM, thanks for the changes!
* reorganizing spaces client-side plugin * additional testing and cleanup * address PR feedback * additional cleanup * rename scss file * one more index Co-authored-by: Elastic Machine <[email protected]>
Summary
The previous spaces client-side plugin had a rather messy folder structure. This attempts to re-organize the code to make porting to the NP a bit easier.
A bulk of the changes are simple moves (with changes to import paths). The rest of the changes are introducing the lightweight services mentioned below, and adding tests for them.
Specifically:
Introduced Advanced Settings Service
Location:
plugins/spaces/public/advanced_settings
This is responsible for registering the React components which decorate the Advanced Settings screen, informing users that the settings are space-aware, unless otherwise noted.
Introduced "Copy Saved Objects to Space" Service
Location:
plugins/spaces/public/copy_saved_objects_to_space
Rather wordy, but this service is responsible for the entire "copy saved objects to space" functionality that exists on the client-side.
Introduced Management Service
Location:
plugins/spaces/public/management
This is responsible for registering the Spaces management link under the Kibana section, which contains the screens allowing for spaces management. As part of this service, we migrated to the NP management registration service.
Removed unnecessary
lib
foldersConsolidated logic under the new services where appropriate
A note on the
SpacesManager
Once we are fully migrated, I want to re-evaluate the SpacesManager (out of scope for this PR). I want to deconstruct this into a few focused entities:
activeSpace$
observable to get the most up-to-date representation of the active space.activeSpace$
when appropriate.