Adding data-test-subject property to interactive components

[katrin-freihofner]

To support our decisions with usage data we often need to identify and track the usage of interactive components. This becomes increasingly important and we want to avoid needing an additional PR to add tracking.

Is adding data-test-subject as a mandatory property to all interactive components an option?

This would mean data acquisition is no longer an afterthought and is supported by the EUI framework.

[cee-chen]

Just a very quick clarification on this - the attribute you are looking for (used widely across both Kibana and EUI) is data-test-subj specifically (note abbreviation), not data-test-subject. I make this distinction because there are multiple test helpers across both EUI & Kibana that target this selector, e.g. getTestSubj.

I also want to clarify that this data attribute is primarily meant for testing purposes. You can certainly use it as an attribute hook for other purposes such as analytics/tracking, but first and foremost it exists for tests (hence the naming).

To clarify even more context about the data-test-subj property, just to make sure we're on the same page:

1. We allow consumers to set a custom data-test-subj on all our components, period, and we test for this internally via requiredProps and snapshot testing.

2. We do not necessarily set our own EUI data-test-subj attributes on all components, although we do set them on some components/sub-components

3. For complex components with multiple wrappers and interactive sub components (e.g. EuiDataGrid), it's very possible we're missing EUI data-test-subjs on all interactive child buttons, etc. Those we are happy to take PRs for if there's no other easy way for you to grab/hook into interactive children.

I'm not 100% sure that answered your question - but in a nutshell, I think my answer would be, all components support you passing your own custom data-test-subj. So even if there isn't a default EUI data-test-subj attached to every component, you should be able to pass, e.g. <EuiButton data-test-subj="startOnboarding" /> and hook into your own attribute to track what you need (and honestly, it's better and more specific that way).

If that doesn't fully answer your q, I think we need more details and information as to what you're trying to accomplish.

[katrin-freihofner]

Hi @cee-chen thanks for your reply. Yes, sorry I meant data-test-subj and you are right - this is meant for testing purposes. Our goal is to have a more or less unique identifier to track clicks in Fullstory, we can do that via any attribute - data-test-subj simply proved to be very handy.

I'm aware of the option to pass a custom data-test-subj, but as this is a manual step, people forget and we need another PR to add it. I was hoping we could make our engineers' lives easier.

[CoenWarmer]

I am writing an ESLint Plugin which checks Eui elements for the existence of a data-test-subj prop, and tries to come up with a suggestion based on the context in which the element is used.

WIP:

Screen.Recording.2023-02-14.at.15.26.35.mov

---

Shape of the suggestion
The suggestion for the value of data-test-subj is of the form: [app][componentName][intent][euiElementName].

For example: when working in a component in the location: x-pack/plugins/observability/public/pages/overview/containers/overview_page/header_actions.tsx, and having the code:

function HeaderActions() {
  return (
    <EuiButton>{i18n.translate('id', { defaultMessage: 'Submit Form' })}</EuiButton>
  )
}

the suggestion becomes: data-test-subj=o11yHeaderActionsSubmitFormButton.

Issue: elastic/kibana#144887

In its current iteration it checks these Eui elements:

  'EuiButton',
  'EuiButtonEmpty',
  'EuiLink',
  'EuiFieldText',
  'EuiFieldSearch',
  'EuiFieldNumber',
  'EuiSelect',
  'EuiRadioGroup',
  'EuiTextArea',
]

For elements that don't take a defaultMessage prop / translation, the suggestion takes the form: [app][componentName][euiElementName]

It is important to note the limitations of this approach:

• the rule is set to warn, not to error. There can be legitimate reasons why an engineer does not want to add a data-test-subj and we don't want to block the CI in any way.
• the suggestion is just that, a suggestion: the engineer can always adjust the value before committing.
• If an element already has a value for data-test-subj the rule will not kick in. So we're nudging engineers to use this format, but we're not prescribing or forcing.

[CoenWarmer]

Update: PR now open: elastic/kibana#151173

[cee-chen]

Hot diggity dog, that's SUPER cool @CoenWarmer!! 👏 👏 👏 I love it!

[CoenWarmer]

Thanks @cee-chen! Appreciated :)

[CoenWarmer]

@cee-chen @katrin-freihofner the Rule was just enabled on all Observability apps!

eslint-data-test-subj.mov

Next up: Security and Enterprise Search!