[Alerting] Adds generic UI for the definition of conditions for Action Groups

[gmmorris]

closes #82412

Summary

This PR adds two components to aid in creating a uniform UI for specifying the conditions for Action Groups:

1. AlertConditions: A component that generates a container which renders custom component for each Action Group which has had its conditions specified.
2. AlertConditionsGroup: A component that provides a unified container for the Action Group with its name and a button for resetting its condition.

This can be used by any Alert Type to easily create the UI for adding action groups with whichever UI is specific to their component.

For example, in the Always Firing alert we want the user to specify a threshold which dictates which T-Shirt size the Alert Instance is assigned. When the randomly generated number exceeds the threshold, the Alert Instance is assigned to that action group:

This is achieved in the Always Firing alert type by utilising these components:

kibana/x-pack/examples/alerting_example/public/alert_types/always_firing.tsx

Lines 97 to 128 in 74b779a

	<AlertConditions
	headline={'Set different thresholds for randomly generated T-Shirt sizes'}
	actionGroups={actionGroups.map((actionGroup) =>
	Number.isInteger(thresholds[actionGroup.id as AlwaysFiringActionGroupIds])
	? {
	...actionGroup,
	conditions: thresholds[actionGroup.id as AlwaysFiringActionGroupIds]!,
	}
	: actionGroup
	)}
	onInitializeConditionsFor={(actionGroup) => {
	setAlertParams('thresholds', {
	...thresholds,
	...pick(DEFAULT_THRESHOLDS, actionGroup.id),
	});
	}}
	>
	<AlertConditionsGroup
	onResetConditionsFor={(actionGroup) => {
	setAlertParams('thresholds', omit(thresholds, actionGroup.id));
	}}
	>
	<TShirtSelector
	setTShirtThreshold={(actionGroup) => {
	setAlertParams('thresholds', {
	...thresholds,
	[actionGroup.id]: actionGroup.conditions,
	});
	}}
	/>
	</AlertConditionsGroup>
	</AlertConditions>

This approach ensures the different Alert Types can easily create a uniform UX which is shared throughout the framework, but also leaved enough flexibility to allow Alert Types to provide their own custom labeling and components for specifying the conditions (as required for #83270).

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)
• Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)
• This was checked for cross-browser compatibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[shahzad31]

Seems like Flyout will not open if alertTypeId isn't selected? but i guess that use case will never happen inside uptime, right?

[gmmorris]

Yeah, exactly - we need to fix some buggy race conditions on our end which allow Uptime to accidentally render half a flyout that thinks no type is selected (because alertTypeId is undefined) and half that thinks you have selected one.

Uptime is the only place (that I'm aware of) where this behaviour is relied on... so the idea is to patch it this way until we can address it properly .

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[shahzad31]

Functionality wise it looks good, my only concern is that there is white content screen when flyout opens, first time it's pretty long, on subsequent openings, it still pretty noticeable, this is new behaviour, either we can improve this or we should at-least show the loading.

Though i am not sure, if this behaviour needs to be fixed in this PR, i leave it up to you.

[ymao1]

Looks awesome!

[ymao1]

Typing changes look good! My only nit is the naming of the InitialAlert type since initialAlert is a variable we use in other places (like the AlertEdit component, where the type of initialAlert is actually Alert) but I get the intent so it's not a big deal.

[gmmorris]

Typing changes look good! My only nit is the naming of the InitialAlert type since initialAlert is a variable we use in other places (like the AlertEdit component, where the type of initialAlert is actually Alert) but I get the intent so it's not a big deal.

Yeah, I think we should rename the variable, rather than the type, in this case.
I was thinking that could change when we refactor these components in #83417 as it will require changes in the plugins using the flyouts. I hope that refactoring will break these components down to smaller components that don't rely on state as much and we might be able to correctly rename that to something more "correct".

[mikecote]

Changes LGTM!

[mikecote]

I noticed the addition of isValidAlert check here. Does it mean there's a scenario the save code can get executed while the alert hasErrors (disabled save button) or just for safety?

[gmmorris]

Type wise, yes, but not UX wise.
I added the check to safely infer that this is in fact an Alert and not an InitialAlert.
This is what happens when we fiddle with types and state the way we have... If we break these components down we might be able to improve that.

[mikecote]

Got it, thanks 👍

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 3aceac3

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
triggersActionsUi	275	277	+2

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
triggersActionsUi	1.4MB	1.4MB	+941.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
triggersActionsUi	143.1KB	152.2KB	+9.1KB

History

• 💔 Build #89001 failed 703898f
• 💔 Build #88921 failed 781975e
• 💔 Build #88899 failed 1ec6e70
• 💔 Build #88617 failed 988dc5f
• 💚 Build #88412 succeeded 2985ee2

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[gmmorris]

Decided to remove the needs_docs label on this as it is documented in the Developer Docs and as an end user can't use these components directly (they are used by Alert Type implementors).
It doesn't make sense to add them to user docs.