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

Replace second line for filters with UI from segments variant D #5022

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

apata
Copy link
Contributor

@apata apata commented Jan 27, 2025

Changes

  • Removes the second line for filters that's shown when saved_segments feature flag is true, replacing it with the single line version from segments variant D and the multicolumned filter menu from the same.
    • For users that don't have the feature flag (pretty much all of them), no visual changes are expected, except a few tiny tweaks that deal with what happens in the top bar in the overflow situation.
  • Refactors filter pills so their drop shadows wouldn't be cut off by overflow: hidden.
  • Creates non-interactive filter pill and pill list versions (in anticipation of segment modals).

Tests

  • Automated tests have been added

Changelog

  • This PR does not make a user-facing change

Documentation

  • This change does not need a documentation update

Dark mode

  • The UI has been tested both in dark and light mode

Visuals

pr-5022 review plausible io_plausible io_f=is,page,__dashboard f=is,country,US f=is,region,US-IL l=US,United%20States l=US-IL,Illinois (1)

@apata apata changed the title Replaces Replaces second line for filters with UI from segments variant D Jan 27, 2025
@apata apata changed the title Replaces second line for filters with UI from segments variant D Replace second line for filters with UI from segments variant D Jan 27, 2025
@apata apata force-pushed the saved-segments/singular-bar branch from a0317c6 to 07e1127 Compare January 27, 2025 19:15
@apata apata added the preview label Jan 28, 2025
Copy link

Preview environment👷🏼‍♀️🏗️
PR-5022

@@ -56,7 +53,10 @@ export default function CurrentVisitors({ tooltipBoundary }) {
>
<AppNavigationLink
search={(prev) => ({ ...prev, period: 'realtime' })}
className="h-9 flex items-center ml-1 mr-auto text-xs md:text-sm font-bold text-gray-500 dark:text-gray-300"
className={classNames(
Copy link
Contributor Author

@apata apata Jan 28, 2025

Choose a reason for hiding this comment

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

Final positioning in this component and some others like site switcher and date picker is now with className prop.

Comment on lines +16 to +20
const BUFFER_RIGHT_PX = 16 - BUFFER_FOR_SHADOW_PX - PILL_X_GAP
const BUFFER_LEFT_PX = 16 - BUFFER_FOR_SHADOW_PX
const SEE_MORE_WIDTH_PX = 36
const SEE_MORE_RIGHT_MARGIN_PX = BUFFER_FOR_SHADOW_PX + PILL_X_GAP
const SEE_MORE_LEFT_MARGIN_PX = BUFFER_FOR_SHADOW_PX
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The idea here is to have a constant separation equivalent to gap-x-4 (16) between pills and top bar left actions, top bar right actions.

These calculations are needed, because pills include a margin around them (BUFFER_FOR...), which if not taken into account, causes misalignment.

Width calculations include the pills and the gaps:
[pill1] [pill2] [pill3] is cut right before [pill 2] ->
[pill1]

That's why the buffers are different for left and right.

@apata apata requested a review from macobo January 28, 2025 08:18
@apata apata changed the base branch from saved-segments/expand-segments-query-from to master January 28, 2025 09:14
@apata apata force-pushed the saved-segments/singular-bar branch from 07e1127 to 85878b7 Compare January 28, 2025 09:18
@apata apata requested review from ukutaht and removed request for macobo January 28, 2025 09:48
onClick={() => onRemoveClick()}
<div className={className}>
<div
style={{ margin: BUFFER_FOR_SHADOW_PX }}
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is style property used here as opposed to a tailwind class?

Copy link
Contributor Author

@apata apata Jan 28, 2025

Choose a reason for hiding this comment

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

I need the numeric values for calculations: I can't generate the custom classes dynamically because https://tailwindcss.com/docs/detecting-classes-in-source-files#dynamic-class-names. I could declare the string class names like BUFFER_CLASS = "m-[4px]", which TW detects properly, and then parse these class name strings to get the px values, but it's a bit more messy.

Ideally, of course, I'd not need these weird calculations, and it's probably possible to get rid of them when either
A) scrapping the partially expanded filters mode (as in designs) in favor of prod version: all shown or none shown
B) refactoring filter pills and pill lists more

ref={seeMoreRef}
dropdownContainerProps={{
['title']: opened ? 'Show less' : 'Show more',
['aria-controls']: 'more-filters-menu',
Copy link
Contributor

Choose a reason for hiding this comment

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

We already have headlessui as a dependency. Consider using the dropdown menu component over a hand-rolled dropdown to get things like aria properties for free.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed with the principle overall. Alas, headlessui doesn't align with accessibility standards (tab navigation between items) and that's why I refactored datepicker out of it last year. I wanted to keep new UI aligned with datepicker, thus I kept this custom component.

Maybe we want to align with the storybook dropdown instead?

Copy link
Contributor

Choose a reason for hiding this comment

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

headlessui doesn't align with accessibility standards (tab navigation between items)

What standard specifically? AFAIK accessible menus should be navigable via arrows and items should have tabindex="-1" which headlessUI does https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/menu_role

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right, MDN is clear on that! My gut feel had solidified to a standard since the last time we talked about this: #4461 (comment)

Still, the question remains which components to refactor and when. There's a few on the dashboard, but also https://plausible.io/storybook/dropdown is on tab navigation.

@ukutaht
Copy link
Contributor

ukutaht commented Jan 28, 2025

Problem: when a filter is added the page jumps vertically by a little bit, but enough to be annoying:

Cap.2025-01-28.at.12.17.07.mp4

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

Successfully merging this pull request may close these issues.

2 participants