mirror of
https://github.com/elastic/kibana.git
synced 2025-06-27 18:51:07 -04:00
Your window into the Elastic Stack
010ee2e112
Resolves https://github.com/elastic/kibana/issues/144887 ## Summary This PR adds an ESLint Plugin which checks specific `Eui` elements for the existence of a `data-test-subj` prop. This rule will make having one for these elements required. This rule is currently only enabled for Observability apps (APM, Infra, Observability, Synthetics, Uptime). The plugin is also able to generate a suggestion based on the context in which the element is used. In the IDE this suggestion can be applied by using the autofix capability (see video below). When opening a PR, the CI will automatically apply the suggestion to qualifying Eui elements in the branch. https://user-images.githubusercontent.com/535564/225449622-bbfccb40-fdd2-4f69-9d5a-7d5a97bf62e6.mov ## Why do this? There is an increased push to move towards data driven feature development. In order to facilitate this, we need to have an increased focus on instrumenting user event generating elements in the Kibana codebase. This linting rule is an attempt to nudge Kibana engineers to not forget to add this property when writing frontend code. It also saves a bit of work for engineers by suggesting a value for the `data-test-subj` based on the location of the file in the codebase and any potential default values that might be present in the JSX node tree. Finally, because the suggestion is always of the same form, it can increase the consistency in the values given to these elements. ## 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`. For elements that don't take a `defaultMessage` prop / translation, the suggestion takes the form: `[app][componentName][euiElementName]` ## Which elements are checked by the ESLint rule? In its current iteration the rule checks these Eui elements: * `EuiButton` * `EuiButtonEmpty` * `EuiLink` * `EuiFieldText` * `EuiFieldSearch` * `EuiFieldNumber` * `EuiSelect` * `EuiRadioGroup` * 'EuiTextArea` ## What types of prop setting does this rule support? * `<EuiButton data-test-subj="foo">` (direct prop) * `<EuiButton {...foo}>` (via spreaded object; rule checks for `data-test-subj` key in object) ## What types of function declarations does this rule support? * `function Foo(){}` (Named function) * `const Foo = () => {}` (Arrow function assigned to variable) * `const Foo = memo(() => {})` (Arrow function assigned to variable wrapped in function) * `const Foo = hoc(uponHoc(uponHoc(() => {})))` (Arrow function assigned to variable wrapped in infinite levels of functions) ## Things to note * If an element already has a value for `data-test-subj` the rule will not kick in as any existing instrumentation might depend on the value. * the auto suggestion is just a suggestion: the engineer can always adjust the value for a `data-test-subj` before or after committing. Once a value is present (autofixed or manually set) the rule will not kick in. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Dario Gieselaar <d.gieselaar@gmail.com> Co-authored-by: Katerina Patticha <kate@kpatticha.com> Co-authored-by: Tiago Costa <tiago.costa@elastic.co> |
||
|---|---|---|
| .buildkite | ||
| .ci | ||
| .github | ||
| api_docs | ||
| config | ||
| dev_docs | ||
| docs | ||
| examples | ||
| kbn_pm | ||
| legacy_rfcs | ||
| licenses | ||
| packages | ||
| plugins | ||
| scripts | ||
| src | ||
| test | ||
| typings | ||
| vars | ||
| x-pack | ||
| .backportrc.json | ||
| .bazelignore | ||
| .bazeliskversion | ||
| .bazelrc | ||
| .bazelrc.common | ||
| .bazelversion | ||
| .browserslistrc | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .gitattributes | ||
| .gitignore | ||
| .i18nrc.json | ||
| .node-version | ||
| .npmrc | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc | ||
| .stylelintignore | ||
| .stylelintrc | ||
| .telemetryrc.json | ||
| .yarnrc | ||
| BUILD.bazel | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| FAQ.md | ||
| fleet_packages.json | ||
| github_checks_reporter.json | ||
| Jenkinsfile | ||
| kibana.d.ts | ||
| LICENSE.txt | ||
| nav-kibana-dev.docnav.json | ||
| NOTICE.txt | ||
| package.json | ||
| preinstall_check.js | ||
| README.md | ||
| renovate.json | ||
| RISK_MATRIX.mdx | ||
| SECURITY.md | ||
| STYLEGUIDE.mdx | ||
| tsconfig.base.json | ||
| tsconfig.browser.json | ||
| tsconfig.browser_bazel.json | ||
| tsconfig.json | ||
| TYPESCRIPT.md | ||
| versions.json | ||
| WORKSPACE.bazel | ||
| yarn.lock | ||
Kibana
Kibana is your window into the Elastic Stack. Specifically, it's a browser-based analytics and search dashboard for Elasticsearch.
- Getting Started
- Documentation
- Version Compatibility with Elasticsearch
- Questions? Problems? Suggestions?
Getting Started
If you just want to try Kibana out, check out the Elastic Stack Getting Started Page to give it a whirl.
If you're interested in diving a bit deeper and getting a taste of Kibana's capabilities, head over to the Kibana Getting Started Page.
Using a Kibana Release
If you want to use a Kibana release in production, give it a test run, or just play around:
- Download the latest version on the Kibana Download Page.
- Learn more about Kibana's features and capabilities on the Kibana Product Page.
- We also offer a hosted version of Kibana on our Cloud Service.
Building and Running Kibana, and/or Contributing Code
You might want to build Kibana locally to contribute some code, test out the latest features, or try out an open PR:
- CONTRIBUTING.md will help you get Kibana up and running.
- If you would like to contribute code, please follow our STYLEGUIDE.mdx.
- For all other questions, check out the FAQ.md and wiki.
Documentation
Visit Elastic.co for the full Kibana documentation.
For information about building the documentation, see the README in elastic/docs.
Version Compatibility with Elasticsearch
Ideally, you should be running Elasticsearch and Kibana with matching version numbers. If your Elasticsearch has an older version number or a newer major number than Kibana, then Kibana will fail to run. If Elasticsearch has a newer minor or patch number than Kibana, then the Kibana Server will log a warning.
Note: The version numbers below are only examples, meant to illustrate the relationships between different types of version numbers.
| Situation | Example Kibana version | Example ES version | Outcome |
|---|---|---|---|
| Versions are the same. | 7.15.1 | 7.15.1 | 💚 OK |
| ES patch number is newer. | 7.15.0 | 7.15.1 | ⚠️ Logged warning |
| ES minor number is newer. | 7.14.2 | 7.15.0 | ⚠️ Logged warning |
| ES major number is newer. | 7.15.1 | 8.0.0 | 🚫 Fatal error |
| ES patch number is older. | 7.15.1 | 7.15.0 | ⚠️ Logged warning |
| ES minor number is older. | 7.15.1 | 7.14.2 | 🚫 Fatal error |
| ES major number is older. | 8.0.0 | 7.15.1 | 🚫 Fatal error |
Questions? Problems? Suggestions?
- If you've found a bug or want to request a feature, please create a GitHub Issue. Please check to make sure someone else hasn't already created an issue for the same topic.
- Need help using Kibana? Ask away on our Kibana Discuss Forum and a fellow community member or Elastic engineer will be glad to help you out.