-
Notifications
You must be signed in to change notification settings - Fork 6
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
Floating Data Catalog Filters Sidebar Follow-up and starting some cleaning and modularizing #930
Floating Data Catalog Filters Sidebar Follow-up and starting some cleaning and modularizing #930
Conversation
✅ Deploy Preview for veda-ui ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Demo of how this looks in the GHG instance will be following soon... |
Demo here: |
Very nice and helpful demo, thanks!
Exactly
I imagine this is quite tricky, because you may also need to scroll the side bar in some cases and it does not have its own scroll bar? 🤯 Let me test a bit more on a GHG Center preview (I can set that up shortly) and also see what @faustoperez says, before you make any more changes. |
Created a GHG Center preview here: |
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.
Ah I see it's more complicated than I thought in the first place, as the height of the element with the accordions and the parent need to be calculated for it to work 🤯 .
To move things forward, I am approving this PR, but let's revisit the behavior after the v2 release.
Ideally, the sidebar would stick at the bottom of the main content when scrolling, it wouldn't scroll up.
Here's a plugin I found in case it helps: https://github.com/blixhavn/sticky-sidebar-v2?tab=readme-ov-file
And a demo: https://blixhavn.github.io/sticky-sidebar-v2/examples/scrollable-element.html
+1 |
ae04d76
to
42cbe65
Compare
42cbe65
to
1e111b2
Compare
I pushed some changes that include
|
const [count, setCount] = useState<number>(0); | ||
const [selected, setSelected] = useState<OptionItem[]>([]); | ||
const targetRef = React.useRef<HTMLDivElement>(null); |
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.
Is there any need to introduce the pattern of using React.useRef
? I am not sure we can set it up as a lint rule, but all other parts of the code explicitly import {useRef}
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 a pattern, can just explicitly import or use like this
setAllSelectedFilters([]); | ||
}, [setAllSelectedFilters]); | ||
|
||
React.useEffect(() => { | ||
useEffect(() => { | ||
if (clearedTagItem && (allSelectedFilters.length == prevSelectedFilters.length-1)) { | ||
onAction(Actions.TAXONOMY_MULTISELECT, { key: clearedTagItem.taxonomy, value: clearedTagItem.id}); | ||
setClearedTagItem(undefined); | ||
} | ||
}, [allSelectedFilters, clearedTagItem]); |
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 noticed warnings about useEffect
has missing dependencies throughout this component. Do you mind putting comments on why those dependencies are excluded? It would help me navigate the code better.
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.
Sure. We have missing dependencies sprinkled throughout the existing codebase already. We can start making notes going forward why some arn't included and as a team create standardization around this in-code documentation
Awesome, the scrolling experience is great now - the filters are visible until the very end of the dataset list and the behavior takes into account the actual height of the side bar. This way, users will always be able to see the filters. One deviation from the design is that the pills that indicate the active filters and give a shortcut to removing them are added in the right column, above the dataset list: Instead of between search bar and filters: That means that the shortcut to removing individual filters disappears from view quite quickly as the user scrolls down the filtered list. Was this a change you discussed, @faustoperez and @sandrahoang686? We could keep that refinement to yet another PR, though, and ship this increment already. 👌 |
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.
As noted in #930 (comment), the implementation works very nicely!
The small difference from the designs in terms of placement of the filter removal pills is ok for now for me.
Related Ticket:
Closes #926
Description of Changes
100%
when filters sidebar height (when all expanded) is greater than or equaled to the height of all the cardsposition:sticky
when filters sidebar height (when all expanded) is less than height all of cardsprepareDatasets
to own logic file - cleaningNotes & Questions About Changes
DEMO Here:
https://www.loom.com/share/5f88edba7ca4422d9f2636464cebf7b6?sid=62ae3536-4174-4de0-adfe-a19b2e4a5893
Validation / Testing