-
Notifications
You must be signed in to change notification settings - Fork 906
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
[Workspace] Feature/workspace service core module #5092
[Workspace] Feature/workspace service core module #5092
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5092 +/- ##
==========================================
+ Coverage 66.73% 66.79% +0.05%
==========================================
Files 3284 3286 +2
Lines 63095 63129 +34
Branches 10049 10053 +4
==========================================
+ Hits 42108 42164 +56
+ Misses 18589 18570 -19
+ Partials 2398 2395 -3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
* SPDX-License-Identifier: Apache-2.0 | ||
*/ | ||
|
||
export interface WorkspaceAttribute { |
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.
if this a core type would be able to have a fast follow to use this one within the workspace 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.
Yes, this type WorkspaceAttribute
is the same as the one used in #5075 and this core type will be used by the plugin, is this what you are referring?
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.
Gotcha! So it's here for the sake of breaking down the PRs. Thanks!
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.
Thanks for doing this! People do love extending core stuff.
Would you potentially be able to add inline commenting could be like something like this:
opensearch-project/opensearch-dashboards-sdk-js#47
which produced https://github.com/kavilla/opensearch-dashboards-sdk-js/blob/avillk/sdk_base_2_no_doc/docs/modules.md. That way, in the future if we have to we can run a skip to dump documentation since usually the hardest part about the extending core functionality for plugins usually tends to be lack of knowing the usages and what to respect.
currentWorkspaceId$: BehaviorSubject<string>; | ||
currentWorkspace$: BehaviorSubject<WorkspaceObject | null>; | ||
workspaceList$: BehaviorSubject<WorkspaceObject[]>; | ||
workspaceEnabled$: BehaviorSubject<boolean>; |
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 wonder if this is redundant? Since a plugin being disabled is kind of a before run time operation.
When setting this up as well, the workspaces plugin can set the value for /api/core/capabilities
and plugins can check it is available to use
http://localhost:5609/vzu/api/core/capabilities
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's a very good point. I will remove this and update to use capabilities
in the follow PRs
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.
@kavilla Just to confirm that you mean we could use core.capabilities.registerProvider
to register a flag when workspace plugin is loaded. Then we could read this at frontend via, for example application.capabilities.workspaces.loaded
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.
Cool. I've fine with being part of a backlog but to be revisited prior to 2.11
cc: @manasvinibs (since she has worked a lot with it)
I see the cypress tests failed I think it was cached will re-run it. But would you like me to run this against a branch of cypress tests within a fork of the ftrepo? |
Overall, I think this fine. It's only going into unreleased for now so if it's unused by core functionality and then probably better off to get it merged sooner than later and let it bake in main for a little before getting into 2.x. Will check if the cypress tests are successful and also could we update any of the files such as: https://github.com/opensearch-project/OpenSearch-Dashboards/blob/80758aae438560445f8a1f8e69008e1c90603c84/src/core/public/public.api.md if they exist and require such changes. |
80758aa
to
59b0a3e
Compare
Hi @kavilla , thanks for suggesting this, I've added some comments, but I'm not sure if that meets the standards. Please take a look if you have time :) Also could you help to rerun the bwc test? Error shows OSD did not load properly, looks like a temporary issue. And I checked the failed cypress tests as well, it looks not related to this PR. |
Will keep this in mind and update those accordingly when appropriate. |
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.
Cypress tests are failing like other PRs. Known issue we are working on.
Hi @AMoo-Miki, could you take another look at the PR and see if everything looks good to you? Much appreciate! |
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.
A couple minor questions, but no large concerns. I would like to have in this PR or the related issue a summary of why this needs to be exposed as a core service rather than entirely encapsulated in a plugin.
src/core/types/workspace.ts
Outdated
features?: string[]; | ||
color?: string; | ||
icon?: string; | ||
defaultVISTheme?: 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.
Is there a design doc that explains this interface, and the use of this prop in particular?
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.
Had a discussion with team, the original requirement was to support different theme on workspace level. But we're not going to support this in our initial release. I will remove defaultVISTheme
for now to avoid confusion.
* The workspace that is derived from `currentWorkspaceId` and `workspaceList`, if | ||
* `currentWorkspaceId` cannot be found from `workspaceList`, it will return an error | ||
* | ||
* This value MUST NOT set manually from outside of WorkspacesService |
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.
Is there any way to enforce this?
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.
Yes, I think we can enforce it, that requires to refactor the current implementation a bit. Since this is the first PR, there will be other PRs will depends on this one, to avoid impacting others, what do you think if I create a task and come back to refactor this later?
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.
We can definitely do it in a follow-up; the concern here is to make sure we don't expose any public interfaces that we don't intend to, because those will all be subject to semver once they go out in a release.
* The list of available workspaces. This workspace list should be set by whoever | ||
* the workspace functionalities |
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.
"by whoever the workspace functionalities" - sorry, I'm not following this. Can we rephrase?
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.
Nice catch! I think there was one line been removed accidentally, will fix this.
} | ||
|
||
enum WORKSPACE_ERROR { | ||
WORKSPACE_STALED = 'WORKSPACE_STALED', |
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.
Can we rename? Maybe WORKSPACE_IS_STALE
* Do a simple idempotent verification here | ||
*/ | ||
if (!isEqual(currentWorkspace, this.currentWorkspace$.getValue())) { | ||
this.currentWorkspace$.next(currentWorkspace ?? null); |
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.
why do we want to use null
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.
I think no particular reason, undefined
also works, just null
was used at the beginning :)
|
||
if (currentWorkspaceId && !currentWorkspace?.id) { | ||
/** | ||
* Current workspace is staled |
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.
* Current workspace is staled | |
* Current workspace is stale |
src/core/public/index.ts
Outdated
@@ -341,3 +347,5 @@ export { | |||
}; | |||
|
|||
export { __osdBootstrap__ } from './osd_bootstrap'; | |||
|
|||
export { WorkspacesStart, WorkspacesSetup, WorkspacesService } from './workspace'; |
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.
Do we need to export WorkspacesService
? Doesn't it just get accessed via the core lifecycle methods?
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're right, this is not necessary.
The core workspace module(WorkspaceService) is a foundational component that enables the implementation of workspace features within OSD plugins. The purpose of the core workspace module is to provide a framework for workspace implementations. This module does not implement specific workspace functionality but provides the essential infrastructure for plugins to extend and customize workspace features, it maintains a shared workspace state(observables) across the entire application to ensure a consistent and up-to-date view of workspace-related information to all parts of the application. --------- Signed-off-by: Yulong Ruan <[email protected]>
Signed-off-by: Yulong Ruan <[email protected]>
Signed-off-by: Yulong Ruan <[email protected]>
Signed-off-by: Yulong Ruan <[email protected]>
Signed-off-by: Yulong Ruan <[email protected]>
Co-authored-by: Miki <[email protected]> Signed-off-by: Yulong Ruan <[email protected]> Signed-off-by: Yulong Ruan <[email protected]>
Signed-off-by: Yulong Ruan <[email protected]>
Signed-off-by: Yulong Ruan <[email protected]>
Signed-off-by: Yulong Ruan <[email protected]>
Signed-off-by: Yulong Ruan <[email protected]>
Signed-off-by: Yulong Ruan <[email protected]>
b6dff78
to
a21adee
Compare
@joshuarrrr Updated it in the PR description |
* SPDX-License-Identifier: Apache-2.0 | ||
*/ | ||
|
||
export { WorkspacesStart, WorkspacesService, WorkspacesSetup } from './workspaces_service'; |
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.
shall we add a README.md
to talk about some internals and usage of workspace service like https://github.com/opensearch-project/OpenSearch-Dashboards/tree/main/src/core/public/chrome
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 point, we have a separate PR that adds the documentation of workspace feature design and some implementation details #5282, I can add the one more section there about the WorkspacesService
currentWorkspaceId$: BehaviorSubject<string>; | ||
|
||
/** | ||
* The workspace that is derived from `currentWorkspaceId` and `workspaceList`, if | ||
* `currentWorkspaceId` cannot be found from `workspaceList`, it will return an error | ||
* | ||
* This value MUST NOT set manually from outside of WorkspacesService | ||
*/ | ||
currentWorkspace$: BehaviorSubject<WorkspaceObject | null>; |
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.
doesn't the currentWorkspace
object include workspace id that we need to have another observable for workspace 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.
Right, ideally having currentWorkspaceId
and workspaceList
is good enough, because currentWorkspace
can be derived from currentWorkspaceId
and workspaceList
.
However, in the actual code, the places that SET the current workspace normally only have the id
and the places that GET the current workspace normally will need the entire workspace object.
The currentWorkspace$
is more like a helper
, its computed from currentWorkspaceId$
and workspaceList$
once they changed.
* This is a flag which indicates the WorkspacesService module is initialized and ready | ||
* for consuming by others. For example, the `workspaceList` has been set, etc | ||
*/ | ||
initialized$: BehaviorSubject<boolean>; |
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 can only go from not initialized
to initialized
, does it needs to be an observable?
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 intention of making it reactive is, the value changing from not initialized
to initialized
maybe happen at any time, this is unlike reading regular configurations which we get value when application is mount. Using an observable so that the application can react to the value change.
do we want to save the selected workspace in browser localStorage so that it can be remembered for next login? |
@zengyan-amazon Sounds good to me, could be an improvement task, I will create a task for this and discuss it with the team and UX. |
* feat: add core workspace module (#145) The core workspace module(WorkspaceService) is a foundational component that enables the implementation of workspace features within OSD plugins. The purpose of the core workspace module is to provide a framework for workspace implementations. This module does not implement specific workspace functionality but provides the essential infrastructure for plugins to extend and customize workspace features, it maintains a shared workspace state(observables) across the entire application to ensure a consistent and up-to-date view of workspace-related information to all parts of the application. Signed-off-by: Yulong Ruan <[email protected]> Signed-off-by: Yulong Ruan <[email protected]> Co-authored-by: Miki <[email protected]> (cherry picked from commit 9e3e3a7) Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> # Conflicts: # CHANGELOG.md
* [Workspace] Feature/workspace service core module (#5092) * feat: add core workspace module (#145) The core workspace module(WorkspaceService) is a foundational component that enables the implementation of workspace features within OSD plugins. The purpose of the core workspace module is to provide a framework for workspace implementations. This module does not implement specific workspace functionality but provides the essential infrastructure for plugins to extend and customize workspace features, it maintains a shared workspace state(observables) across the entire application to ensure a consistent and up-to-date view of workspace-related information to all parts of the application. Signed-off-by: Yulong Ruan <[email protected]> Signed-off-by: Yulong Ruan <[email protected]> Co-authored-by: Miki <[email protected]> (cherry picked from commit 9e3e3a7) Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> --------- Signed-off-by: Anan Zhuang <[email protected]> Signed-off-by: Miki <[email protected]> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Anan Zhuang <[email protected]> Co-authored-by: Miki <[email protected]>
Description
The core workspace module(WorkspaceService) is a foundational component that enables the implementation of workspace features within OSD plugins. The purpose of the core workspace module is to provide a framework for workspace implementations.
This module does not implement specific workspace functionality but provides the essential infrastructure for plugins to
extend and customize workspace features, it maintains a shared workspace state(observables) across the entire application to ensure a consistent and up-to-date view of workspace-related information to all parts of the application.
Why introducing these changes to core?
The main consideration of introducing core workspace module includes:
currentWorkspace
,workspaceList
, etc maybe/is used by other core modules and core plugins, having it in core seems the most reasonable approached and it also makes it easy to be accessed.Issues Resolved
Partially resolved #5091
Screenshot
Testing the changes
Check List
yarn test:jest
yarn test:jest_integration
yarn test:ftr