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

DOP-3690: Initial implementation of Search Facets UI #925

Merged
merged 22 commits into from
Oct 6, 2023
Merged

Conversation

rayangler
Copy link
Collaborator

@rayangler rayangler commented Sep 29, 2023

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:

  • The order and names of the facet options/categories may not currently match the designs. This is due to the current order of the taxonomy. The frontend should be responsible for rendering the order of the data as-is. A separate change may be needed to update the taxonomy accordingly.
  • Versions are not currently included in this UI due to lack of data. These can be added separately.
  • Selecting facets currently does NOT update the search results. I believe this may intersect with DOP-3689's goal of having the context responsible for API requests.

@rayangler rayangler marked this pull request as ready for review September 29, 2023 15:08
Copy link
Collaborator

@mmeigs mmeigs left a 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:

  1. 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.
Screenshot 2023-09-29 at 2 00 27 PM
  1. 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;
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: In some places, this feels a little squished on the bottom compared to the Figma file.
Screenshot 2023-09-29 at 1 48 18 PM
Screenshot 2023-09-29 at 1 48 30 PM

Copy link
Collaborator Author

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

Comment on lines 53 to 60
{truncated && (
<div className={cx(showMoreStyle)} onClick={handleExpandResults}>
<Icon className={cx(showMoreGlyphStyle)} glyph={'ChevronDown'} />
Show more
</div>
)}
</div>
);
Copy link
Collaborator

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.

Copy link
Collaborator Author

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
Copy link
Collaborator

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"

Copy link
Collaborator Author

@rayangler rayangler Oct 5, 2023

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

Comment on lines 46 to 48
<Body className={cx(optionNameStyle)} weight={'bold'}>
{name}
</Body>
Copy link
Collaborator

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?

Copy link
Collaborator

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

Copy link
Collaborator

@seungpark seungpark left a 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 !

src/components/SearchResults/SearchResults.js Outdated Show resolved Hide resolved
src/components/SearchResults/SearchContext.js Outdated Show resolved Hide resolved
src/components/SearchResults/Facets/FacetValue.js Outdated Show resolved Hide resolved
/>
{isChecked &&
facets.map((facet) => {
return <FacetOption key={facet.id} className={cx(nestedFacetStyle)} facetOption={facet} isNested={true} />;
Copy link
Collaborator

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

Copy link
Collaborator Author

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

Comment on lines 46 to 48
<Body className={cx(optionNameStyle)} weight={'bold'}>
{name}
</Body>
Copy link
Collaborator

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

src/components/SearchResults/Facets/FacetOption.js Outdated Show resolved Hide resolved
@rayangler
Copy link
Collaborator Author

rayangler commented Oct 5, 2023

@mmeigs

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.

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).

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!!

Yup, I tried to name the components based on the data types received in the response. That being said, I do like using FacetGroup instead of FacetOption. I think it might make sense to keep FacetValue named as is for now to minimize overlapping terminology between component and data (i.e. FacetOption doesn't represent facet-option but facet-value)

@rayangler rayangler requested a review from seungpark October 5, 2023 18:21
@rayangler rayangler requested a review from mmeigs October 5, 2023 18:21
Copy link
Collaborator

@seungpark seungpark left a 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);
Copy link
Collaborator

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good idea. Done

@rayangler
Copy link
Collaborator Author

on a minor note, should we be resetting facet selections on a new search query? or persist user selected facets

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

Copy link
Collaborator

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

Copy link
Collaborator Author

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

Copy link
Collaborator

@mmeigs mmeigs left a 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.

@rayangler
Copy link
Collaborator Author

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.

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

@rayangler rayangler merged commit 1289447 into master Oct 6, 2023
@rayangler rayangler deleted the DOP-3690 branch October 6, 2023 21:28
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.

3 participants