Events are going to be key to the library. For things like API interactions, or library events (i.e. a command failed).
How should they look? A general idea I had was again to make them generic (type safety, yay!)
[Event("CommandFailed")] // we could probably also extract the name from the class name, i.e. CommandFailedEvent without 'Event' would be the same, CommandFailed. It's nice to have options, though.
public class CommandFailedEvent : IEventHandler<CommandFailedInfo>
{
private ILogger _logger;
public ValueTask RunAsync(CommandFailedInfo info)
{
_logger.LogError($"Command with name {info.Command.Name} failed due to {info.FailureReason}");
return ValueTask.CompletedTask;
}
}
this is nice because then it can be used based on type, or type + name, i.e.
client.RaiseEvent<CommandFailedInfo>(new CommandFailedInfo()); // raise all events that have this generic argument
client.RaiseEvent<CommandFailedInfo>("CommandFailed", new CommandFailedInfo());
we'd likely use source generators again to generate an event handler - to avoid lookup and boxing.
Events are going to be key to the library. For things like API interactions, or library events (i.e. a command failed).
How should they look? A general idea I had was again to make them generic (type safety, yay!)
this is nice because then it can be used based on type, or type + name, i.e.
we'd likely use source generators again to generate an event handler - to avoid lookup and boxing.