mirror of
https://github.com/elastic/kibana.git
synced 2025-04-24 17:59:23 -04:00
Your window into the Elastic Stack
6d691854f4
# Backport This will backport the following commits from `main` to `8.x`: - [[React18] Migrate test suites to account for testing library upgrades response-ops (#201141)](https://github.com/elastic/kibana/pull/201141) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Eyo O. Eyo","email":"7893459+eokoneyo@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-11-22T16:43:23Z","message":"[React18] Migrate test suites to account for testing library upgrades response-ops (#201141)\n\nThis PR migrates test suites that use `renderHook` from the library\r\n`@testing-library/react-hooks` to adopt the equivalent and replacement\r\nof `renderHook` from the export that is now available from\r\n`@testing-library/react`. This work is required for the planned\r\nmigration to react18.\r\n\r\n## Context\r\n\r\nIn this PR, usages of `waitForNextUpdate` that previously could have\r\nbeen destructured from `renderHook` are now been replaced with `waitFor`\r\nexported from `@testing-library/react`, furthermore `waitFor`\r\nthat would also have been destructured from the same renderHook result\r\nis now been replaced with `waitFor` from the export of\r\n`@testing-library/react`.\r\n\r\n***Why is `waitFor` a sufficient enough replacement for\r\n`waitForNextUpdate`, and better for testing values subject to async\r\ncomputations?***\r\n\r\nWaitFor will retry the provided callback if an error is returned, till\r\nthe configured timeout elapses. By default the retry interval is `50ms`\r\nwith a timeout value of `1000ms` that\r\neffectively translates to at least 20 retries for assertions placed\r\nwithin waitFor. See\r\nhttps://testing-library.com/docs/dom-testing-library/api-async/#waitfor\r\nfor more information.\r\nThis however means that for person's writing tests, said person has to\r\nbe explicit about expectations that describe the internal state of the\r\nhook being tested.\r\nThis implies checking for instance when a react query hook is being\r\nrendered, there's an assertion that said hook isn't loading anymore.\r\n\r\nIn this PR you'd notice that this pattern has been adopted, with most\r\nexisting assertions following an invocation of `waitForNextUpdate` being\r\nplaced within a `waitFor`\r\ninvocation. In some cases the replacement is simply a `waitFor(() => new\r\nPromise((resolve) => resolve(null)))` (many thanks to @kapral18, for\r\npoint out exactly why this works),\r\nwhere this suffices the assertions that follow aren't placed within a\r\nwaitFor so this PR doesn't get larger than it needs to be.\r\n\r\nIt's also worth pointing out this PR might also contain changes to test\r\nand application code to improve said existing test.\r\n\r\n### What to do next?\r\n1. Review the changes in this PR.\r\n2. If you think the changes are correct, approve the PR.\r\n\r\n## Any questions?\r\nIf you have any questions or need help with this PR, please leave\r\ncomments in this PR.","sha":"3890bde1ab9510adc7b6b8333861d3de51381ef5","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","React@18"],"title":"[React18] Migrate test suites to account for testing library upgrades response-ops","number":201141,"url":"https://github.com/elastic/kibana/pull/201141","mergeCommit":{"message":"[React18] Migrate test suites to account for testing library upgrades response-ops (#201141)\n\nThis PR migrates test suites that use `renderHook` from the library\r\n`@testing-library/react-hooks` to adopt the equivalent and replacement\r\nof `renderHook` from the export that is now available from\r\n`@testing-library/react`. This work is required for the planned\r\nmigration to react18.\r\n\r\n## Context\r\n\r\nIn this PR, usages of `waitForNextUpdate` that previously could have\r\nbeen destructured from `renderHook` are now been replaced with `waitFor`\r\nexported from `@testing-library/react`, furthermore `waitFor`\r\nthat would also have been destructured from the same renderHook result\r\nis now been replaced with `waitFor` from the export of\r\n`@testing-library/react`.\r\n\r\n***Why is `waitFor` a sufficient enough replacement for\r\n`waitForNextUpdate`, and better for testing values subject to async\r\ncomputations?***\r\n\r\nWaitFor will retry the provided callback if an error is returned, till\r\nthe configured timeout elapses. By default the retry interval is `50ms`\r\nwith a timeout value of `1000ms` that\r\neffectively translates to at least 20 retries for assertions placed\r\nwithin waitFor. See\r\nhttps://testing-library.com/docs/dom-testing-library/api-async/#waitfor\r\nfor more information.\r\nThis however means that for person's writing tests, said person has to\r\nbe explicit about expectations that describe the internal state of the\r\nhook being tested.\r\nThis implies checking for instance when a react query hook is being\r\nrendered, there's an assertion that said hook isn't loading anymore.\r\n\r\nIn this PR you'd notice that this pattern has been adopted, with most\r\nexisting assertions following an invocation of `waitForNextUpdate` being\r\nplaced within a `waitFor`\r\ninvocation. In some cases the replacement is simply a `waitFor(() => new\r\nPromise((resolve) => resolve(null)))` (many thanks to @kapral18, for\r\npoint out exactly why this works),\r\nwhere this suffices the assertions that follow aren't placed within a\r\nwaitFor so this PR doesn't get larger than it needs to be.\r\n\r\nIt's also worth pointing out this PR might also contain changes to test\r\nand application code to improve said existing test.\r\n\r\n### What to do next?\r\n1. Review the changes in this PR.\r\n2. If you think the changes are correct, approve the PR.\r\n\r\n## Any questions?\r\nIf you have any questions or need help with this PR, please leave\r\ncomments in this PR.","sha":"3890bde1ab9510adc7b6b8333861d3de51381ef5"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/201141","number":201141,"mergeCommit":{"message":"[React18] Migrate test suites to account for testing library upgrades response-ops (#201141)\n\nThis PR migrates test suites that use `renderHook` from the library\r\n`@testing-library/react-hooks` to adopt the equivalent and replacement\r\nof `renderHook` from the export that is now available from\r\n`@testing-library/react`. This work is required for the planned\r\nmigration to react18.\r\n\r\n## Context\r\n\r\nIn this PR, usages of `waitForNextUpdate` that previously could have\r\nbeen destructured from `renderHook` are now been replaced with `waitFor`\r\nexported from `@testing-library/react`, furthermore `waitFor`\r\nthat would also have been destructured from the same renderHook result\r\nis now been replaced with `waitFor` from the export of\r\n`@testing-library/react`.\r\n\r\n***Why is `waitFor` a sufficient enough replacement for\r\n`waitForNextUpdate`, and better for testing values subject to async\r\ncomputations?***\r\n\r\nWaitFor will retry the provided callback if an error is returned, till\r\nthe configured timeout elapses. By default the retry interval is `50ms`\r\nwith a timeout value of `1000ms` that\r\neffectively translates to at least 20 retries for assertions placed\r\nwithin waitFor. See\r\nhttps://testing-library.com/docs/dom-testing-library/api-async/#waitfor\r\nfor more information.\r\nThis however means that for person's writing tests, said person has to\r\nbe explicit about expectations that describe the internal state of the\r\nhook being tested.\r\nThis implies checking for instance when a react query hook is being\r\nrendered, there's an assertion that said hook isn't loading anymore.\r\n\r\nIn this PR you'd notice that this pattern has been adopted, with most\r\nexisting assertions following an invocation of `waitForNextUpdate` being\r\nplaced within a `waitFor`\r\ninvocation. In some cases the replacement is simply a `waitFor(() => new\r\nPromise((resolve) => resolve(null)))` (many thanks to @kapral18, for\r\npoint out exactly why this works),\r\nwhere this suffices the assertions that follow aren't placed within a\r\nwaitFor so this PR doesn't get larger than it needs to be.\r\n\r\nIt's also worth pointing out this PR might also contain changes to test\r\nand application code to improve said existing test.\r\n\r\n### What to do next?\r\n1. Review the changes in this PR.\r\n2. If you think the changes are correct, approve the PR.\r\n\r\n## Any questions?\r\nIf you have any questions or need help with this PR, please leave\r\ncomments in this PR.","sha":"3890bde1ab9510adc7b6b8333861d3de51381ef5"}}]}] BACKPORT--> Co-authored-by: Eyo O. Eyo <7893459+eokoneyo@users.noreply.github.com> |
||
|---|---|---|
| .buildkite | ||
| .devcontainer | ||
| .github | ||
| api_docs | ||
| config | ||
| dev_docs | ||
| docs | ||
| examples | ||
| kbn_pm | ||
| legacy_rfcs | ||
| licenses | ||
| oas_docs | ||
| packages | ||
| plugins | ||
| scripts | ||
| src | ||
| test | ||
| typings | ||
| 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 | ||
| .puppeteerrc | ||
| .stylelintignore | ||
| .stylelintrc | ||
| .telemetryrc.json | ||
| .yarnrc | ||
| BUILD.bazel | ||
| catalog-info.yaml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| FAQ.md | ||
| fleet_packages.json | ||
| github_checks_reporter.json | ||
| kibana.d.ts | ||
| LICENSE.txt | ||
| NOTICE.txt | ||
| package.json | ||
| preinstall_check.js | ||
| README.md | ||
| renovate.json | ||
| RISK_MATRIX.mdx | ||
| run_fleet_setup_parallel.sh | ||
| SECURITY.md | ||
| sonar-project.properties | ||
| 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.