-
Notifications
You must be signed in to change notification settings - Fork 36
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
DOP-3690: Initial implementation of Search Facets UI #925
Conversation
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.
Looks gorgeous. Two things:
- Should there be downward arrows to the left of these option groupings that have hidden expansions? This could be a later ticket, just wondering. I'll attach an example from the figma.
Note: it's a bit confusing because in the figma all the examples are for versions (which are ignored here, I know), but I'm wondering if options such as "Atlas" which have so many other options nested should have the arrows and option to open it up without selecting it.
- TOTAL nit. But I had a slow brain moment for a while looking back and forth between FacetOption and FacetValue. Thinking there might be a better naming convention? I do not have perfect "options" here but something like FacetOption -> FacetGroup(ing) and FacetValue -> FacetOption? Not sure. Also, disregard if you like!!
font-size: 13px; | ||
line-height: 20px; | ||
color: ${palette.gray.dark4}; | ||
margin: 8px 0; |
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.
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.
Done! Changed the bottom to be 16px, as recommended by Iz
{truncated && ( | ||
<div className={cx(showMoreStyle)} onClick={handleExpandResults}> | ||
<Icon className={cx(showMoreGlyphStyle)} glyph={'ChevronDown'} /> | ||
Show more | ||
</div> | ||
)} | ||
</div> | ||
); |
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 think it's worth asking Iz if we want a "show less" option as well for the opposite of these.
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.
You're right! Done!
({ target, key, id }) => { | ||
const { id: fullFacetId, checked } = target; | ||
|
||
// Update query params based on whether a facet a is being added or removed |
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.
Just typing error :)
"on whether a facet is being"
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.
Hehe, good catch. I think I ended up removing the comment as part of a small refactor :P
<Body className={cx(optionNameStyle)} weight={'bold'}> | ||
{name} | ||
</Body> |
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.
This is random, and I don't want to hardcode, but are we going with "Target Product" as the name for "Product" or do we need to change the data model or do we need to create a frontend translation?
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.
we will have to change the taxonomy file for preservation of order and naming
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.
this looks great! couple of minor design comments and code cleanup comments below. thanks for putting the front end to fruition @rayangler !
/> | ||
{isChecked && | ||
facets.map((facet) => { | ||
return <FacetOption key={facet.id} className={cx(nestedFacetStyle)} facetOption={facet} isNested={true} />; |
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.
should we just pass the isNested prop? seems like we can style here for FacetOption but we are passing a classname for FacetOption styling set in FacetValue
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.
Done. Moved the styling accordingly
<Body className={cx(optionNameStyle)} weight={'bold'}> | ||
{name} | ||
</Body> |
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.
we will have to change the taxonomy file for preservation of order and naming
Updated the implementation to have Atlas's subfacets always shown as requested by design. Iz mentioned that the arrow to the left should only be shown to display versions for a facet (like Atlas CLI, but this will be addressed separately). We want Atlas and its subfacets to always be shown, so we don't want that caret/arrow present. Other facets that have subfacets will only show their subfacets when the parent is clicked on (like Realm).
Yup, I tried to name the components based on the data types received in the response. That being said, I do like using |
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.
this largely LGTM.
on a minor note, should we be resetting facet selections on a new search query? or persist user selected facets
} | ||
`; | ||
|
||
const FacetValue = ({ facetValue: { name, facets, key, id } }) => { | ||
const { handleFacetChange, selectedFacets } = useContext(SearchContext); | ||
const initChecked = (searchParams, key, id) => searchParams.getAll(`facets.${key}`).includes(id); |
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.
minor. we can export FACETS_KEY_PREFIX
from SearchContext
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.
Good idea. Done
Current search implementation in prod shows that filters are kept between searches. Let's check back in with design to confirm expected behavior and handle separately if needed |
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.
the useEffect actually has to account for facets now 🤦 we totally overlooked this. was wondering why the results was not refreshing.
this should also be distinguished between the showFacets or not property
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.
Spoke briefly about this offline. This PR intentionally omitted this as the initial UI implementation's goal was to focus on displaying facets. We can have a separate ticket or PR as needed to handle successful queries
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.
LGTM!! Great work. So nice.
For posterity, putting here that (although very rare) I suppose I worry a bit about max url size in how we're using these params. If a user were to click idk like 70% of the facets so far (and in the future with versions, it would be less) the max char limit of 2,083 for a url will be hit.
Once again, don't think this will be an issue, but want to voice it.
This is a good callout. Seems like this limit is browser-dependent and it seems like we're fine for now. I agree we should definitely be mindful of how long our urls get. Let's revisit as we finalize the UI and data |
Stories/Links:
DOP-3690
Current Behavior:
Search page - prod
Staging Links:
Search page with feature flag - no facets applied
Search page with feature flag - facets applied
Search page without feature flag - old filters, should have no changes from prod
Notes: