| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
PatternFly-React preview: https://2278-pr-patternfly-react-patternfly.surge.sh |
Sorry, something went wrong.
Codecov Report
@@ Coverage Diff @@
## master #2278 +/- ##
========================================
Coverage ? 80.6%
========================================
Files ? 666
Lines ? 8441
Branches ? 720
========================================
Hits ? 6804
Misses ? 1274
Partials ? 363
Continue to review full report at Codecov.
|
Sorry, something went wrong.
|
PatternFly-React preview: https://patternfly-react-pr-2278.surge.sh |
Sorry, something went wrong.
|
The prop works as expected! 🎉 The only question I have is whether the prop should move to the parent <ChipGroup> component? With the Accordion component, we discussed this and ended up supporting the prop on the parent <Accordion> component, because in that component, it would be really odd to have different heading levels for different toggles (because there would then be a disconnect between the visual presentation and the semantic structure). I would think that same reason is true in this case, but am curious if anyone has some reason for supporting this prop on the <ChipGroupToolbarItem> component instead. I'm pulling in @mturley because he had provided suggestions on how to implement this for Accordion, and might have relevant info that would be helpful to share for this case as well. |
Sorry, something went wrong.
|
@boaz0, I agree with @jgiardino that we should probably have the consumer pass one headingLevel prop to the parent <ChipGroup> instead of having to pass it to each <ChipGroupToolbarItem>, since it reduces duplication in the consumer's code and prevents them from using different heading levels in the same chip group. @jenny-s51 implemented this for Accordion using React's Context API in this PR: https://github.com/patternfly/patternfly-react/pull/2290/files. Basically in the ChipGroup component you'd accept headingLevel as a prop and pass it to a ChipGroupContext.Provider, and then in ChipGroupToolbarItem you'd render a ChipGroupContext.Consumer that takes a function for a child, and this function can pull the headingLevel out of its arguments and return the children rendered with that headingLevel. If you need any help, feel free to let me know! |
Sorry, something went wrong.
|
@mturley no problem I will be working on this. |
Sorry, something went wrong.
|
@mturley updated PR feel free to review and give some feedback. |
Sorry, something went wrong.
Signed-off-by: Boaz Shuster <boaz.shuster.github@gmail.com>
|
@mturley thanks a lot! Would you mind reviewing this again? |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM! :)
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
There was a problem hiding this comment.
I have the same question as Joachim
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
|
Thank you all |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
What:
closes #2167