Closed gustavoguichard closed 2 months ago
This PR introducing the tagging of composables at both type and runtime levels: fn.kind = 'composable'
fn.kind = 'composable'
This allows us to achieve: Composable<Composable<() => void>> === Composable<() => void>.
Composable<Composable<() => void>> === Composable<() => void>
And by doing so we are now able to accept plain functions in any combinator, like so:
const add = (a: number, b: number) => a + b // Before this PR: const fn = collect({ add: composable(add), toString: map(composable(add), String) }) // With this PR: const fn = collect({ add, toString: map(add, String) })
There are still 2 todos to my goal:
branch
applySchema
withSchema
I think this PR as is can be merged and the remaining tasks can come later as new features.
This PR introducing the tagging of composables at both type and runtime levels:
fn.kind = 'composable'
This allows us to achieve:
Composable<Composable<() => void>> === Composable<() => void>
.And by doing so we are now able to accept plain functions in any combinator, like so:
There are still 2 todos to my goal:
branch
resolver function be able to return plain functions instead of only composables or nullapplySchema
work with plain functions and then we can deprecatewithSchema
because they will be virtually the sameI think this PR as is can be merged and the remaining tasks can come later as new features.