[APM] Ensure refresh button works#112652
Conversation
| return ( | ||
| route.path === '/services' || | ||
| route.path === '/traces' || | ||
| route.path === '/service-map' || | ||
| route.path === '/backends' || | ||
| route.path === '/services/{serviceName}' || | ||
| location.pathname === '/' || | ||
| location.pathname === '' | ||
| ); |
There was a problem hiding this comment.
This isn't great. Ideally this would be a property of the route, as the route itself is disconnected from setting the default parameters. I've considered some alternatives, but they come at a cost. One issue is that the date range defaults are (AFAIK) only available via a hook, so we have to render a React element to get the appropriate defaults. We can't easily use a middleware layer for that reason (e.g. onRouteActivate). One option would be to allow the route to specify a pre element that gets rendered as an immediate child of RouterProvider, before any other elements, that can block rendering of child routes. That's a little bit of a weird API though, and I think we should wait for more use cases before implementing it.
|
Pinging @elastic/apm-ui (Team:apm) |
|
Pinging @elastic/uptime (Team:uptime) |
|
@elasticmachine merge upstream |
| const refreshPaused = refreshPausedFromUrl | ||
| ? toBoolean(refreshPausedFromUrl) | ||
| : undefined; |
There was a problem hiding this comment.
do you really need this check? you're adding a default value to refreshPausedFromUrl o line 44, so it'll never be undefined, right?
| const refreshInterval = refreshIntervalFromUrl | ||
| ? toNumber(refreshIntervalFromUrl) | ||
| : undefined; |
| refreshPaused={refreshPaused} | ||
| refreshInterval={refreshInterval} | ||
| onTimeRangeRefresh={() => { | ||
| incrementTimeRangeId(); |
There was a problem hiding this comment.
Is it really the responsibility of who calls DatePicker to call incrementTimeRangeId? I would expect that the DatePicker component to handle it automatically.
There was a problem hiding this comment.
The DatePicker component itself is being used by the UX app as well, and they're using urlParams still. So we have APMDatePicker and RUMDatePicker that each deal with date picker state differently.
| import { TimePickerTimeDefaults } from '../components/shared/DatePicker/typings'; | ||
| import { useApmPluginContext } from '../context/apm_plugin/use_apm_plugin_context'; | ||
|
|
||
| export function useDateRangeRedirect() { |
There was a problem hiding this comment.
We already have a hook that handles time range useTimeRange do you think we could centralize this change in one single hook? does it make sense?
There was a problem hiding this comment.
They serve different purposes, useTimeRange gets the (parsed) range parameters from the url and expects the apm client router to be used, this one checks whether the date range is set in the URL, and can be used by both the APM app and the UX app.
There was a problem hiding this comment.
Why is it necessary for the date range to be set in the url - as @cauemarcondes says, can't we just get the date from useTimeRange?
There was a problem hiding this comment.
discussed with @sqren in AON, we agreed this is ok for now but we will look into whether we can make these query parameters optional and use the kibana date store as the single source of truth.
| import { useApmRouter } from '../../../hooks/use_apm_router'; | ||
| import { useDateRangeRedirect } from '../../../hooks/use_date_range_redirect'; | ||
|
|
||
| export function RedirectWithDefaultDateRange({ |
There was a problem hiding this comment.
Can you add a description to this. The purpose of this function was not clear to me until I read the PR description.
Perhaps some like:
// intercept invalid routes before they are rendered, and redirect, without rendering child components that expect valid & parsed routing parametersThere was a problem hiding this comment.
I'm also wondering what an "invalid route" is in this context. Are we specifically referring to routes that require date range and don't have it? And isn't this something io-ts can handle for us?
| onRefresh={() => { | ||
| onRefreshTimeRange(); | ||
| }} |
There was a problem hiding this comment.
tiny nit (just to keep in consistent with the other handlers)
| onRefresh={() => { | |
| onRefreshTimeRange(); | |
| }} | |
| onRefresh={onRefreshTimeRange} |
💚 Build SucceededMetrics [docs]Module Count
Async chunks
History
To update your PR or re-run it, just comment with: |
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
Closes #110465.
After some routing changes, the refresh button no longer works, due to the
DatePickercomponent and useFetcher using different ways to invalidate the current time range. This PR addresses that issue by:URLParamsContextuseDateRangeRedirectwhich returns aredirectfunction and aisDateRangeSetpropertyincrementTimeRangeIdfrom theuseTimeRangeIdhook, which is also used byuseFetcherto refresh datarefreshTimeRangefromuseUxUrlParams, anduseDateRangeRedirectRedirectWithDefaultDateRangecomponent, which uses a newly implementedgetRoutesToMatchfunction, that returns the routes that are expected to match, without validating the query parameters. This enables us to intercept invalid routes before they are rendered, and redirect, without rendering child components that expect valid & parsed routing parameters