Is there a way to perform schema parsing generically?
My reasoning is to integrate Arktype with https://effect.website/
This most simple example fails:
This fails as the return type of
.assert
is finalizeDistillation<T, _distill<T, { endpoint: "out"; }>>
Is there a way to coerce this back to a T
? Or is there some constraint I need to put on the T
input to make this work?Effect – The best way to build robust apps in TypeScript
Effect is a powerful TypeScript library designed to help developers easily create complex, synchronous, and asynchronous programs.
14 Replies
The parameter of a type can include morphs and constraints, so the inferred return type is correct there- you wouldn't want to return
T
my reasoning is to create a function which can be used in an effect chain, i.e. something like this:
ah, hm
so here's my problem: how do I get access to the
finalizeDistillation
type from the outside?There are a few options. You could use
type.infer.Out<T>
I could do this but it seems hacky:
aha, that's exactly what I need. thanks!
ah hm, no, it's not
There are a lot of limitations in TS around inferring generic return types without casting even if the types are trivially identical
There may be a way we can get it to infer without casting by making the constraint a
Type
instead of the param though
(if you cast there it would work because in reality those two types are equivalent)
Hmm well I guess actually if it's not the type instance you're passing they may not be hold onI'm sorry, I don't understand what you mean. Forget all the effect stuff - my very simple case is this:
if I can figure out what belongs as the return type of this function, that's the whole problem sorted
Would this work
If you want to accept a type definition instead of an instantiated type in your API to remove a layer of indirection, there's also a way to do that
yes - that solves it, thank you!
I am curious as to why
Out<T>
didn't do that - but no worries
it does look like it shouldBecause it I made a mistake, it expects a definition or a type instance but we passed it the inner type param
This would be another option:
Although best not to create a new type for each parse call so you'd want to curry or cache it
That way you could pass
{foo: "string"}
or whatever directly instead of having to wrap everything in Type
(although it also works if you wrap it in Type
since types are valid definitions)ah, well, I have types already I would reuse, so passing a Type in is the way to go 🙂
Sorry, just added
.validate
you'd need that to get autocomplete
Cool, definitely hope this works out! I talk to Effect folks somewhat often so I'm sure they'd be interested hahaha, it works! this is excellent