What pattern do you expect for setting handlers?

[brickscrap]

Apologies for this vague question, but as the documentation isn't finished I can't find a clear answer to know if I'm doing this "right".

I've created a class for each of my handlers, as my app has a lot of options, and I've made each of the handlers an ICommandHandler, then creating my commands as such:

var anOption = new Option<string>(new[] { "--option", "-o" }, "Description");

        Command cmd = new("sub-command", "Sub command description")
        {
            anOption
        };

        var binder = new SubCommandBinder(anOption);

        cmd.SetHandler((SubCommandOptions options, InvocationContext ctx, CancellationToken ct) =>
        {
            var handler = new SubCommandHandler(options, ct);
            return handler.InvokeAsync(ctx);
        }, binder);

        return cmd;

And the binder is just defined as in the beta 2 announcement. Is this the way you expect people to invoke the commands? How would I go about using dependency injection in this approach? The beta 2 announcement shows creating a MyCustomBinder as an example, but I'm not really sure I understand this approach - is it expected that dependencies will be handled by the binder, or to use the InvocationContext within the InvokeAsync method?

At the moment I'm injecting an IHost into the class where I create my RootCommand, then just passing that into my handler constructors, and this appears to work - is this your intention?

[jonsequitur]

That approach sounds very reasonable.

The primary use case for the custom binder is to be able to map multiple argument and option values into a single object like your SubCommandOptions, which can help clean up your code but also prevent the 16-parameter Func<...> on SetHandler from being a limit to the number of arguments and options for your CLI.

Using the binder to pull other dependencies (including from a DI container / service provider) is an additional use case. We're trying to keep it flexible and not couple to specific DI interfaces because we've seen the needs for DI here vary quite widely.

Is the pattern working well for you? Any pain points? Improvements you would suggest?

[brickscrap]

Thanks for the reply Jon. I think the newer approach is definitely an improvement from the older - whilst it does seem like there's more boilerplate required, the code certainly appears cleaner, at least in my eyes.

I wish I was able to suggest improvements, but I'm still relatively new to coding in general so wouldn't know where to start! However, thank you for your work on this package, it's been a godsend