-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Canvas] Use data views service #139610
[Canvas] Use data views service #139610
Conversation
Pinging @elastic/kibana-presentation (Team:Presentation) |
getDataViews: async () => { | ||
try { | ||
const dataViews = await startPlugins.data.dataViews.getIdsWithTitle(); | ||
return dataViews.map((view) => view.title); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is the list of data views being used? Title is no longer unique, and generally speaking data views should be referenced by name
in UIs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For BWC, I won't be able to use the data view id
instead of the title
because this value is used directly in the SQL statement generated in this esdocs
datasource function and updates the SQL statement to something like SELECT * FROM kibana_sample_data_flights
. Setting the value to id
instead results in an error because ES doesn't recognize this ID and ES SQL expects an index name here. I can use name
for the label for each of the options, but I'll still need to use title
for the value selected and inserted into the SQL statement.
I'm not sure that uniqueness is a requirement here because if you have two data views with the same title, ES will just return results from both data views right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ouch, thats an awkward mixing of metaphors. This should definitely be resolved but I'm not sure how. Data views should be referenced by name even if their title is used for a query.
Any idea how we might address this? Who owns SQL?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps a short term fix would be adding more info to each item in the list - display the data view name but beneath it show the index pattern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any idea how we might address this? Who owns SQL?
@elastic/es-ql owns ES SQL
Perhaps a short term fix would be adding more info to each item in the list - display the data view name but beneath it show the index pattern.
You mean display both the title
and name
for each data view in the dropdown list? Is there a problem with seeing the name
only in the option list and seeing the title
in the expression/SQL statement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a problem with seeing the name only in the option list and seeing the title in the expression/SQL statement?
Thats your call but I worry that it might confuse some.
e5093bd
to
52635e7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Data view usage looks good to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice service addition, and I looked through the code and things look pretty good. Left some small nits!
Also ran this locally, and was able to select data views as expected. Verified that the expression looks as expected too.
Ran into the router issue, which was super annoying because it happened when I saved the change after changing from demo data to es docs, it kicked me back to the listing page and did that weird loading URL thing.
Anyway, LGTM!
.getServices() | ||
.dataViews.getDefaultDataView() | ||
.then((defaultDataView) => { | ||
console.log('componnentDidMount', defaultDataView); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we remove the console.log
here?
|
||
type ESDataViewSelectProps = Omit<Props, 'indices' | 'loading'>; | ||
|
||
export const ESDataViewSelect: React.FunctionComponent<ESDataViewSelectProps> = (props) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Not necessary for this PR, but I'm wondering if we should standardize the way we define functional components as part of that style guide we wrote. I usually do:
export const ESDataViewSelect = ({ value, onChange }: ESDataViewSelectProps) => {
...
}
Instead of how it's done here. I find that that is more concise and easier to understand, but it isn't explicity labeled as a function component
, the dev has to infer that based on the fact that it returns JSX. Wondering if we should come together to use a standard definition, for all of our code, or if we should just define it in the same way it's defined elsewhere in the plugin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually prefer using the FC type like this:
import { FC } from 'react';
export const ESDataViewSelect: FC<ESDataViewSelectProps> = ({ value, onChange }) => {
...
}
which only adds two characters while also being easy to read/concise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like a good pattern!
|
||
useEffectOnce(() => { | ||
getDataViews().then((newDataViews) => { | ||
console.log({ newDataViews }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: remove console logs - I thought we had some sort of linting rule that highlighted these - but maybe that's not the case in Canvas?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really sure why the precommit check didn't catch this before letting me commit. I don't think it's a canvas specific issue. Maybe something's wrong with my dev environment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not actually sure if the pre-commit checks get run anymore, I think you might have to run them manually now.
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |
## Summary Closes #157101 and #157083. This refactors all Canvas routes to use the versioned router for BWC and makes access for all routes internal only. I also removed the `es_fields` routes because the last usage of that route was removed in #139610. All routes have been changed from `/api/canvas/*` to `/internal/canvas/*`. ### Checklist Delete any items that are not applicable to this PR. - [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] Any UI touched in this PR is usable by keyboard only (learn more about [keyboard accessibility](https://webaim.org/techniques/keyboard/)) - [ ] Any UI touched in this PR does not create any new axe failures (run axe in browser: [FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/), [Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US)) - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This renders correctly on smaller devices using a responsive layout. (You can test this [in your browser](https://www.browserstack.com/guide/responsive-testing-on-local-server)) - [ ] This was checked for [cross-browser compatibility](https://www.elastic.co/support/matrix#matrix_browsers) ### Risk Matrix Delete this section if it is not applicable to this PR. Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release. When forming the risk matrix, consider some of the following examples and how they may potentially impact the change: | Risk | Probability | Severity | Mitigation/Notes | |---------------------------|-------------|----------|-------------------------| | Multiple Spaces—unexpected behavior in non-default Kibana Space. | Low | High | Integration tests will verify that all features are still supported in non-default Kibana Space and when user switches between spaces. | | Multiple nodes—Elasticsearch polling might have race conditions when multiple Kibana nodes are polling for the same tasks. | High | Low | Tasks are idempotent, so executing them multiple times will not result in logical error, but will degrade performance. To test for this case we add plenty of unit tests around this logic and document manual testing procedure. | | Code should gracefully handle cases when feature X or plugin Y are disabled. | Medium | High | Unit tests will verify that any feature flag or plugin combination still results in our service operational. | | [See more potential risk examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) | ### For maintainers - [ ] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
Summary
Related to #91715.
Merges #130320 and #138922.
This uses the data views service instead of the saved object client to retrieve data views. These changes should only affect the
esdocs
andescount
datasources.Checklist
Delete any items that are not applicable to this PR.
Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:
For maintainers