Skip to content

Conversation

@mabaasit
Copy link
Collaborator

Description

Checklist

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)

);
});
// TODO: The connection is disconnected somehow/somewhere which triggers cleanup and
// tabs are removed and these assertions fail. Need to figure this out!
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this still outstanding?

Copy link
Collaborator Author

@mabaasit mabaasit Dec 16, 2024

Choose a reason for hiding this comment

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

phew, yeah! i spent quite some time in this PR to figure this out. i'll spend a bit more to figure out what triggers plugin cleanup for connections which leads to this failure.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Weirdly enough, doesn't look like it's failing in test-electron, so somehow this is runtime specific? It's very unexpected tbh, so we should really try to get to the bottom of this, ping me if you want to poke around in this together

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

i traced it down to mongoDBInstanceLocator not returning the correctly mocked instance. we hit this line and onNamespaceFallbackSelectRef is called and tab switches to default connection tab.

this actually also re-creates on main (if we give a small timeout before we do await waitFor).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

after some time, i changed the strings to regex in 963497c (coll1 and coll3 to /coll1/i and /coll3/i) and it started to pass. i still think we should investigate it a bit more to see what's going on here. (i did not expect it to pass with this change)

Comment on lines 135 to 136
// TODO: The connection is disconnected somehow/somewhere which triggers cleanup and
// tabs are removed and these assertions fail. Need to figure this out!
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I have spent lots of time figuring this out, but did not find a solution yet.

className: confirmationProps.hideCancelButton
? hideButtonStyles
: undefined,
children: confirmationProps.cancelButtonText ?? 'Cancel',
Copy link
Collaborator Author

@mabaasit mabaasit Dec 16, 2024

Choose a reason for hiding this comment

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

Its always Cancel now and LG removed children prop.

Copy link
Collaborator

@gribnoysup gribnoysup Dec 16, 2024

Choose a reason for hiding this comment

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

i think you are referring to confirmButton props, which still exists. but my comment refers to cancelButton props, which is defined as https://github.com/mongodb/leafygreen-ui/blob/24c828d24c484cf8d02b777faa2dacc4b4ec2452/packages/confirmation-modal/src/ConfirmationModal/ConfirmationModal.types.ts#L16-L17

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah, right, misread when expanding the code in github, thanks for pointing this out!

Comment on lines -87 to -93
export const withStackedComponentPopoverStyles = function <
ComponentProps extends { popoverZIndex?: number }
>(
WrappedComponent: ComponentType<ComponentProps>
): ComponentType<ComponentProps> {
return withBaseStyles(WrappedComponent, true);
};
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

this becomes irrelevant with packages bump and Popover has marked popoverZIndex as deprecated.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Is there another way to provide the index now? We need to confirm this doesn't break compass-web in mms

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, i'll check this with mms integration (using sync-with-mms script)

@mabaasit mabaasit changed the title chore(deps): update LG packages chore(deps): update LG packages COMPASS-8611 Dec 16, 2024
Comment on lines +42 to +86
const menuItems = useMemo(() => {
return [
{
label: 'Add stage after',
onClick: () => {
onAddStageClick(index);
setMenuOpen(false);
},
icon: 'PlusWithCircle',
},
{
label: 'Add stage before',
onClick: () => {
onAddStageClick(index - 1);
setMenuOpen(false);
},
icon: 'PlusWithCircle',
},
{
label: 'Delete stage',
onClick: () => {
onDeleteStageClick(index);
setMenuOpen(false);
},
icon: 'Trash',
},
{
label: 'Expand documents',
onClick: () => {
onExpand(index);
setMenuOpen(false);
},
icon: 'ChevronDown',
},
{
label: 'Collapse documents',
onClick: () => {
onCollapse(index);
setMenuOpen(false);
},
icon: 'ChevronUp',
},
];
}, [index, onAddStageClick, onDeleteStageClick, onExpand, onCollapse]);

Copy link
Contributor

@kraenhansen kraenhansen Dec 16, 2024

Choose a reason for hiding this comment

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

I've seen us doing this pattern elsewhere, but why do you see this being advantageous over simply rendering the children? I see possibilities of making the existing code more DRY without falling back on this pattern of building component trees from arrays of "data". In any case, would it make sense to separate this out into its own PR or does it have to be included in this work?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I added this to simply avoid adding data-text prop in the menu item because i did not want to repeat the text.
How would you prefer to clean this?

open={isOpen}
setOpen={setIsOpen}
usePortal={false}
popoverZIndex={999999}
Copy link
Contributor

Choose a reason for hiding this comment

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

💙

Copy link
Contributor

@kraenhansen kraenhansen left a comment

Choose a reason for hiding this comment

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

Always nice to see dependencies being updated 👍 I don't see anything holding back a merge.

@mabaasit
Copy link
Collaborator Author

Always nice to see dependencies being updated 👍 I don't see anything holding back a merge.

I am waiting to test this locally with mms integration and see if everything goes fine. My local setup it a bit broken and if it takes longer, I'll merge it.

@mabaasit mabaasit merged commit 3c302b9 into main Dec 17, 2024
29 checks passed
@mabaasit mabaasit deleted the lgupdate branch December 17, 2024 09:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants