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

feat(sidebar): connections filter popover COMPASS-8503 #6486

Merged
merged 12 commits into from
Nov 14, 2024

Conversation

kraenhansen
Copy link
Contributor

@kraenhansen kraenhansen commented Nov 13, 2024

Description

Merging this PR will:

  • Refactor the toggle-able active connections icon-button in the sidebar to a popover with a toggle.
  • Delete icons that was added but is no longer used.
  • Add a blue indicator on the icon button when a filter from within the popover is activated.
  • Update tests to reflect the changes.
connections-filter-popover-2.mov

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)

@bsradcliffe
Copy link
Contributor

@kraenhansen this LGTM! 👍🏻

We'll follow up with the LG team on the composability and configurability of their foundational components like labels, overline, and popovers.

Copy link
Contributor

@bsradcliffe bsradcliffe left a comment

Choose a reason for hiding this comment

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

LGTM! 👍🏻

@kraenhansen kraenhansen marked this pull request as ready for review November 13, 2024 15:42
@kraenhansen
Copy link
Contributor Author

Seems the test are failing as our CI infrastructure is getting rate-limited by the Docker registry.

@@ -388,16 +388,19 @@ function filteredConnectionsToSidebarConnection(
return sidebarConnections;
}

export type ConnectionsFilter = {
regex: RegExp | null;
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit and not something you changed, but I'm wondering why this ever used explicit null over just being optional / undefined.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It does 👍

try {
re = searchString ? new RegExp(searchString, 'i') : null;
} catch (e) {
re = null;
}

excludeInactive: boolean;
onFilterChange(regex: RegExp | null): void;
onToggleExcludeInactive(): void;
filter: ConnectionsFilter;
Copy link
Contributor Author

@kraenhansen kraenhansen Nov 13, 2024

Choose a reason for hiding this comment

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

I've combined the filterRegex and excludeInactive into a single filter prop as adding the pop-over suggests we might be adding more parameters for filtering in the future.

Copy link
Contributor

Choose a reason for hiding this comment

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

Makes sense. I believe that's the plan with the popover.

[onFilterChange]
);

const excludeInactiveToggleId = useId('exclude-inactive-toggle');
Copy link
Collaborator

Choose a reason for hiding this comment

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

useId with default argument just returns the argument you are passing, there is no reason to use it here if you're ids are constant

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Looking at use elsewhere in the codebase, I was under the impression that this would add some suffix to avoid conflicts if the component is mounted multiple places in the tree? But apparently I was wrong in that assumption 😬 Thanks.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah, good point, seems like a few misuses slipped through, opene #6491 to fix those

<InteractivePopover
open={open}
setOpen={setOpen}
blurTriggerOnClose
Copy link
Collaborator

Choose a reason for hiding this comment

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

It's a common accessible behavior to return focus back to the trigger, especially helpful if you're navigating with a keyboard, all leafygreen Menus are doing that and we are following their behavior here with our InteractivePopover. Why are we breaking the pattern here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added this because bringing back the focus makes the tooltip show even if it's not hoved 🤔 Perhaps I can return focus to something else?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For what it's worth, it seems the "tab position" is remembered. I.e. when tabbing after closing the popover you can continue to the connections tree.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Your focus is on body though, you don't get notificed by voice over that you're back on button. If we want to really address this, we probably should make sure that the button has a proper (aria-)label and shows tooltip only on hover where it makes sense to show it, not on keyboard focus, but this probably requires figuring this out with leafygreen team. You can probably circumvent this by using an extra sibling element as trigger and not the IconButton itself, this should also work. Or we can just ignore it, we're compromising on accessibility in a lot of other places too already 🤷

Copy link
Collaborator

Choose a reason for hiding this comment

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

One thing I would prefer though if possible is not to add a prop to a shared component that explicitly breaks its accessibility behavior. If we can hack around this outside of it to make this tooltip not show up in this exact place where we need this for some reason, that would be nice

Copy link
Contributor Author

@kraenhansen kraenhansen Nov 14, 2024

Choose a reason for hiding this comment

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

we're compromising on accessibility in a lot of other places too already 🤷

Yeah, but I agree we should avoid regressing further on this 👍

I reverted the change to add a blurTriggerOnClose prop and instead used Tooltip as a controlled component. I also updated the screen capture in the description above ☝️ Thanks a lot for the explanations and the comment in the first place 👍

Pass hideCloseButton instead of using display none
Fix generating unique ids
onClick={onClick}
active={open}
aria-label="Filter connections"
ref={ref as React.Ref<unknown>}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

To be honest, I didn't fully understand the need for this. It seems the InteractivePopover is using the React.LegacyRef type for ref, but 🤷 it works.

Copy link
Collaborator

@gribnoysup gribnoysup Nov 14, 2024

Choose a reason for hiding this comment

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

InteractivePopover was initially built to be used with button which has this specific type of the ref. It's our code, so if we need to change this to Ref (can probably change it to be a more generic HTMLElement instead of HTMLButtonElement too, but it might have more of a cascading effect) in the component types, we can, it would make sense and would still be compatible with types of "normal" html button refs

Copy link
Contributor Author

@kraenhansen kraenhansen Nov 14, 2024

Choose a reason for hiding this comment

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

I agree, that could probably be fixed with updates to the InteractivePopover. If you're okay with it, I suggest making that a follow-up PR.

@kraenhansen
Copy link
Contributor Author

kraenhansen commented Nov 14, 2024

I've already had a successful run on CI this morning and I've verified the changes I made since pass tests locally.
The failing jobs on CI is unrelated and as this is marked as a blocker for a new GA release, I'll go ahead and merge it.

@kraenhansen kraenhansen merged commit 5a6c445 into main Nov 14, 2024
20 of 25 checks passed
@kraenhansen kraenhansen deleted the kh/connections-filter-popover branch November 14, 2024 12:05
// Add future filters to the boolean below
const isActivated = filter.excludeInactive;

// Manually handling the tooltip state instead of supplying a trigger
Copy link
Contributor

Choose a reason for hiding this comment

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

❤️


// Manually handling the tooltip state instead of supplying a trigger
// we do this to avoid the tooltip from rendering when the popover is open
// and when the IconButton regains focus as the
Copy link
Contributor

Choose a reason for hiding this comment

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

Already merged, but your comment ends mid-sentence :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks: #6502

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants