frontend: Add a way for plugins to react to Headlamp events

[joaquimrocha]

Plugins may be interested in reacting to when e.g. all plugins are
loaded, in order to show a notification or perform some different
action. These changes allows plugins to do that by registering
callbacks that are run when some events in the app happen.

fixes #1451

[illume]

@ashu8912 walked me through the PR.

Nice.

• Should plugins be able to dispatch events too? Has this been considered. Is the dispatchEvent API exposed?
• Probably needs an example plugin for documentation and testing reasons.
• He queried the resource list event. I was also wondering about the name. Should it match the component name?

[illume]

Left a couple of notes for your consideration.

[illume]

Hi. There were some notes and questions that were missed because they were obscured with the other comment below. I'll repeat them here.

• Should plugins be able to dispatch events too? Has this been considered. Is the dispatchEvent API exposed?
• Probably needs an example plugin for documentation and testing reasons.
• Ashu queried the resource list event. I was also wondering about the name. Should it match the component name?

I have some other feedback, but I'm not sure of the entire context or requirements. So I'm not clear if all of this applies.

• Is there an issue for this somewhere? It would be good to link it to get more context and to see if it solves the problems there.

• I like that there is only one exposed API for registration.

• The API doesn't use the type checker for the data given to the callback. It would be better for it to have types (see below for an option)

• It would be good to consider the number of files that need to be edited for this to add a new one. But I think it's pretty good. Maybe a little comment block inside of eventCallbackSlice explaining how to add one would be helpful.

On redux...

• I like how it's possible to see these events in the store now. It will help with observability/debugging too inside the dev tools.
• How does this compare to the plugins using the redux state? It seems a hook (typedselector) won't work for these types of events.
• The events won't happen at the callsite, but will go through the redux store. I'm not sure if this matter for the requirements. But the implication of this is that folks won't be able to run code within the context of where the event is sent. Maybe this is a good thing. But I would like to know if you considered this.

names

• Probably the dispatchHeadlampEvent could live inside the eventCallbackSlice rather than util.
• I feel dispatchEvent is better because it's still a unique name within the headlamp codebase. On hover inside vscode it's easy enough to see where it's from, and also by looking at the import.

add types to data

interface ErrorBoundaryEvent {
  type: HeadlampEventType.ERROR_BOUNDARY;
  data?: { error: string };
}

interface DeleteResourceEvent {
  type: HeadlampEventType.DELETE_RESOURCE;
  data?: { resourceId: string };
}

type HeadlampEvent =
  | ErrorBoundaryEvent
  | DeleteResourceEvent
  | /* others */;

[joaquimrocha]

I updated the PR with a more complex, single commit, but I think it makes sense as it now makes things more structured, type checked, and easier to use. Also added an example plugin but that's still WIP as I haven't finished adding the details in the README, etc.

[illume]

Some notes for future selves... I remember we spoke verbally, but I wanted to have it written down somewhere.

• How would plugins who want to send events be able to do that? So plugin A can listen to an event from plugin B. There's no user requirement for this yet. However, I could see it possible to extend this to make an API for plugin authors in the future. Under it all it's just a { type, data }, and all the types in here are prefixed with "headlamp.". So a future plugin sending event API would just need to expose that.
• Having functionality for different modules all in one file was a bit concerning. However, it's not such a great concern because there's not much cyclical importing of things going on. It only imports three internal things so far. But it does mean if there are 10x more things added that file will get quite crowded. I can roughly see a refactoring that might make this worthwhile to do when we get up to 10x more events, so I feel we do that then not now... if required. This current way seems more convenient, and better now.
• For "The events won't happen at the callsite, but will go through the redux store. " there doesn't appear to be a use case for this. If there is later, I could see there being something like a 'sync' attribute added so the callbacks are called at the callsite.

[illume]

Very very Nice.

I left a few comments, now I'm testing it locally.

[joaquimrocha]

Thanks for the review @illume . I have updated the branch after your suggestions.

[illume]

Great job! Thanks.