No useful return type on QueryBus.execute about cqrs

[boenrobot]

I would also imagine that a return type for commands would be equally useful. Has this been considered? Or am I misinterpreting the proper way to implement this pattern?

Strictly speaking, commands are not supposed to return results, but only change state. However, in more prectical terms, a command may return the status from the storage (e.g. a database may return the ID of a newly inserted item, number of updated rows, etc.), so yes, I agree that the command should be extended in the same way.

If the intent of a query is to return a response, it would be useful to have type inference for the expected response.

The type can't be inferred from the query, because it is defined in the query handler, not the query. You are supposed to declare on the same return type as you've declared in the handler. As defined right now, you could theoretically declare erroniously different types between the handler and the bus, and that will build, but will potentially have runtime errors.

There is a pattern I use in my project to avoid this problem, and that is to extend the comman/query interface with an optional mutatable property for the result. The command/query/event handler writes its output there, allowing you to have type safety between the command/query/event and its handler, while still keeping the command/query/event and handler implementations separate. The "cost" is that you require the side effect of mutating the result instead of returning it, i.e. if a handler just returns the result, results may be unexpected, and that must be enforced as a matter of policy in the project. More inconviently though, you have to always check if the result is defined before using it, with or without this policy in place.

I think there is a middle ground between these two, which would require changes in this package though...

The ICommand/IQuery interfaces can be extended to have the optional property for the result (specified as a generic, and defaulting to unknown). Then, after return of the handler, the command/query can be updated, and the returned value can be returned by the bus (which would at that point be able to infer the result based on the command/query). But that would be a potentially breaking change, since all commands/queries in the wild will need to be updated to include a results property and/or rename their existing property to something else, if there's a conflict.

[igolka97]

You can specify an expected query result as a second type argument.

Hello @kamilmysliwiec

It may look strange, but why not to make

execute<T extends QueryBase, THandler extends IQueryHandler>(query: T): Promise<Awaited<ReturnType<THandler['execute']>>>;

at QueryBus Interface?

Since that we could do something like that:

return this.queryBus.execute<SomeQuery, SomeQueryHandler>(new SomeQuery());

[kamilmysliwiec]

When dispatching a query from the QueryBus, the return type of the execute method is IQueryResult. If the intent of a query is to return a response, it would be useful to have type inference for the expected response.

You can specify an expected query result as a second type argument.

I would also imagine that a return type for commands would be equally useful. Has this been considered? Or am I misinterpreting the proper way to implement this pattern?

This has been discussed several times in the past and it's not YET supported. Perhaps, we'll provide such a feature down the road, but there's no bandwidth to focus on that for now.

[shirados90]

This PR #1204 might make it event better 😃