-
Notifications
You must be signed in to change notification settings - Fork 418
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
Object Switcher: Added props for combobox #1638
Conversation
- support cross-entity - loading - default value - disabled - Menu: Footer and Header
Hello Stephen, are you going to merge this PR or something wrong with it ? |
@seirykborys I apologize if I was unclear. The deployment was of your pull request branch's code and not a release of the library. You can see your code deployed to a Heroku (PaaS) "reivew app" here. My request was to add the header (Search salesforce) and the footer (Add item) of the menu items to the keyboard (arrow keys up/down) navigation to make the new menu items you added accessible to keyboard users. I was waiting for this feature before I continued to review and merge the code in. The other option is that I believe I have time in the next few weeks to complete this ask if you'd prefer me to finish up the feature. |
@seirykborys @interactivellama Would be more than happy to move this forward if y'all are occupied 😄 |
@tanhengyeow Yes, that would be great. It's mostly done. I haven't looked at it in a while, but the primary issue is that the menu list header and footer are not in the index when the keyboard arrows are used. They should be accessible for keyboard users just like the other items. |
@davidlygagnon Would you be willing to finish this PR up. This is mostly an accessibility ask to complete. You know Combobox so well, I think knocking this out wouldn't be too difficult. |
Sounds good - I'll wrap this up. |
/** | ||
* Provided to input to make it disabled | ||
*/ | ||
disabled: PropTypes.bool, |
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 sure why he added this? We already have singleInputDisabled
. We would need to figure out what it means to disable the input for the cases where it's not a single select.
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.
Please remove. There will never be an all variants disabled prop on a combobox. If folks want to hack with with input
prop. They can I think.
/** | ||
* Default value of input. Provide uncontroled behaviour | ||
*/ | ||
defaultValue: PropTypes.string, |
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 call this defaultInputValue
?
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.
Can this be added in the input prop? If so, please remove. I'd like to not promote it.
/** | ||
* Object for creating Add item below the options | ||
*/ | ||
optionsAddItem: PropTypes.shape({ |
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.
@interactivellama Wouldn't it be better to include this as part of the options object and have a different type
attribute ? Something like option.type='header'
and option.type='footer'
Same question goes for optionsSearchEntity
? Under the hood, it was much cleaner to "merge" those 2 props with options
to get the same keyboard nav behavior and highlighting on mouse over. Plus, we wouldn't need to have 2 extra props.
Other question is: If we keep as is, I'd suggest having a more generic name: optionsHeaderItem
and optionsFooterItems
?
Also, should it accept an array instead of just one prop?
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 the idea was that you wouldn't want to pass it through the filter like the other items on keypress--and that the data type is different since it's not data, it's UI chrome in a way.
As to type, I think I've seen multi-entity searching on Platform such as Accounts, Users, etc. so an array might make more sense. My original proposal called for arrays. I don't think I had caught it in the previous review. Good catch!
As to naming, I was hoping to keep it semantic just in case it ever changed places. such as Add Item moved to the top or something. Do you foresee different footer needs. As you say, it might be good to future proof it as a head/footer. I could go either way.
Replacing with #1986 |
Fixes #1600
Additional description
CONTRIBUTOR checklist (do not remove)
Please complete for every pull request
npm run lint:fix
has been run and linting passes.components/component-docs.json
CI tests pass (npm test
).REVIEWER checklist (do not remove)
components/component-docs.json
tests.Required only if there are markup / UX changes
last-slds-markup-review
inpackage.json
and push.last-accessibility-review
, topackage.json
and push.npm run local-update
within locally cloned site repo to confirm the site will function correctly at the next release.