Add Fluent methods on `IResourceBuilder<T>` for subscribing to resource events

[afscrome]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

When subscribing to events on a resource, you have to break out of the fluent builder pattern

var foo = builder.AddContainer(…);

builder.Eventing.Subscribe<BeforeResourceStartedEvent>(foo, (evt, ct) => { /*...*/ } );

return foo;

Describe the solution you'd like

It would be nice if we could have a fluent method to subscribe to resource events

return builder.AddContainer(…)
   .Subscribe<BeforeResourceStartedEvent>((evt, ct) => { /*...*/ } );

Additional context

No response

[DamianEdwards]

You won't believe this, but I was literally thinking of this while falling asleep last night 😄

I was thinking we'd have actual methods to help with discovery though, e.g.:

return builder.AddContainer(…)
   .OnBeforeResourceStarted((evt, ct) => { /*...*/ } );

[afscrome]

Done a bit of experimentation on this (see #10097). First attempt was to reuse the callback argument as is from the main IDistributedApplicationEventing.Subscribe

public static IResourceBuilder<T> OnInitializeResource<T>(this IResourceBuilder<T> builder, Func<InitializeResourceEvent, CancellationToken, Task> callback)
        where T : IResource
{
        builder.ApplicationBuilder.Eventing.Subscribe(builder.Resource, callback);
        return builder;
}

This mostly works, but hits some quirks when you want to access the resource in question inside the event. Whilst IResourceEvent contains a Resource property, it's typed as IResource rather than the concrete type you want. This is not a problem if you already have a local for the resource that you can reference. But that is not always going to be the case - particularly if either

1. You are using a resources provided by another package
2. You are defining the resource inline in the AddResource(), and not storing it as a local variable

builder.AddResource(new MyResource()
   .OnResourceInitalized((evt, ct) => { 
      // evt.Resource does exist, but it's `IResource`, rather than your specific resource type
      // which leads to some awkward casting.
      var resource = (MyResource)evt.Resource;
   });

So I'm now leaning toward including the typed resource as one of the callback arguments to this method.

- public static IResourceBuilder<T> OnInitializeResource<T>(this IResourceBuilder<T> builder, Func<InitializeResourceEvent, CancellationToken, Task> callback)
+ public static IResourceBuilder<T> OnInitializeResource<T>(this IResourceBuilder<T> builder, Func<T, InitializeResourceEvent, CancellationToken, Task> callback) 

Thoughts on this API shape?