-
Notifications
You must be signed in to change notification settings - Fork 234
feat(compass-workspaces): introduce workspaces plugin; implement single top level tabs COMPASS-7354 #5169
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
Conversation
…le top level tabs
}) | ||
); | ||
}; | ||
onAppRegistryEvent('active-collection-dropped', onActiveCollectionDropped); |
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.
Not needed anymore, we just listen to the add / remove change events on the instance model
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.
GitHub collapsed the main store for the plugin
action.workspace.type === 'My Queries' || | ||
action.workspace.type === 'Databases' || | ||
action.workspace.type === 'Performance' |
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'll be moving tests from tabs.ts store to this one, in the meantime, the gist for the tab behavior is that we're trying to preserve the current tab / workspace relation:
If you open a new tab for the instance stuff, we'll always try to find an open one and switch to it, this matches the current compass behavior where we don't really have any way to open any of those in the new tab.
If you open anything that requires namespace: database collections list or collection tab, we'll replace the current active tab content with the new namespace tab, but only if the current tab type matches the new one that we're trying to open.
For example: if you'd try to open a collection while looking at "my queries" tab, this will open a new tab with the selected collection namespace. But if it's a collection tab for a different namespace that is active, we'll replace the content, same way it works right now.
For this project we're just keeping the behavior as close to the current one as possible with the change. Some changes might be made in the follow up project that is more focused on the UI part of compass web.
}; | ||
}; | ||
|
||
// TODO: events are re-emitted when tab is changed for compatibility reasons, |
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 is basically the biggest hack this PR has while sidebar and collections list plugins still relies on multiple events to get the current active workspaces state synced with its internal state. Removing the need for this will be the first thing I'll be addressing in the follow-up 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.
Looks pretty neat so far!
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.
interesting that git recognizes these a file move :) makes sense, still surprising
packages/compass-components/src/components/workspace-tabs/tab.tsx
Outdated
Show resolved
Hide resolved
3ff379c
to
e075009
Compare
9ef8d84
to
4e7dc6f
Compare
b98f460
to
b1fa44f
Compare
pipelineText?: string; | ||
editViewName?: string; | ||
} & CollectionMetadata; | ||
} & CollectionMetadata; // TODO: make collection-tab resovle metadata on its own |
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'm gonna assume these TODO comments are for the immediate follow-up PRs and not insist on ticket numbers :)
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 let me still add them, it would be easier to track those
navigationProps | ||
); | ||
|
||
useHotkeys( |
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.
All this is 😘
// Close all the workspace tabs to get rid of all the state we | ||
// might have accumulated. This is the only way to get back to the zero | ||
// state of Schema, and Validation tabs without re-connecting. | ||
await browser.closeWorkspaceTabs(); |
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 work cleaning up all these commands. Must have been a pain.
isDataLake, | ||
isWritable, | ||
changeFilterRegex, | ||
showCreateDatabaseAction = 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.
Nice! Much better naming here.
); | ||
const isDataLake = instanceFetched | ||
? state.instance?.dataLake.isDataLake | ||
: true; |
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 is a total nit, but since you're making the assumption that something is datalake when the instance isn't fetched so that the perf item won't show by default it is probably better/safer to just name this temp var showPerformanceItem immediately. Just in case someone comes along in future and uses isDataLake to display something specific to datalake and in that case you probably want false as a safer default?
Although that would complicate showCreateDatabaseAction below where you use isDataLake again, so maybe more trouble than its worth 🤔
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.
Hmmm, yeah, good point, I feel like I can just move this logic to a function where default value is provided and then it's not that complicated to use and the intent is explicit
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.
Refactored this a bit in 60f022d. A bit more verbose, but probably not a bad thing?
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.
Amazing work! The new tabs are so much nicer.
Trying this out a bit, I noticed that if you have two tabs of the same namespace open and click the tab on the right it only will open the tab on the left. |
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.
When I'm on the database tab and I click on a collection it opens the collection in a new tab. Is that expected? I'm thinking folks might end up with a lot of database tabs. Might have missed this if it was brought up elsewhere.
Looks like I get a runtime error when the active collection tab's collection is deleted and it's the only open tab:
Might be something we want to catch?
I dig the leaf on no open tab states, and the navigation to database when the active tab collection is deleted. Tabs look great.
It is in this implementation, yes. We can't exactly re-create the old behavior without bringing some old weirdness with it because we never had just one level of tabs before, so the behavior is as close to it as possible, but not exactly the same, I described it in the comment above and you can take a closer look at the reducer action handling. I personally feel like that's okay, we're adding tabs so that users can open a bunch of them and close if needed, and would rather adjust this later based on user feedback 🙂 Do you have concerns about more tabs opening? If yes, I can introduce a special workaround specifically for "Collections" workspace for now to make it even closer to the current behavior, it will stand out from how other tabs will work, but I'd rather try to avoid blocking this work on a bigger UX discussion, so happy to change this.
Thanks for spotting! Fixed in 5da6966 |
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!!
I do feel folks could end up with too many tabs if we're opening a new one everytime they click on a collection/database from one of the higher up namespace pages. I think it's fine for this version though. We can adjust later if we get feedback from folks.
Alrighty, merging! |
This patch is a first step in refactoring all tab handling logic into a single plugin to make sure that we have a single source of truth for the current active tab and don't need to rely on global events to sync those. For more details refer to the tech design.
As this touches a lot of code in Compass, this current PR introduces a minimal amount of changes to preserve feature parity with current tabs implementation, but doesn't include a full refactor for the tab opening events. It's just too much code changes already, I wanted to stop at something that is already mergeable. Some additional refactoring will be introduced in the follow-up PRs.
Changes in this PR:
Introduce a single top level row of tabs for all workspace types through the compass-workspaces plugin. Instead of having instance workspaces, database workspaces, and collection tab workspaces have a different top level tab logic, all these are now merged into a single row of tabs that work similar to the collection tabs
Remove compass-instance, compass-database, and collection-tabs plugins. They are redundant, compass-workspaces is now handling this logic.
Convert collection tab content plugin to new interface. Required so that compass-workspaces plugin can render it without relying on the old
configureStore
interfaceStill TODO in this PR:
Follow-up PRs to finish the work on the compass-workspaces will include:
openWorkspace
method exported from the compass-workspaces plugin to be used instead of eventsAll listed follow ups are better isolated from each other, so hopefully this is the only big PR needed for this particular work