-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Remove kuery from uiFilters #91932
Remove kuery from uiFilters #91932
Conversation
Pinging @elastic/apm-ui (Team:apm) |
Pinging @elastic/uptime (Team:uptime) |
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.
Such a good change! 👍👍👍 I've got one question: we previously had a type guard around uiFilters, that it was not available on Setup unless the corresponding query parameter/rt is set (similar to SetupTimeRange). Looks like that was removed (not sure why). I think we should put that guard back, because it will help the removal of uiFilters altogether. How do you feel about that? I can push a commit to this branch that puts it back. It would be good to get feedback from whoever removed it as well, there may have been a good reason that I'm not aware of. I think it was @sqren?
@@ -43,7 +49,7 @@ export function getErrorGroupSample({ | |||
{ term: { [ERROR_GROUP_ID]: groupId } }, | |||
...rangeQuery(start, end), | |||
...environmentQuery(environment), | |||
...esFilter, | |||
...searchQuery(kuery), |
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.
what about kqlToQueryDSL 😬 ?
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.
or just kqlToQuery
, or queryFromKql
, you get the idea.
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.
So far these functions are all *thing*Query
: rangeQuery
, environmentQuery
, serviceNodeNameQuery
, etc. How about kqlQuery
?
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.
yeah, works for 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.
(assuming you won't go with kqlQuery
instead of kuery
like Shahzad suggested)
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 just leaving kuery
as the name of the query string parameter, and kqlQuery
as the name of the function that converts the KQL query text into a QueryContainer[]
.
setup, | ||
serviceName, | ||
serviceNodeName, | ||
}: { | ||
environment?: string; | ||
kuery?: string; |
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 these be optional always? Can we avoid it?
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.
Can't think of a case where it wouldn't be optional, since you can always have an empty kuery bar and it's present on most pages.
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.
if it's empty I'd say it's still a string? But making it optional makes it easy to accidentally leave out
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'd like to revisit the "requiredness" of parameters shortly in a future PR. Since useUrlParams
always returns an object with everything optional, it's a bit tricky to make something required, and there are some endpoints where kuery and environment aren't there at all. If we can make some improvements to the client-side routes to have more type information about their query parameters we can make this less error-prone.
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 think we can just make kuery required in the UrlParams type. I can have a look if you want (and also make the uiFilters type change).
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.
Please do, but this PR is already changing 144 files so I don't want to make it too much bigger.
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.
@smith Alright, if you can create the issue I'll take a stab on a follow-up PR, that way you're not blocked by 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.
Quid pro quo 😬
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.
Pleasure doing business 🤝
Object { | ||
"term": Object { | ||
"service.environment": "test", | ||
}, | ||
}, |
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 this intentional?
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.
Yes. esFilter
was a property of setup
but now it's removed. The places where it was used in UX have been replaced with a call to getEsFilter
with the uiFilters.
Object { | ||
"term": Object { | ||
"service.environment": "test", | ||
}, | ||
}, |
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 this intentional?
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.
Yes, see above.
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.
This looks good, though i found another issue, which is possible side effect of this #89647 or maybe it got broken later. But UX app environment filter isn't working, i mean it's not passing environment filter to API's.
@shahzad31 Thanks I'll make sure this gets fixed. Is it working on 7.12 but not master? |
i haven't taken a look at 7.12, but i suspect it's broken there as well. |
In 7.12 we're only removing UI filters from the APM UI. None of the changes to environment or kuery are backported there. Environment switching on UX on dev-edge seems to work fine right now. |
💚 Build Succeeded
Metrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
💔 Backport failed❌ 7.x: Commit could not be cherrypicked due to conflicts To backport manually, check out the target branch and run: |
* Make kuery a standalone query parameter instead of part of uiFilters * Move getEsFilters helper to RUM * Move query utils from "common" to "server" (it uses esKuery from the data plugin, which is exported from server, not common.) * Move uiFiltersRt to RUM routes References elastic#84526. # Conflicts: # x-pack/plugins/apm/public/context/annotations/annotations_context.tsx
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
2 similar comments
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
* Make kuery a standalone query parameter instead of part of uiFilters * Move getEsFilters helper to RUM * Move query utils from "common" to "server" (it uses esKuery from the data plugin, which is exported from server, not common.) * Move uiFiltersRt to RUM routes References #84526. # Conflicts: # x-pack/plugins/apm/public/context/annotations/annotations_context.tsx
kuery
a standalone query parameter instead of part ofuiFilters
getEsFilters
helper to RUMesKuery
from the data plugin, which is exported from server, not common.)uiFiltersRt
to RUM routesReferences #84526.