feat(chipGroup): add heading level prop to toolbar chip group label

[boaz0]

What:

closes #2167

• add heading level prop to ChipGroup
• pass heading level to Chip Group Toolbar item through Context API
• update tests
• HeadingLevel type was moved from Title to helpers
• Chip Group Toolbar Item is using HeadingLevel type in its own heading level prop

[patternfly-build]

PatternFly-React preview: https://2278-pr-patternfly-react-patternfly.surge.sh

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@a5d571e). Click here to learn what that means.
The diff coverage is 0%.

@@           Coverage Diff            @@
##             master   #2278   +/-   ##
========================================
  Coverage          ?   80.6%           
========================================
  Files             ?     666           
  Lines             ?    8441           
  Branches          ?     720           
========================================
  Hits              ?    6804           
  Misses            ?    1274           
  Partials          ?     363

Flag	Coverage Δ
#patternfly3	85.23% <ø> (?)
#patternfly4	76.18% <0%> (?)
#patternflymisc	95.79% <ø> (?)

Impacted Files	Coverage Δ
...ernfly-4/react-core/src/components/Title/Title.tsx	94.11% <ø> (ø)
.../src/components/ChipGroup/ChipGroupToolbarItem.tsx	50% <0%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a5d571e...65e2fde. Read the comment docs.

[patternfly-build]

PatternFly-React preview: https://patternfly-react-pr-2278.surge.sh

[jgiardino]

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.

[mturley]

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

[boaz0]

@mturley no problem I will be working on this.
Thanks for your feedback!

[boaz0]

@mturley updated PR feel free to review and give some feedback.

[mturley]

Thanks for your quick update @boaz0 ! Your actual changes look great, I'm just a little obsessed with code style today.

[boaz0]

@mturley thanks a lot! Would you mind reviewing this again?

[jessiehuff]

LGTM! :)

[tlabaj]

LGTM

[tlabaj]

I have the same question as Joachim

[tlabaj]

LGTM

[boaz0]

Thank you all
@jgiardino @mturley @jessiehuff @jschuler @tlabaj