-
Notifications
You must be signed in to change notification settings - Fork 2
[CI-3134] Filters Components #77
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
Conversation
CI-3134 [MVP] Create a Filters Component
Business Outcome:
Definition of done:
Additional Notes: |
HHHindawy
left a comment
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.
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' : ''}`}> |
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.
A super minor thing to satisfy my OCD 😅
Can we add a space before ${!isCollapsed ? and remove the space here: ' cio-collapsible-is-open'
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.
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.
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.
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
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.
+1 to adding classnames, it's really useful!
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'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' : ''}`}> |
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.
Same OCD comment 😅
| </span> | ||
| <div className='cio-slider-input'> | ||
| <span className='cio-slider-input-prefix'>to </span> | ||
| <input |
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.
looking at the figma file, it may be the other way around... checkboxes shouldn't be white-color-bg?
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.
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
| value={inputMaxValue} | ||
| onChange={onMaxInputValueChange} |
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.
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?
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 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
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.
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; |
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.
Do we have a reason we're not exposing the other Filters components utilized by Filters? Sorry if this was already discussed
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.
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?
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 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
lordvkrum
left a comment
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
HHHindawy
left a comment
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!
Thanks for baring with us and making the changes!


Pull Request Checklist
Before you submit a pull request, please make sure you have to following:
PR Type
What kind of change does this PR introduce?