What's your use case for wanting zod instead of https://telefunc.com/shield#all-types?
What's your use case for wanting zod instead of https://telefunc.com/shield#all-types?
Importantly Zod philosophically follows "parse, don't validate" https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... which means that once validation is done, you get a type - a parsed value. This means you can validate clientside and serverside using the same types. Again, sure you could do the same with Telefunc, but you still need to invoke Abort manually and every single RPC definition you have needs to be followed by Zod.parse. A small cost to be sure, but what are the advantages of Telefunc over tRPC? I'm not seeing any right now.
tRPC also isn't strongly tied to Zod, it also works with yup, superstruct, and custom validators.
I'm more than open to support Zod & co, but I'd like to see a concrete use case for it.
Speaking of boilerplate, one Telefunc feature I'm particularly excited about is its capability to automatically generate runtime type safety, so you don't even need `shield()` nor Zod then. But it's an experimental feature, let's see how it works out at scale.
The main problem with Telefunc right now is the lack of clear documentation which I'm going to work on in the next weeks/months. Hopefully, it will then become clear why Telefunc is simpler and less boilerplate. Stay tuned.
In the meantime feel free to check out the `examples/` and feel free to hit me up on Discord.