Closed gustavoguichard closed 1 year ago
We decided to keep the current implementation and add an optional generic to allow the user to overwrite the Result<unknown>
.
In case you want to do that just pass the generic to trace as:
const logErrors = trace<DomainFunction<number>>(
({ input, result, output }) => console.log({ input, result, output })
// ?^ Result<number>
)
Purpose
When doing type-level testing (#58) I realized the newly introduced.
trace
function kills the type inference of the composition applied to it. Any DF given to trace will be inferred as DomainFunctionThat was introduced in favor of typing the result of the trace callback which kind of defeats the purpose bc neither are being properly inferred unless you give trace a manual type argument.
We might be able to keep both inferences with some TS contortionism which I could not take off the 🎩.
The problem actually seems impossible on the first look, it lies on the API decision:
It seems to be an underlying issue with the chosen order of parameters with the curried API.
Possible solutions for the current API
What could be done without breaking the API is to manually set the type param:
Or even
New API proposals
IMO I'd go this route.
We could have both inferences if we changed the
trace
API to something like:What do you think? We could bump the minor to 1.6 and deprecate the 1.5 package maybe.