-
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
[Alerting UI] Replaced AlertsContextProvider with KibanaContextProvider and exposed components in API #84604
[Alerting UI] Replaced AlertsContextProvider with KibanaContextProvider and exposed components in API #84604
Conversation
YulNaumenko
commented
Dec 1, 2020
•
edited
Loading
edited
- Removed AlertsContextProvider
- Exposed AlertAdd and AlertEdit flyouts in triggers_actions_ui plugin start
- Did the proper changes in other plugins to use api instead of components by itself.
…er and exposed components in API
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
Pinging @elastic/uptime (Team:uptime) |
Pinging @elastic/apm-ui (Team:apm) |
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.
Code looks good; Logs and Metrics UIs seem to work as expected
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.
LGTM from 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.
All the changes look great! Stack alerts section all seems to work as expected.
When I look in Metrics, in Metrics Explorer tab and create an alert. There are a few percentage expressions to fill in. When I click on any of the percentages to populate, the flyout closes and reopens.
x-pack/plugins/infra/public/alerting/metric_threshold/components/alert_flyout.tsx
Outdated
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.
Looks good!
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.
LGTM for Stack Monitoring
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.
Changes LGTM! I left a few comments regarding the typing and docs
charts?: ChartsPluginSetup; | ||
data?: DataPublicPluginStart; |
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.
Since these are required plugins for triggers actions ui to work, we will always have a value for them (similar to TriggersAndActionsUiServices
). We should be able to remove the empty or data?.
type checks in other files as well.
charts?: ChartsPluginSetup; | |
data?: DataPublicPluginStart; | |
charts: ChartsPluginSetup; | |
data: DataPublicPluginStart; |
dataFieldsFormats, | ||
metadata: { test: 'some value', fields: ['test'] }, | ||
}} | ||
> | ||
<AlertAdd consumer={'watcher'} addFlyoutVisible={alertFlyoutVisible} |
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.
Since this is the Embed the Create Alert flyout within any Kibana plugin
section of the docs, should we explain how to do it using the plugin start contract?
dataFieldsFormats?: Pick<FieldFormatsRegistry, 'register'>; | ||
} | ||
``` | ||
|
||
|Property|Description| |
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 table below should also be removed?
metadata?: MetaData; | ||
} | ||
``` | ||
|
||
|Property|Description| |
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 table below should also be removed?
getAddAlertFlyout: ( | ||
props: Omit<AlertAddProps, 'actionTypeRegistry' | 'alertTypeRegistry'> | ||
) => ReactElement<AlertAddProps> | null; | ||
getEditAlertFlyout: ( | ||
props: Omit<AlertEditProps, 'actionTypeRegistry' | 'alertTypeRegistry'> | ||
) => ReactElement<AlertEditProps> | null; |
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: it seems these functions don't have a scenario that returns null
.
getAddAlertFlyout: ( | |
props: Omit<AlertAddProps, 'actionTypeRegistry' | 'alertTypeRegistry'> | |
) => ReactElement<AlertAddProps> | null; | |
getEditAlertFlyout: ( | |
props: Omit<AlertEditProps, 'actionTypeRegistry' | 'alertTypeRegistry'> | |
) => ReactElement<AlertEditProps> | null; | |
getAddAlertFlyout: ( | |
props: Omit<AlertAddProps, 'actionTypeRegistry' | 'alertTypeRegistry'> | |
) => ReactElement<AlertAddProps>; | |
getEditAlertFlyout: ( | |
props: Omit<AlertEditProps, 'actionTypeRegistry' | 'alertTypeRegistry'> | |
) => ReactElement<AlertEditProps>; |
charts?: ChartsPluginSetup; | ||
dataFieldsFormats?: FieldFormatsStart; |
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 these will always have a value once the changes in x-pack/plugins/triggers_actions_ui/public/types.ts
is done.
charts?: ChartsPluginSetup; | |
dataFieldsFormats?: FieldFormatsStart; | |
charts: ChartsPluginSetup; | |
dataFieldsFormats: FieldFormatsStart; |
@@ -123,7 +123,7 @@ export const IndexThresholdAlertTypeExpression: React.FunctionComponent< | |||
}); | |||
|
|||
if (index && index.length > 0) { | |||
const currentEsFields = await getFields(http, index); | |||
const currentEsFields = await getFields(http!, index); |
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 wonder if there will be scenarios where http
is undefined now?
if (!data) { | ||
throw new Error('KibanaContext has not been initalized correctly.'); | ||
} |
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 should be able to remove this and some further checks below once the changes in x-pack/plugins/triggers_actions_ui/public/types.ts
are done.
const AddAlertFlyout = useMemo( | ||
() => | ||
alertType && | ||
triggersActionsUi.getAddAlertFlyout({ | ||
consumer: 'apm', | ||
addFlyoutVisible, | ||
setAddFlyoutVisibility, | ||
alertTypeId: alertType, | ||
canChangeTrigger: false, | ||
}), | ||
// eslint-disable-next-line react-hooks/exhaustive-deps | ||
[addFlyoutVisible, alertType] | ||
); | ||
return <>{AddAlertFlyout}</>; |
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 reason why this cannot be a component that the alerting UI exports?
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.
From the code reducing prospective it sounds right to expose it as component, but our decision was to live the details of the flyout usage to the end plugin - as a result it can be without memoizations or with the own dependancies list.
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 the memoization is not needed?
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 ok, but since it's not a component could we make the variable lowercase? Also why are we disabling exhaustive-deps? If there's a good reason for that please add a comment explaining why.
<ApmAppRoot | ||
apmPluginContextValue={apmPluginContextValue} | ||
startDeps={startDeps} | ||
/>, |
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.
Ideally startDeps
is part of the plugin context value, similar to plugins. We've not named the properties here appropriately but we'll change that separately from this PR.
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 right for me, I had the similar thoughts, but decided not to modify your plugin context. Are you OK to have it for this PR as it is currently implemented?
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.
Sure thing.
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.
Geo alerts changes lgtm!
- code review
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.
See my comment on the add flyout component. Other than that everything looks ok. We can follow-up later with the dependency props.
const AddAlertFlyout = useMemo( | ||
() => | ||
alertType && | ||
triggersActionsUi.getAddAlertFlyout({ | ||
consumer: 'apm', | ||
addFlyoutVisible, | ||
setAddFlyoutVisibility, | ||
alertTypeId: alertType, | ||
canChangeTrigger: false, | ||
}), | ||
// eslint-disable-next-line react-hooks/exhaustive-deps | ||
[addFlyoutVisible, alertType] | ||
); | ||
return <>{AddAlertFlyout}</>; |
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 ok, but since it's not a component could we make the variable lowercase? Also why are we disabling exhaustive-deps? If there's a good reason for that please add a comment explaining why.
💚 Build SucceededMetrics [docs]Module Count
Async chunks
Distributable file count
Page load bundle
History
To update your PR or re-run it, just comment with: |
…or-disable-searchable-snapshot-fields * 'master' of github.com:elastic/kibana: (29 commits) HTTP CRUD+ API for Index Patterns (elastic#83576) Don't list packages in devDependencies already listed in dependencies (elastic#85120) Remove unused devDependencies (elastic#85121) [ILM] Reposition form toggles (elastic#85143) [APM] Make sure jest script can be run from anywhere (elastic#85111) Add EuiButtonEmptyTo components (elastic#85213) skip flaky suite (elastic#85216) skip flaky suite (elastic#83775) skip flaky suite (elastic#83774) skip flaky suite (elastic#83773) skip flaky suite (elastic#83793) skip flaky suite (elastic#85215) skip flaky suite (elastic#85217) [Usage Collection] Kibana Overview Page UI Metrics (elastic#81937) [Alerting UI] Replaced AlertsContextProvider with KibanaContextProvider and exposed components in API (elastic#84604) skip flaky suite (elastic#85208) [Security Solutions][Detection Engine] Fixes cypress errors by using latest signals mapping (elastic#84600) Small fixes to Kibana search bar (elastic#85079) Change link text to say Fleet (elastic#85083) [Metrics UI] Refactor Process List API to fetch only top processes (elastic#84716) ... # Conflicts: # x-pack/plugins/index_lifecycle_management/public/application/sections/edit_policy/components/phases/hot_phase/hot_phase.tsx # x-pack/plugins/index_lifecycle_management/public/application/sections/edit_policy/components/phases/shared_fields/searchable_snapshot_field/searchable_snapshot_field.tsx