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

231–240 of 287 posts

Re: TypeScript please give us reflection/runtime types

#231

Post by code_biologist »

paxys wrote: post #129
wvenable wrote: post #92

Earlier quoted context omitted.

You don't get JavaScript engines to understand it. You use a library.

So then...exactly how it is done today? TypeScript provides an API to get type info at compile time. Libraries write plugins to consume this type info and use it for runtime and custom validation. What changes in this new world?

> So then...exactly how it is done today? TypeScript provides an API to get type info at compile time.

That's exactly it, it doesn't. That project you linked (typescript-rtti) mentions in the README that you must install and use it via ttypescript, a typescript wrapper that patches the compilation process to expose compilation details to plugins. Except that plugin API is unofficial and changes break the ecosystem built on it. For example, ttypescript doesn't work for TS 5 and the dev doesn't want to spend time on it. ts-patch has stepped in to provide a source transformer API for TS 5.

There's no way I can recommend libraries like typescript-rtti in commercial projects until something changes. I hope the ts-patch folks don't burn out.

Re: TypeScript please give us reflection/runtime types

#232

Post by cjdell »

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 found Zod a lot easier to use once we were given the "satisfies" keyword. I still basically have to write my schema twice (I don't mind this) but I can ensure the two are tightly coupled. A change to either one will show a compile error in the right place:

interface Person { firstName: string; lastName: string; }

const PersonSchema = z.object({ firstName: z.string(), lastName: z.string(), }) satisfies z.Schema;

Re: TypeScript please give us reflection/runtime types

#233

Post by code_biologist »

oorza wrote: post #213
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…

Why don't you just make the transformer API stable, public, and let the community do the hard part? There's plenty of us that have experimental transformers doing all sorts of fun things, these are problems that can be solved external to TS. I've got a fully functional compile-time dependency injection container that I've been sitting on for literal years because the transformer API isn't public.

^^^ Please do this. I'm completely ok with "using transformers voids your nonexistent warranty" and the community can deal with transformer API churn. Exposing the API makes it easier to adopt those community solutions, versus me needing to explain to teammates why I switched all the `tsc` invocations to `ttsc` and promise it's not that sketchy.

Re: TypeScript please give us reflection/runtime types

#234

Post by lf-non »

fzeindl wrote: post #9
andix wrote: post #5

There is a good reason for not doing this. Typescript would become some kind of runtime on top of JavaScript. A new language that compiles to JavaScript. Currently TS is only JavaScript with type annotations. There are many languages that compile to JavaScript. Pick one of them and use it! And I have the feeling, that people who want runtime typed Typescript would rather like to write Java/OOP style code instead of J…

You can use Kotlin and compile to JavaScript. It's type system is better and the standard library greater scnr

Kotlin's type system works great for interop with a nominally typed lang like java but for interop with a dynamically typed lang like js and myriad of its libs not designed with type safety in mind, structural typing is far more convenient.

Re: TypeScript please give us reflection/runtime types

#235

Post by syspec »

Waterluvian wrote: post #7

Above all of what I write below, I think that this is a very valid issue for discussion and debate. I don't think there's one objective correct answer. So this isn't me dictating what TypeScript shalt be. TypeScript is an entirely optional layer on top of JavaScript, with the exception of `Enum` that emits an object, many of which see as a mistake. You don't even have to "transform" TS code to get JS: you just have t…

> You don't even have to "transform" TS code to get JS

Sure if you consider the whole language, typings

Re: TypeScript please give us reflection/runtime types

#236

Post by code_biologist »

decs wrote: post #37
rcme wrote: post #4

There are good typed deserialization libraries. Personally, I prefer runtypes but there are options.

Agree, zod, arktype, and typia are impressively easy to use! Though, I feel that this environment created a different problem of spreading developers into multiple solutions. So for lib devs like me, we end up having to choose between coupling with a single validation lib or managing support for multiple (like tRPC does). To address that, I ended up doing a reusable lightweight lib that wraps that logic for supportin…

Thanks for the lib! I'm always charmed to come across such a concrete example of the fundamental theorem of software engineering: "We can solve any problem by introducing an extra level of indirection."

Re: TypeScript please give us reflection/runtime types

#238

Post by orthecreedence »

benatkin wrote: post #101
orthecreedence wrote: post #83

Earlier quoted context omitted.

> Just kidding, but I'm not pushing for JavaScript anymore. If rust/WASM works as well, I say go with that. This is the direction I'm going. I use rust a LOT these days, and after trying out typescript for a few projects over the course of a few months, I absolutely hate it when comparing it to rust or even any other compiled language. Something about it just rubs me the wrong way...maybe the fact that it has to be J…

I'm curious what you think about Dart/Flutter if you've gotten a chance to dig into them. I am very impressed, but it trades simplicity for being cross platform. It has a nice set of types though. https://dart.dev/language/built-in-types It also has a WASM compilation target that is under early development. https://docs.flutter.dev/platform-integration/web/wasm

Good question! I prototyped some stuff on Dart/Flutter. What I took away from it is that a) I really liked Flutter b) I really do not like Dart. I really tried to like Dart (mainly because I was enthralled by the idea of Flutter) but it just didn't click for me. It seemed like the syntax was trying to be intuitive in some ways, logical in others, and that incongruity really made it hard for me to pick up. I think overall it felt inconsistent in confusing ways. I also was both simulaneously impressed and disgusted by the fact that it render everything in a canvas for desktop...I mean, it totally makes sense, and what a great way to get consistent rendering acros platforms, but I wonder what the tradeoffs are. Accessibility must suffer in some way, but maybe they figured all that out.

I wish Flutter was just a regular GUI library for another language (C maybe, so you can use it from everywhere, that'd be nice). Dart really killed it for me. Also, I know it's beating a dead horse, but Google doesn't have a good track record with long term support of their projects. If it was a grassroots open source project, I'd probably feel a lot more secure putting aside my Dart-inflicted OCD and really picking it up.

Given my current love affair with Rust, my main squeeze right now is Tauri. Once they hit mobile platforms I think it'll be unstoppable, and in the meantime whatever you can do in Tauri you could probably translate to Ionic.

Re: TypeScript please give us reflection/runtime types

#239

Post by solumunus »

ncallaway wrote: post #216
rizky05 wrote: post #214

Earlier quoted context omitted.

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

I like a lot of things about zod (it's what I use when I need to do this kind of validation), but when I was working with a mildly complicated schema the type that z.infer produced wasn't great for me. When I produce a type definition for a nested schema, I'll produce types for individual pieces. So type Schema = { foo: Foo; bar: Bar; baz: Baz[]; } type Foo = { red: Color; white: Color; blue: Color; } type Color = {…

Use objectSchema.shape.xxx to access the nested schemas and infer on those.

Re: TypeScript please give us reflection/runtime types

#240

Post by can16358p »

vbezhenar wrote: post #218
can16358p wrote: post #47

This shouldn't happen... unless someone finds a way to do this without a runtime overhead, which naturally seems impossible. If this is done, TS will become something entirely different as it currently doesn't have a runtime: it's a huge-and-smart linter. But that's all about it. No matter how huge, it's a linter. Reflection would imply something beyond that. Even though I absolutely love reflection, I believe it sho…

It has nothing to do with any runtime. You just write const personType: Type = typeof(Person); This code gets compiled into const personType = { name: "Person", fields: [ { name: "lastName", type: "string" }, { name: "firstName", type: "string" }, ], } There's no runtime. It's just an object which describes layout of some time. If you would implement validation by hand, you'd come up with absolutely conceptually iden…

Oh okay I was thinking of more of a runtime-code-emitting-dynamically kind of thing.

If it's the way you've shown it'd be great!

Post reply on HN