[Stack Monitoring] Fix date picker range options #121295
Conversation
Kerry350
added
Feature:Stack Monitoring
release_note:fix
Team:Infra Monitoring UI - DEPRECATED
|
Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI) |
| import { useAlertsModal } from '../application/hooks/use_alerts_modal'; | ||
|
|
||
| export const AlertsDropdown: React.FC<{}> = () => { | ||
| const alertsEnableModalProvider = useAlertsModal(); | ||
| const { navigateToApp } = | ||
| useKibana<MonitoringStartPluginDependencies['core']>().services.application; | ||
| const { navigateToApp } = useKibana<MonitoringStartServices>().services.application; |
| const commonlyUsedRanges = useMemo( | ||
| () => | ||
| timePickerQuickRanges.map(({ from, to, display }) => ({ | ||
| start: from, | ||
| end: to, | ||
| label: display, | ||
| })), | ||
| [timePickerQuickRanges] | ||
| ); |
There was a problem hiding this comment.
If TIMEPICKER_QUICK_RANGES don't change during the lifecycle of the app, they could be hoisted at module scope outside of the component... but they depend on a useKibana hook which must live inside of a component 🤷♂️
There was a problem hiding this comment.
Yep, it's a fair point. I used this chunk of code as-is from other solutions. This code (verbatim) exists in quite a few places now. We should really extract it (most likely to the kibana_react helpers) but that would be way out of scope for this bug fix. I can file an issue for later though (which wouldn't just affect Observability).
For now I'll leave it, as I think having the parity with the other locations is less jarring overall.
|
@elasticmachine merge upstream |
|
@claudiopro Thank you for the review. I'll merge once we're green, there was a random and unrelated test failure. |
💚 Build Succeeded
Metrics [docs]Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: cc @Kerry350 |
* Pass commonly used ranges to EuiSuperDatePicker * Tidy up start contract types
* Pass commonly used ranges to EuiSuperDatePicker * Tidy up start contract types (cherry picked from commit dcd6da7)
* Pass commonly used ranges to EuiSuperDatePicker * Tidy up start contract types (cherry picked from commit dcd6da7) # Conflicts: # x-pack/plugins/monitoring/public/plugin.ts
Summary
Fixes #120999
commonlyUsedRangesare passed to theEuiSuperDatePicker(and these are read from the Kibana settings)startcontractType changes
I made some minor changes to the types that relate to the
start(plugins, core etc) contract as I noticed these were incorrect.https://github.com/elastic/kibana/blob/main/x-pack/plugins/monitoring/public/types.ts#L19 suggests currently that properties such as
isCloud,core,elementetc exist on the plugins passed as part ofstart(whereas these will actually just be the defined plugin dependencies).That type is constructed for the legacy version of the app here: https://github.com/elastic/kibana/blob/main/x-pack/plugins/monitoring/public/plugin.ts#L97
I've therefore made a legacy type, and a standard type. I've also added a
StartServicestype that is for use withuseKibanaand accurately reflects the spreading ofcoreandplugins. It might be worth adding aKibanaContextwrapper for Stack Monitoring to wrap up some of this, e.g.: https://github.com/elastic/kibana/blob/main/x-pack/plugins/infra/public/hooks/use_kibana.ts#L18 (there are a lot of individualuseKibanacalls currently).(I'm still getting up to speed with SM code, so please let me know if there are reasons for this that aren't "got missed in refactors")