Conversation
🦋 Changeset detectedLatest commit: 1cbc315 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
| 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.IconButtonfeels worse for some reason.ActionBar.MenuIconButton: 👍 I like this the most. consistent pattern everywhere
There was a problem hiding this comment.
Hmmmmmm, I know i'm being very inconsistent with my feeling or taste™, but i like ActionList.Item.Label there because ActionList.Item is where you would put your className 🤔
❌ bad:
<ActionList>
<ActionList.Item><span className={styles.myLabel}>label</span></ActionList.Item>
</ActionList>
<style>
.myLabel {
font-weight: bold
}
</style>✅ good:
<ActionList>
<ActionList.Item className={styles.myActionListItem}>label</ActionList.Item>
</ActionList>
<style>
// with direct data-component, good!:
.myActionListItem [data-component="ActionList.Item.Label"] {
font-weight: bold
}
</style>I think I was wrong about ActionBar.Menu.IconButton. If ActionBar.Menu is part of the public API, then ActionBar.Menu.IconButton should be the better choice.
Do you mind also including Pagination and SelectPanel in this PR? I think those are the most opaque components, once we go through them, all the rest will be straightforward.
| <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?
There was a problem hiding this comment.
does that mean we should always have data-component for wrappers?
EDIT: no, quoting ADR: "Elements that are purely for layout and have no semantic meaning (spacers,
wrappers that exist only for CSS grid/flex layout) do not require this
attribute."
therefor also no
For this case, should we do: data-component="GroupHeading.Wrapper" and data-component="GroupHeading"?
|
🤖 Lint issues have been automatically fixed and committed to this PR. |
| - **TextInputwithTokens** | ||
| - **TooltipV2** | ||
|
|
||
| This enables consumers to query and test components using stable selectors like `[data-component="Table.Row"]`. |
There was a problem hiding this comment.
General comment, that's why I'm leaving it on the changelog.
How i understand it, the problem that we're trying to solve with data-component is to expose stable selectors which otherwise would be hidden or tucked away.
Some of these components are top level components that support className and are not composed in an invisible manner inside another component (like selectpanel items), should we still add data-component to them?
There was a problem hiding this comment.
and are not composed in an invisible manner inside another component
I think this is the key here. Which one of these falls into that category? 🤔 The way I see it these all are either:
- parts of bigger components (ex: Button inside SelectPanel, Button inside table, Tooltip inside everywhere), so we want the data-component to be able to drill down:
- Big components with smaller parts (SelectPanel has ActionList, Table has Button, ActionBar has Button...), so we need the top-level data-component to "inherit from":
|
🤖 Lint issues have been automatically fixed and committed to this PR. |
|
🤖 Lint issues have been automatically fixed and committed to this PR. |
|
🤖 Lint issues have been automatically fixed and committed to this PR. |

Towards https://github.com/github/primer/issues/6497
Adds data-component attribute (see ADR) for:
Changelog
New
Rollout strategy
Testing & Reviewing
Merge checklist