Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript please give us reflection/runtime types

github.com

Post reply on HN
Print view View original

221–230 of 287 posts

Re: TypeScript please give us reflection/runtime types

#221

Post by vbezhenar »

orthecreedence wrote: post #95

Reflection on a language that compiles to javascript? I don't get it. Why are people so allergic to macros?? Every stinking language that has compiled to JS has had a chance to do macros but they don't. Coming from many years spent in the lisp world, metaprogramming is this incredible feature that, in my experience, completely negates the need for runtime reflection while adding many other possibilities as well. I ge…

What're you talking about? JS has had macros since the dawn of this world. Just eval(anything). For example eval(tsc("function f(x: number): number { return x + 1}")). Easy!

Re: TypeScript please give us reflection/runtime types

#222

Post by mirekrusin »

DanRosenwasser wrote: post #120

Hey all, TypeScript PM here. I understand the desire here. Runtime type checking is often necessary for data validation, and we can see lots of libraries developed to help fill the gap here. But I think the fact that there are so many libraries with different design decisions is pretty indicative that this is not a solved problem with an obvious solution. We knew this going into the early design of TypeScript, and it…

Microsoft hosted MacroScript as TypeScript plugin or toplevel wrapper would solve this problem.

You just need to spark it, community will help maintaining it.

It would solve all codegen needs from generating clients to runtime type assertions and many interesting problems in between.

Re: TypeScript please give us reflection/runtime types

#223

Post by steve_adams_86 »

JohnDotAwesome wrote: post #39

Instead of pleading to the TypeScript gods, why not make a deal with the JavaScript deities? Let's get type-checking into JS! If I want runtime types, I reach for type guards. If I need to do this a lot, then I reach for io-ts or zod and pretty much exclusively write types as validators/codecs/schemas or what-have-you. I don't think TS - as a specification, type-checker, community, or otherwise - needs to concern its…

I know it’s not perfect, but I’m pretty content writing schemas and types as validators with zod and deriving my types from those. That you can derive the types easily and the validation then evolves with your typing is really nice.

I’ve worked with people who find it too complicated or they feel like it should be baked into the language, but I’d argue there are so many contentious design choices in these libraries that it might actually be best to be an implementation choice, selected based on a project and its specific needs.

Zod has been very good to me though. It’s quite easy to get up and running with, and its API has never gotten in my way when scaling things out.

My one complaint is that certain patterns I love, such as runtime validation with zod and deriving types from schemas, doesn’t necessarily always play well with something like pattern matching in ts-pattern. The type definitions behind these libraries are labyrinths, and cases where something seems like it should work won’t always behave as expected. On some level, I do wish these were seamless language level features, though I fully recognize these are selfish desires.

But imagine having runtime safety combined with exhaustive pattern matching. I’d be very happy to have that.

Re: TypeScript please give us reflection/runtime types

#225

Post by lf-non »

epolanski wrote: post #54
frou_dh wrote: post #40

I was perfectly satisfied with using https://zod.dev for some runtime data validation, and found it really cool that I didn't have to define some nominal type off to the side and could instead just say what I meant inline using a fluent API.

Nominal types have different use cases. Simple one, distinguishing `2` number with `2` currency in your domain.

We can use branded types to simulate nominal typing

https://zod.dev/?id=brand

Re: TypeScript please give us reflection/runtime types

#227

Post by afiori »

nonethewiser wrote: post #211
RyanCavanaugh wrote: post #131

Earlier quoted context omitted.

Not to be flip, but if it were really all this easy, we would have done it already. There are dozens of questions you can throw at this code: What if the input's a union? What if it's a nested union -- how do you avoid combinatorial explosion? What if the input is a function -- how do you validate its parameter types using runtime information? What if the input is a conditional type? What if you're inside a generic f…

> Not to be flip, but if it were really all this easy, we would have done it already. Typescript is mature. There is no low hanging fruit to be develop. I don't necessarily think it needs this but this is hardly the right grounds to dismiss it.

I do not think that they mean that all easy things have been done, rather that if this feature was easy then it would already exist

Re: TypeScript please give us reflection/runtime types

#230

Post by lf-non »

rizky05 wrote: post #214
ncallaway wrote: post #205

Earlier quoted context omitted.

> And we already have runtime validation libraries to cover that validation step. Right, but now my type information for inbound data must be in two places: the typescript type, and the validation schema. And heaven forbid I make a mistake and those two become out of sync. Yes, I can use something like zod to define a schema then infer the type from it, but those inferred types are often … suboptimal to work with.

Zod is great, why do you think it is suboptimal ?

I love zod and use it daily.

It is also the most frequent thing where junior developers get stuck. TS tooling doesn't make it very easy to work with large extracted types though it is head and shoulders above other mainstream languages. The error messages often become incomprehensible walls of text once your types are Complex enough, and then tsserver will just truncate the type info in pop overs making them useless.

I am personally OK to live with all of the above. My single issue with zod is that it is not easy to use if you don't own your types. If your types are coming from a third party lib you don't have an easy path to derive runtypes from them. If the concept of runtypes was supported by the compiler itself, this could have been possible but as a userland library zod can't handle this easily.

Post reply on HN