chore(my-queries): support for multiple connections for my-queries COMPASS-7904, COMPASS-7915

[himanshusinghs]

Description

This PR introduces following changes:

• "My Queries" plugin work now with ConnectionsManager and InstancesManager instead of DataService and MongoDBInstance
• We don't rely anymore on singleConnectionConnectionInfo that we introduced at some point to render "My Queries" plugin. Instead, we have taken a more optimistic route which is to use useActiveConnections hook to get a hold of current active connections and work with the very first connection that we find, to render "CompassSidebar", "CompassShell" and interaction in "My Queries" plugin for single connection mode

For the saved aggregations and queries these are the changes to be expected:

State	What to expect	Modal
Connected to just one connection, trying to open the query and the namespace exists	Opens the query in the target namespace
Connected to just one connection, trying to open the query and the namespace does not exist	Opens the modal asking for another namespace, connection is already selected and the dropdown is not shown
Connected to multiple connections, trying to open the query and the namespace exists in only one of the connections	Opens the query in the only connection with the namespace
Connected to multiple connections, trying to open the query and the namespace exists multiple connections	Opens the modal to choose a connection from one of the connections that have the namespace
Connected to multiple connections, trying to open the query and the namespace does not exist in any of the active connections	Opens the modal asking for a connection and another namespace

There is additionally a new context menu item called "Open in" added when in multiple connections mode to explicitly open a query in a different connection / namespace.

Entry	What you see when connected to multiple connections	What you see when connected to just one connection

Checklist

• New tests and/or benchmarks are included
• Documentation is changed or added
• I have signed the MongoDB Contributor License Agreement (https://www.mongodb.com/legal/contributor-agreement)

Motivation and Context

• Bugfix
• New feature
• Dependency update
• Misc

Open Questions

Dependents

Types of changes

• Backport Needed
• Patch (non-breaking change which fixes an issue)
• Minor (non-breaking change which adds functionality)
• Major (fix or feature that would cause existing functionality to change)

[himanshusinghs]

This modal is for a case that was not discussed when planning for this and hence I would say not final but I am hoping to keep this until Ben is back and we have a chance to discuss this.

[himanshusinghs]

This file appears deleted but I actually renamed it to select-connection-and-namespace-modal.tsx. Most of the original content of the file is preserved and I have mostly modified the component props and its mapState

[lerouxb]

One question would be why you're using radio buttons rather than the selectbox in the "Select a Connection" modal.

[himanshusinghs]

One question would be why you're using radio buttons rather than the selectbox in the "Select a Connection" modal.

No specific reason other than that it was in the design. But IIRC Ben was also re-contemplating the idea of using select box for this. I can check in with him once he's back and if it needs changing then I can quickly iterate over that?

[paula-stacho]

I've seen this isAction approach in other places, can I ask what is the benefit of this against the switch?

[himanshusinghs]

I noticed some inconsistencies in the reducer like accessing non-existent parameters on passed actions. This isAction helps to get around that as it validates wether a received action is of the expected type.

[lerouxb]

I'm thinking the rules are too complicated and would propose:

• If you're not connected to anything, tell the user to connect to something first.
• If you're just connected to one connection, proceed as we do in the single connection world.
• If you're connected to multiple things, make the user select a connection and confirm the namespace within that connection.

If we're going to make an exception where we prefer the "active" connection I think there will be trouble because as we've seen even in the single connection world the sidebar easily scrolls and I don't think there's anything we can do that will make it super obvious enough which connection will be used. At most I'd pre-select the current selection but still show the modal and make the user chooses so that they confirm.

ie. we'd only have the two modals: Select a namespace (like we do today) and Select a Connection and Namespace. I don't know how/where we'd display to the user that you have to connect to something first. But I think we should try and avoid having another way of kicking off a new connection.

[himanshusinghs]

So for the points that you mentioned Le Roux, we do follow the first and the second, and only for the third point we try to detect if namespace is available in only one or multiple of the active connections.

But that is also only to keep the user experience consistent for the simplest of the use-case which is - when we try to open the query and the namespace for the query exists only in one connection we simply open the query in that connection.

[paula-stacho]

since we have the OpenedModal: no-active-connections-modal in redux, and for example openItem action handles most of the decision making on which modal to use -> wouldn't it make sense to move the if no connections -> no-active-connections-modal bit to redux as well?

[himanshusinghs]

since we have the OpenedModal: no-active-connections-modal in redux, and for example openItem action handles most of the decision making on which modal to use -> wouldn't it make sense to move the if no connections -> no-active-connections-modal bit to redux as well?

Yea I think we can do this - I will push a commit for that.
(pushed 81d2b66)

[paula-stacho]

Nice! 🎉

[lerouxb]

I still have some concerns about the design, but I suppose we can deal with those during the feedback phase.

[himanshusinghs]

@lerouxb yea - it would be amazing if you could add those to the findings doc so that we don't loose the thought of it.