Add actions for getting resources from resources plugin.

[absoludity]

Description of the change

This PR adds the new required actions (and handling of those actions in the reducer) for interacting with the new resources plugin to get and watch resources.

This allows a single request to the resources plugin to watch many resources. The streaming rpc call uses server-side events rather than web sockets, with the grpc-web client using rxjs observables which makes the implementation quite tidy.

Benefits

This PR doesn't change the AppView yet, so the only benefit is preparation for the next PR where the AppView will be updated to use the new action.

Possible drawbacks

Applicable issues

• Ref Update dashboard to use new k8s resources endpoint of api server #3779

Additional information

[antgamdia]

Thank you!! This is way simpler than the manual webhook+fallback polling mechanism! Really happy to move the complexity to the existing protocols and backend instead of a heavy frontend!

[antgamdia]

So, it is in this request event that we also perform the actual subscription. Other actions (which are not meant to return any msg-subscription thing) split the request and receive actions, but here, given that the concept of requesting resources implies requesting a subscription, maybe makes sense to leave it this way.

[absoludity]

Yeah - it is slightly different to the non-subscription pattern such as the existing getResource, out of necessity, but more similar (and based on) the existing getAndWatchResource function (though it's also slightly different as it is getting/watching a single resource only.

The existing non-subscription/non-websocket functions tend to do:

• dispatch request action that just does book-keeping in the state,
• do the actual http request
• dispatch receive action with the result, updating the state.

I think difference that you are pointing out in this new getResources function, the function itself is not doing the actual grpc request, but relying on the reducer to do more than just book-keeping, as the reducer does the grpc-request to get the subscription and then does the book-keeping with this.

Note that the existing getAndWatchResource similarly does the const socket = ref.watchResource() in the reducer, as part of handling the initial dispatched action (called openWatchResource there). What the existing getAndWatchResource and the new getResources share in common is that there is no book keeping state to handle for the request action until the actual request is performed (as the book keeping is on the socket or subscription respectively).

I did think about reducing the difference by doing the actual request and subscription creation:

const observable = Kube.getResources(pkg, refs, watch);
const subscription = observable.subscribe({...});

in the action, and update the dispatched requestResources action to instead include the subscription, but this means that there is no requestResources dispatched until after the actual request has been performed, which means it may it may be skipped entirely (in the case of an error during the request). The only way I think we could get the same pattern is to dispatch a requestResources action that does nothing with the state, then do the request getting the subscription in the action and dispatch a subscribeResources or similar action to do the book keeping with the resulting subscription?

Let me know what you think.

[antgamdia]

Are we 100% sure that r does have a resourceRef ? If not, we can just dispatch an error instead of forcing the null check? No strong opinion, though, happy as it is.

[absoludity]

Yep, I'll try returning an error so it's handled by the error handler (which dispatches the receiveResourcesError).

[antgamdia]

Nitpick: I'd use the same comment format to ease the search term when we want to find for them.

[absoludity]

Woops, updated.

[antgamdia]

I guess is something missing in the eslintrc.json (perhaps in import/resolver ?) not sure, I'd have to check

[absoludity]

So finally found the right incantation here, from https://stackoverflow.com/a/55280867 . It looks like it was because rxjs is itself written in typescript directly, but node was (?) only looking for js files in node_modules.