Earlier quoted context omitted.
This is the first time I’ve even seen an emoji in an HN comment. What?! Unicode Character “♥” (U+2665) ♳
How about emoji in a HN submission? https://news.ycombinator.com/item?id=36159443
Hadn’t seen this. Neat!
tRPC – Build and consume typesafe APIs without schemas or code generation
201–210 of 223 posts
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#202Earlier quoted context omitted.
I think there are certain types of boilerplate that used to be truly onerous that are now much less so because of types. If there are 3 different files that need to be updated to add a file, and forgetting one is only going to error at runtime (maybe even only if you're exercising that new field) that's horrible. But 3 files that require updating where the code won't compile until you've added all three is way way le…
> But 3 files that require updating where the code won't compile until you've added all three is way way less of a problem. I think this is only really possible in a relatively small subset of programming languages, even among those with static typing. At a minimum it seems like it would require a type system that didn't allow optional properties (by default) and did distinguish between nullable and non-nullable type…
Optional types can get you for sure. I've been doing this with typescript and it's been alright. Prisma -> my domain model -> ApolloServer
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#203Earlier quoted context omitted.
TypeScript-first schema validation with static type inference
There you go. But schemas for what?
> Schema validation provides assurance that data is strictly similar to a set of patterns, structures, and data types you have provided. It helps identify quality issues earlier in your codebase and prevents errors that arise from incomplete or incorrect data types.
From: https://blog.logrocket.com/schema-validation-typescript-zod/
Most common use case I’ve seen is using schema validation for user input (like forms) so you don’t send junk off to the api, you can validate data at runtime (whereas typescript checks your types statically when compiled).
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#204Earlier quoted context omitted.
This works quite well actually: https://github.com/mikew/transmission-material-ui/blob/maste... https://github.com/mikew/transmission-material-ui/blob/maste...
That's seems to be completely missing validation. Typescript types are at their worst when they are lies, and the actual shape of the data is something completely different.
It's copied and adapted directly from their RPC docs, validation would just be busy work.
https://github.com/transmission/transmission/blob/main/docs/...
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#205Earlier quoted context omitted.
That's seems to be completely missing validation. Typescript types are at their worst when they are lies, and the actual shape of the data is something completely different.
It's copied and adapted directly from their RPC docs, validation would just be busy work. https://github.com/transmission/transmission/blob/main/docs/...
For Transmission, maybe. In general, validation is very much not "busywork".
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#206Earlier quoted context omitted.
It's copied and adapted directly from their RPC docs, validation would just be busy work. https://github.com/transmission/transmission/blob/main/docs/...
For Transmission, maybe. In general, validation is very much not "busywork".
On top of automatically generated types (eg. openapi, graphql), I would say it is.
Seems like you're just inserting yourself and ranting about typescript where it's not really applicable.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#207Earlier quoted context omitted.
For Transmission, maybe. In general, validation is very much not "busywork".
On top of automatically generated types (eg. openapi, graphql), I would say it is. Seems like you're just inserting yourself and ranting about typescript where it's not really applicable.
Lovely attitude, you have a nice day too.
There's others expressing the same concerns, for example https://news.ycombinator.com/item?id=37101393
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#208Earlier quoted context omitted.
I don’t really like Zod at all, it has very finicky and verbose types/generic params and it’s object generic won’t allow you to pass a data type, but instead you must pass zods own schema types as properties which are very messy and unintuitive. Another annoyance is that the type of validation errors varies depending on what kind of schema you’re checking against. This makes it unpredictable to handle errors and ther…
I don't disagree (not that I feel the same level of annoyance, on balance I love Zod for the time it saves me) but what would you recommend as an alternative? The new valibot.dev looks cool but I haven't tried it yet.
Just took a quick glance at the source[0] and the generic type for an object schema is a record of other schemas too, similar to Zod. At least that irk won't be solved by this and for me at least it’t the biggest one because it makes typing a function with generic data that includes a schema that acts upon it unnecessarily difficult.
[0] https://github.com/fabian-hiller/valibot/blob/e6c53c8a4b0033...
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#209Earlier quoted context omitted.
There you go. But schemas for what?
> Schema validation provides assurance that data is strictly similar to a set of patterns, structures, and data types you have provided. It helps identify quality issues earlier in your codebase and prevents errors that arise from incomplete or incorrect data types. From: https://blog.logrocket.com/schema-validation-typescript-zod/ Most common use case I’ve seen is using schema validation for user input (like forms)…
Thanks for the reply! I know what schema validation is, but didn't see what kind of schemas Zod was intended for. In other words, what is it parsing? That post you linked to looks very informative.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#210Earlier quoted context omitted.
On top of automatically generated types (eg. openapi, graphql), I would say it is. Seems like you're just inserting yourself and ranting about typescript where it's not really applicable.
Lovely attitude, you have a nice day too. There's others expressing the same concerns, for example https://news.ycombinator.com/item?id=37101393
What's your solution though?
To me, if the server has updated it's schema and the client has old code, the server responds with an error, the user sees "something went wrong".
And if the validation fails on the client side, the user sees "something went wrong"
And if the client isn't doing validation of what's returned, and an error gets thrown because it tried to access a now missing field, the user sees ... "something went wrong"
Intentionally maintaining multiple versions of an API, or making sure your API changes are backwards compatible (like adding new fields and marking old ones as deprecated), those are solutions but definitely require organizational effort.
All totally expressible via Typescript though!