Skip to content
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

Fix being able to view clusters outside the current workspace #2355

Merged
merged 4 commits into from
Apr 14, 2021

Conversation

Nokel81
Copy link
Collaborator

@Nokel81 Nokel81 commented Mar 17, 2021

  • Completely removes ClusterStore.activeCluster
  • Every workspace now tracks it current activeCluster
  • If an active cluster is removed then the workspace's activeClusterId is set to undefined
  • Only show welcome notification on the first time a non-managed workspace is viewed in the workspace overview
  • Add unit tests for the WorkspaceStore
  • Add validation that only valid clusters can be set to the activeClusterId field
  • Marks the current workspace as disabled in the switch workspace's command

Signed-off-by: Sebastian Malton sebastian@malton.name

fixes #2348

future work:

  • I could make it so that if you disconnect from a cluster it pick another one to go to instead of popping you back to the overview screen (see end of video).

New look:

Screen.Recording.2021-03-17.at.4.30.55.PM.mov

@Nokel81 Nokel81 added the bug Something isn't working label Mar 17, 2021
@Nokel81 Nokel81 added this to the 4.2.0 milestone Mar 17, 2021
@Nokel81 Nokel81 requested a review from a team March 17, 2021 20:33
@Nokel81 Nokel81 self-assigned this Mar 17, 2021
ixrock
ixrock previously approved these changes Mar 18, 2021
Copy link
Member

@ixrock ixrock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@@ -152,16 +241,24 @@ export class WorkspaceStore extends BaseStore<WorkspaceStoreModel> {
private static stateRequestChannel = "workspace:states";

@observable currentWorkspaceId = WorkspaceStore.defaultId;

#seenWorkspaces = observable.set<WorkspaceId>();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we use private fields here btw?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean instead of typescript's private modifier? I felt that this was a better way to prevent outside consumers from using the raw values

src/renderer/components/cluster-manager/clusters-menu.tsx Outdated Show resolved Hide resolved
@Nokel81
Copy link
Collaborator Author

Nokel81 commented Mar 18, 2021

Hopefully this can be in rc.2

ixrock
ixrock previously approved these changes Mar 18, 2021
Copy link
Contributor

@jim-docker jim-docker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a lot of refactoring to introduce between 4.2.0-rc.1 and rc.2. Did you consider doing just a surgical fix for the issue now, and saving this for 4.2.1 (or even 4.3)?

src/common/workspace-store.ts Outdated Show resolved Hide resolved
src/common/workspace-store.ts Outdated Show resolved Hide resolved
src/common/workspace-store.ts Outdated Show resolved Hide resolved
src/common/workspace-store.ts Outdated Show resolved Hide resolved
src/common/workspace-store.ts Outdated Show resolved Hide resolved
src/extensions/stores/cluster-store.ts Show resolved Hide resolved
src/main/index.ts Outdated Show resolved Hide resolved
@Nokel81
Copy link
Collaborator Author

Nokel81 commented Mar 19, 2021

I did consider a more patchwork fix, we could push this to 4.2.1 depending on how other people feel about this.

I think that if we test it enough it should be fine to put it into rc.2 though.

@Nokel81 Nokel81 modified the milestones: 4.2.0, 4.2.1 Mar 19, 2021
src/extensions/stores/cluster-store.ts Outdated Show resolved Hide resolved

@observer
export class LandingPage extends React.Component {
private static storage = createStorage<WorkspaceId[]>("landing_page", []);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so it will persist, nice, great idea.

src/renderer/components/+landing-page/landing-page.tsx Outdated Show resolved Hide resolved
@Nokel81
Copy link
Collaborator Author

Nokel81 commented Mar 19, 2021

I have moved this to target 4.2.1

@jim-docker
Copy link
Contributor

I have moved this to target 4.2.1

this will be a known issue for 4.2.0 then?

@Nokel81
Copy link
Collaborator Author

Nokel81 commented Mar 19, 2021

Yes in the final release notes I'll add that.

src/extensions/stores/cluster-store.ts Outdated Show resolved Hide resolved
LandingPage
.storage
.get()
.filter(id => workspaceStore.getById(id))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

slick!

src/renderer/components/+landing-page/landing-page.tsx Outdated Show resolved Hide resolved
@github-actions
Copy link
Contributor

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@github-actions
Copy link
Contributor

github-actions bot commented Apr 6, 2021

Conflicts have been resolved. A maintainer will review the pull request shortly.

@stefcameron
Copy link
Contributor

@Nokel81 Can you give me an overview of what the new API to activate a cluster in a workspace looks like now, with changes in this PR, since it sounds like it'll fix #1759 ?

@Nokel81
Copy link
Collaborator Author

Nokel81 commented Apr 7, 2021

@stefcameron I think it will be as simple as <LensExtensionInstance>.navigate("/cluster/<cluster-id>"); but I will verify this in the morning.

Signed-off-by: Sebastian Malton <sebastian@malton.name>
@Nokel81
Copy link
Collaborator Author

Nokel81 commented Apr 8, 2021

@stefcameron Done, I have added it. I don't know why the LensExtension.navigate method is only limited to a specific extension but whatever.

You need to do the following:

import { Store } from "@k8slens/extensions";

...
const cluster = ...;

await Store.workspaceStore.setActiveCluster(cluster); // or cluster ID

@Nokel81 Nokel81 linked an issue Apr 8, 2021 that may be closed by this pull request
@stefcameron
Copy link
Contributor

@stefcameron Done, I have added it. I don't know why the LensExtension.navigate method is only limited to a specific extension but whatever.

You need to do the following:

import { Store } from "@k8slens/extensions";

...
const cluster = ...;

await Store.workspaceStore.setActiveCluster(cluster); // or cluster ID

Thanks for following-up on this, @Nokel81 ! I will watch for this in 4.2.1 (unless I get to it off master before then) and will update my code accordingly.

Based on the call, the cluster doesn't have to be in the active workspace. Could be in some other workspace, and Lens will also activate the workspace as a result? Of course, this means Lens now ensures (maybe it always has; I haven't specifically tested) that all clusters have unique IDs...

@Nokel81
Copy link
Collaborator Author

Nokel81 commented Apr 8, 2021

No that call will update the active workspace too. Though now that I think about it. I think we should instead have it be Navigation.navigate("/cluster/<cluster-id"); and instead change the active workspace on the fly. So I might back out this change.

@Nokel81
Copy link
Collaborator Author

Nokel81 commented Apr 8, 2021

But I need to think about it. I only mention this because workspace are going away and I would prefer if what I told you will also work in 5.0

@stefcameron
Copy link
Contributor

But I need to think about it. I only mention this because workspace are going away and I would prefer if what I told you will also work in 5.0

Whaaaaat? 😉 OK, I'd like to know a way that will survive, though if workspaces disappear, that will definitely impact my extension.

BTW, extension.navigate("/cluster/<cluster-id>"); is what I'm already doing, but it's not reliable, which is the reason for #1759

@Nokel81
Copy link
Collaborator Author

Nokel81 commented Apr 8, 2021

@stefcameron So as we discussed, I am going to leave this API as is since putting more work into this is misplaced effort.

@stefcameron
Copy link
Contributor

@stefcameron So as we discussed, I am going to leave this API as is since putting more work into this is misplaced effort.

You mean it will be await Store.workspaceStore.setActiveCluster(cluster); // or cluster ID for now until Lens 5.0 when workspaces disappear? I assume there will be some equivalent method off the Catalogue API to activate an object at that point.

@Nokel81
Copy link
Collaborator Author

Nokel81 commented Apr 8, 2021

Yeah that.

@Nokel81 Nokel81 modified the milestones: 4.2.1, 4.2.2 Apr 9, 2021
@Nokel81 Nokel81 requested review from a team, jim-docker, jakolehm and nevalla and removed request for jim-docker April 14, 2021 12:48
Signed-off-by: Sebastian Malton <sebastian@malton.name>
Copy link
Contributor

@nevalla nevalla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@Nokel81 Nokel81 merged commit b6c3ce7 into release/v4.2 Apr 14, 2021
@Nokel81 Nokel81 deleted the issue-2348 branch April 14, 2021 13:49
@Nokel81 Nokel81 mentioned this pull request Apr 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocker bug Something isn't working
Projects
None yet
6 participants