Skip to content

Conversation

@Mudaafi
Copy link
Contributor

@Mudaafi Mudaafi commented May 9, 2024

Pull Request Checklist

Before you submit a pull request, please make sure you have to following:

  • I have added or updated TypeScript types for my changes, ensuring they are compatible with the existing codebase.
  • I have added JSDoc comments to my TypeScript definitions for improved documentation.
  • I have added tests that prove my fix is effective or that my feature works.
  • I have added any necessary documentation (if appropriate).
  • I have made sure my PR is up-to-date with the main branch.

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no API changes)
  • Documentation content changes
  • TypeScript type definitions update
  • Other... Please describe:

@Mudaafi Mudaafi added the wip Edits in Progress label May 9, 2024
@linear
Copy link

linear bot commented May 9, 2024

CI-3134 [MVP] Create a Filters Component

Business Outcome:

  • As a Consumer I want Filters to be handled OOO so that I can fully port over my current implementation to use Constructor's OS UI Library

Definition of done:

  • Utilize the useFilters Hook
  • Takes in a Search Response object and renders the Filters
    • Should be able to render: multiple, range and range buckets
  • Tests
  • Documentation

Additional Notes:

https://www.figma.com/file/bWsxaLJGgHTX9ystM0Ko5Z/Open-Source-Demo?type=design&node-id=1%3A1317&mode=design&t=kL2O8RQZtPrsaepq-1

Screenshot 2023-12-23 at 12.55.42 AM.png

@Mudaafi Mudaafi removed the wip Edits in Progress label Jun 3, 2024
@Mudaafi Mudaafi requested review from a team and HHHindawy June 3, 2024 16:01
Copy link
Contributor

@HHHindawy HHHindawy left a comment

Choose a reason for hiding this comment

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

Looking good! Thanks for working on this!
Left you a couple of minor comments 🙏

if (optionsToRender.length === 0) return null;

return (
<div className={`cio-collapsible-wrapper${!isCollapsed ? ' cio-collapsible-is-open' : ''}`}>
Copy link
Contributor

Choose a reason for hiding this comment

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

A super minor thing to satisfy my OCD 😅
Can we add a space before ${!isCollapsed ? and remove the space here: ' cio-collapsible-is-open'

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hmm, if we add the space outside the conditional, it'd be rendered even if isCollapsed == true tho. I'd rather avoid the extra space but I guess we can call a .trim() at the end.

Copy link

Choose a reason for hiding this comment

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

Depending on how often these conditional classes come up, it might be worth bringing in a library like classnames if we want to keep things clean 😄

Otherwise, I don't have a strong opinion on either direction. If I had to choose, I'd go for keeping what we have already to keep the line of code shorter

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 to adding classnames, it's really useful!

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'm down for adding classnames. It seems like we'll need to add it as an actual dependency but it should be fine since it's only 752 bytes when minified, 436 bytes minified + gzipped

}, [visibleTrack]);

return (
<div className={`cio-collapsible-wrapper${!isCollapsed ? ' cio-collapsible-is-open' : ''}`}>
Copy link
Contributor

Choose a reason for hiding this comment

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

Same OCD comment 😅

</span>
<div className='cio-slider-input'>
<span className='cio-slider-input-prefix'>to </span>
<input
Copy link
Contributor

Choose a reason for hiding this comment

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

small thing: should inputs have white-colot background, same as checkboxes do?
Screenshot 2024-06-21 at 12 11 21

Copy link
Contributor

Choose a reason for hiding this comment

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

looking at the figma file, it may be the other way around... checkboxes shouldn't be white-color-bg?

Copy link
Contributor Author

@Mudaafi Mudaafi Jun 24, 2024

Choose a reason for hiding this comment

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

hmm interesting. I didn't actually mean to specify the color of the inputs. I think it's fine to set it to white to keep it consistent. I'll make the changes

Comment on lines +194 to +195
value={inputMaxValue}
onChange={onMaxInputValueChange}
Copy link
Contributor

Choose a reason for hiding this comment

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

we can leave blank any of the inputs, but after doing that the slider is not updated... should we move the respective bar to the end of the range? (that's what empty means after all, right? no-min/max)
Screenshot 2024-06-21 at 12 22 15

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not necessarily, it just means that the current value isn't set. The general experience is the filters re-apply after a change has been made, but in this state, we shouldn't reapply the filters, and the bar shouldn't move as well since it's an invalid state. I'd prefer either highlighting the border in red as we do for other invalid values, or making the corresponding sliding button slightly faded. wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

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

is there no way to just set a min value and not max? (for example, search 30+)
if that's the expected behavior then yeah, I'd agree with adding the red-error state

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nope, we'll need to set both before applying the filter since it's a range. The min-max defaults to the actual min-max of the result set so 30+ would just mean modifying the minValue. Now that you mentioned it, if we update minInputValue, we don't actually check if the maxInputValue is valid before we run the callback 🤔 . I'll add a check for it.

import Filters from './Filters';

export * from './Filters';
export default Filters;
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we have a reason we're not exposing the other Filters components utilized by Filters? Sorry if this was already discussed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No particular reason, but I didn't see other components in the library needing to use them. Do you mean exposing it so that library users can take advantage of them?

Copy link
Contributor

@mocca102 mocca102 left a comment

Choose a reason for hiding this comment

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

I see a lot of logic handled inside what should have been "Presentational Components" ie Components that should handle only UI.

This could be ok but let's assume I want to utilize the hooks and build the UI myself. All we're giving the users is useFilters(). We're not giving state nor click handler or anything else. So we're limiting the hook implementation by doing so.

I don't want us to handle this in this PR though if we're going to but lets have an internal sync on this. @Mudaafi

Copy link
Contributor

@lordvkrum lordvkrum left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@HHHindawy HHHindawy left a comment

Choose a reason for hiding this comment

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

LGTM!
Thanks for baring with us and making the changes!

@Mudaafi Mudaafi merged commit 743645a into main Jun 27, 2024
@Mudaafi Mudaafi deleted the ci-3134-mvp-create-a-filters-component branch June 27, 2024 18:12
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.

6 participants