Conversation
|
|
| aria-label={ariaLabel} | ||
| icon={icon} | ||
| {...props} | ||
| // TODO: does this make sense? it'll override IconButton's data-component |
There was a problem hiding this comment.
I feel like this indeed makes no sense, but does that mean that subcomponents like ActionBar.Menu don't have a data-component, despite being public subcomponents? how would you target them then?: [data-component="ActionBar"] [data-component="IconButton"] isn't specific enough because ActionBar.IconButton would match this as well 🤔
Should we wrap everything top-level in a span for these cases just so we can attach the data-component attribute? is there any chance for that to mess anything up?
There was a problem hiding this comment.
In this scenario, i think it makes sense to override the menu IconButton because there are other IconButtons in this component as well. (I'd call it ActionBar.MoreIconButton or ActionBar.MenuIconButton)
It's likely that it will be used with a classname on the ActionBar root .myActionBar [data-component=ActionBar.MoreIconButton]
That said, I don't think <Actionbar.IconButton> should get a data-component at all because
- they already have a data-component
- you can pass a classname to that
Should we wrap everything top-level in a span for these cases just so we can attach the data-component attribute?
Not a good idea because it will introduce nesting, which in best of cases is unnecessary and in the worst cases breaks dom validation rules or slots constraints
There will be other similar scenarios where we might choose to override the child's data-component when there are two distinct IconButtons that are baked in the component and not accessible in the API, for example the previous and next icon buttons in Pagination.
| icon={icon} | ||
| {...props} | ||
| // overriding IconButton's data-component so that the ActionBar's "More Menu" Icon can be targetted specifically | ||
| data-component="ActionBar.Menu.IconButton" |
There was a problem hiding this comment.
should this be:
- ActionBar.MenuIconButton
- ActionBar.Menu
- ActionBar.Menu.IconButton
?
I feel like this is the IconButton that belongs to the Menu that is a subcomponent of ActionBar, which is why ActionBar.Menu.IconButton makes sense to me 🤔. ActionBar.Menu seems disingenuous because really this is not the menu itself, just the Icon trigger. But I could see the case for ActionBar.MenuIconButton
There was a problem hiding this comment.
I vote for ActionBar.Menu.IconButton too!
There was a problem hiding this comment.
tl;dr: both ActionBar.MenuIconButton and ActionBar.Menu.IconButton are fine, i like one more than the other
ActionBar.Menu👎 that's for the menu, not the buttonActionBar.Menu.IconButtonit's fine, but the double dots feels weird, idk why. Maybe becauseActionBar.Menuis actually a shorthand forActionMenu... butActionBar.ActionMenu.IconButtonis worse.ActionBar.MenuIconButton: 👍 I like this the most. consistent pattern everywhere
| <HeadingWrap | ||
| role="presentation" | ||
| className={groupClasses.GroupHeadingWrap} | ||
| aria-hidden="true" | ||
| data-variant={variant} | ||
| data-component="GroupHeadingWrap" | ||
| data-component="ActionList.GroupHeading" | ||
| as={headingWrapElement} | ||
| {...props} | ||
| > | ||
| <span className={clsx(className, groupClasses.GroupHeading)} id={groupHeadingId}> | ||
| {_internalBackwardCompatibleTitle ?? children} | ||
| </span> |
There was a problem hiding this comment.
Here the actual user-supplied className is in the span within the "HeadingWrap";
Should the data-component always be where the className is? or does it make sense for it to go on the outermost element?
if so:
For this case, should we do: data-component="GroupHeading.Wrapper" and data-component="GroupHeading"?
If so:
does that mean we should always have data-component for wrappers?
|
🤖 Lint issues have been automatically fixed and committed to this PR. |
Towards https://github.com/github/primer/issues/6497
Changelog
New
Changed
Removed
Rollout strategy
Testing & Reviewing
Merge checklist