Dynamic actions

[streamich]

Summary

Closes #55341
Closes #55333

See action configuration collection component, by running:

yarn storybook ui_actions

Also in this PR:

• Adds ability for actions to return something from execute methods.
• execute method can also be sync now.
• Instead of adding DynamicAction interface next to Action interface keeps everything in one action concept, e.g there is no distinction between regular actions and dynamic actions, basically all actions are dynamic.
• Splits the Action interface into three: (1) ActionDefinition - used to easily register actions; (2) ActionInternal - used internally inside ui_actions plugin; (3) ActionContract - represents action that is returned to other plugins.
• Splits action Context into two: (1) PresentationContext - used to render the action on screen; (2) ExecutionContext - used when action is executed, i.e when execute() method is called.
• Action state now lives in a state container.
• Action may have factoryId field which is used to look up the factory action used to create the action when deserializing it. (BTW, was the type field meant to be used for that? Should I use type field to identify factories instead?)
• Extracts presentation related fields into Presentable interface, this way triggers could implement the same interface interface Trigger extends Presentable, to be used in <TriggerPicker> component.

Checklist

Delete any items that are not applicable to this PR.

• Unit or functional tests were updated or added to match the most common scenarios

For maintainers

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

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[jbudz]

ops codeowner files LGTM

[stacey-gammon]

Is this name field needed/used anywhere?

[streamich]

Yes:

[stacey-gammon]

Where will name be used and where will getDisplayName be used? Name shown in a management table/list and getDisplayName shown when a trigger was emitted that the action is attached to?

[streamich]

Name shown in a management table/list and getDisplayName shown when a trigger was emitted that the action is attached to?

Yes, I think so.

[Dosant]

@elasticmachine merge upstream

[Dosant]

@streamich

After working on UI components it seems to me that it would be better to have this collect config thingy on ActionFactory instead of Action.

Because when we open a dialog for creating / editing a drilldown - user can change the type of action he is creating.

It means, that we either should be able to change action's type on a fly (and all other action definition things which depend on it) or just don't create any action when editing.

So, I think, the way to go is to make that editor component to not have Action as Input and Output, but instead have something like as input and output all needed information to create an action. In our case:
actionFactory actionConfig name
where actionFactory will have

actionFactory.createConfig() // default config
actionFactory.CollectConfig() // specific component for collecting it
actionFactory.isValid(name, config) // is info for creating an action is valid? 

So far I was following this direction in my components prs.
#59032 #59139

[stacey-gammon]

Now that this has been merged to master after my typescript PR, this is a duplicate type, there is a file action_definition with a ActionDefinition type as well. I think we should use that one, and like @Dosant suggested, tie Config shape with the factory which I think should go in x-pack.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 2700d00

History

• 💛 Build #31087 was flaky d056277
• 💚 Build #31024 succeeded 7fbd1fb
• 💚 Build #31004 succeeded d0f67ec
• 💚 Build #29388 succeeded 55b8721
• 💔 Build #29371 failed 3e81792

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