-
Notifications
You must be signed in to change notification settings - Fork 8.1k
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 comparisonStart and comparisonEnd from API endpoints #127812
Remove comparisonStart and comparisonEnd from API endpoints #127812
Conversation
26f4c25
to
a585624
Compare
Buildkite, test this |
@elasticmachine merge upstream |
682a2c8
to
80f5d27
Compare
I wonder if it makes sense to remove |
@ogupte That's a good point, we've discussed it with @sqren before. In this case we'll need to store the selected option somewhere. I could do it with local state but we'll lose the previously selected option when navigating away e.g.
Created #128146 |
Pinging @elastic/apm-ui (Team:apm) |
@elasticmachine merge upstream |
x-pack/plugins/apm/public/components/app/service_inventory/service_inventory.stories.tsx
Show resolved
Hide resolved
...k/plugins/apm/public/components/app/service_overview/service_overview_errors_table/index.tsx
Show resolved
Hide resolved
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 this is a great change! Makes things simpler. I see that we (probably me) implemented offset as "time difference moving backwards", but I think it should be the other way around, e.g. 1d should be one day in the future, and -1d should be one day into the past. What do you think? I haven't reviewed all of it, would like to wait until we have figured that question out, and the redirects.
rangeTo: rangeTo as string, | ||
}); | ||
|
||
const momentStart = moment(start); |
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.
Instead of getting rangeFrom
/ rangeTo
and calculating the diff I can just map TimeRangeComparisonEnum.DayBefore
to 1d
and TimeRangeComparisonEnum.WeekBefore
to 1w
. Then the value is PeriodBefore
we don't have any other options which means even without redirects we will still get the default value. @dgieselaar WDYT?
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.
sgtm, although I'm not sure how that helps with redirect - if users have bookmarks or whatever it will still include the literal string no? am I missing something?
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.
It would still calculate the right offset because it'll be the default option, but comparisonType=period
will remain in the url. I only mentioned it as it'll simplified the redirect a bit. I'm find to leave it as is if you think it looks ok.
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.
oh I see now I think, I assumed you were talking about changing the value of the enum. You're talking about mapping it here? would that also remove the need to call getSelectOptions
below?
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, it would be removed. It'll be like if (comparisonType === 'day') offset = '1d')
(same for the week). For period we just leave it continue and the time comparison component will calculate the default.
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.
sgtm 👍
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.
Done in de4d405
That could be an improvement, although I don't necessarily think there's a big issue with what we have right now. Do you think that's something we could raise and address in a follow up? |
Sounds good to me, I don't think it's that much of an issue and there's some work involved flipping all the offsets around. No need to make an issue AFAIC either. |
return ( | ||
route.path === '/services' || | ||
route.path === '/traces' || | ||
route.path === '/service-map' || | ||
route.path === '/backends' || | ||
route.path === '/services/{serviceName}' || | ||
route.path === '/service-groups' || | ||
location.pathname === '/' || | ||
location.pathname === '' | ||
); |
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.
Maybe we should extract this into a function, something like isRouteWithTimeRange()? I think we're using it somewhere else too. I'm not a fan (I can say that because I wrote it) but I don't really have a better way of doing this right now.
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.
Good shout, indeed it's being used here as well. I can extract it to a function.
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.
Added in 9337e5d
const momentStart = moment(start); | ||
const momentEnd = moment(end); | ||
|
||
const offset = getSelectOptions({ |
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: perhaps the relevant part should be abstracted out of the getSelectOptions function, calling this here seems kind of odd.
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.
Discussed another option in #127812 (comment)
@@ -41,13 +41,13 @@ export function TimeComparison() { | |||
const { start, end } = useTimeRange({ rangeFrom, rangeTo }); | |||
|
|||
const { | |||
urlParams: { comparisonEnabled, comparisonType }, | |||
urlParams: { comparisonEnabled, offset }, |
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 reason why we're still getting this from useLegacyUrlParams()
?
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.
We've discussed this previously here #126567 (comment). Basically if we get it from apm params it'll be false the first time instead of undefined and we wouldn't know if it was actually in the url or we should query the advanced settings. Will the redirect you've suggested overcome this issue?
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.
Are you referring to comparisonEnabled
or offset
? I was referring to the latter. I'm hoping we can make comparisonEnabled
required and redirect in RedirectWithOffset
when taking the value of the Kibana Advanced Setting into account - would that make sense?
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 was referring to comparisonEnabled
. Removed the call to useLegacyUrlParams
, made comparisonEnabled
required and added redirect in f0c8d72.
if (comparisonEnabled === undefined || offset === undefined) { | ||
urlHelpers.replace(history, { |
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.
do we still need this redirect?
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.
Removed it in f0c8d72 as we now redirect from RedirectWithOffset
6adb314
to
9337e5d
Compare
|
||
if ( | ||
matchesRoute && | ||
('comparisonType' in query || !('comparisonEnabled' in query)) |
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 is a little hard for me to parse, do you mind leaving a comment why we're redirecting in this scenario? (IIRC, we redirect if comparisonType is set, because we no longer support it, and we redirect if comparisonEnabled is not set, because it is now required)
url: location.pathname, | ||
query: { | ||
comparisonEnabled, | ||
offset: dayAndWeekBeforeToOffsetMap[comparisonTypeEnumValue] ?? '', |
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 happens if we set offset to an empty string? is offset optional? (if it is required I don't think we should set it to an empty 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.
Offset is optional, we set it to empty string if comparisonType
is not day
or week
. TimeComparison
component then switches to the default offset for the current time range.
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.
ok, should we maybe remove it then from the query entirely? either way this looks fine to me then.
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.
Updated so we add it to the query only if it's day or week.
} | ||
|
||
export const dayAndWeekBeforeToOffsetMap = { |
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.
maybe a little verbose? just a nit though.
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.
Thanks! I think this cleans up nicely. I left a couple of comments, perhaps the one about offset being an empty string requires a good look, but looks good other than that.
💚 Build SucceededMetrics [docs]Module Count
Async chunks
History
To update your PR or re-run it, just comment with: |
Summary
comparisonStart
andcomparisonEnd
withoffset
in all the API endpointscomparisonType
url param withoffset
so the helper is no longer usedCloses #127307