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

211–220 of 287 posts

Re: TypeScript please give us reflection/runtime types

#211

Post by nonethewiser »

RyanCavanaugh wrote: post #131
tylerhou wrote: post #76

Earlier quoted context omitted.

Nit: they're not asking for runtime type safety; they're asking for the ability to reflect on types (at compile time, to generate values) so that they can use type information at runtime. This helps ensure runtime type safety because (for example) it would be great to have a generic "validation" function that takes an arbitrary interface and an arbitrary object and validates that object. One way to implement this wou…

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.

Re: TypeScript please give us reflection/runtime types

#212

Post by [deleted] »

tylerhou wrote: post #76
paxys wrote: post #43

I had to read their problem statement like 4 times to understand what they are asking for. This is exactly why simple, concise writing is essential, and their wall of text is...not it. > I love you. You do amazing work. You are gods among mortals. You have brought JavaScript from the darkness, and given it the warm light of strong typing. Look upon us, the cowering meek masses, and understand that we live in the muck…

Nit: they're not asking for runtime type safety; they're asking for the ability to reflect on types (at compile time, to generate values) so that they can use type information at runtime. This helps ensure runtime type safety because (for example) it would be great to have a generic "validation" function that takes an arbitrary interface and an arbitrary object and validates that object. One way to implement this wou…

[deleted]

Re: TypeScript please give us reflection/runtime types

#213

Post by oorza »

RyanCavanaugh wrote: post #131
tylerhou wrote: post #76

Earlier quoted context omitted.

Nit: they're not asking for runtime type safety; they're asking for the ability to reflect on types (at compile time, to generate values) so that they can use type information at runtime. This helps ensure runtime type safety because (for example) it would be great to have a generic "validation" function that takes an arbitrary interface and an arbitrary object and validates that object. One way to implement this wou…

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.

Re: TypeScript please give us reflection/runtime types

#214

Post by rizky05 »

ncallaway wrote: post #205
TheRealPomax wrote: post #105

Earlier quoted context omitted.

Here's the thing though: if you wrote your TS properly, you don't need this and asking for it just highlights that you're not using TS the way it's meant to be used. The only place you need runtime type enforcement (when you're writing your own code in TS) is for validating third party data at the point where you're ingesting it into your own code. Once it's in there, it is type safe if you used TS to compile your co…

> 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 ?

Re: TypeScript please give us reflection/runtime types

#215

Post by jauntywundrkind »

yxre wrote: post #210
jauntywundrkind wrote: post #106

Earlier quoted context omitted.

Counter to this post, as soon as I read the title I knew what this was, & I knew it was speaking exactly to something we've wanted for a long time. This is asking for more official & better supported https://github.com/rbuckton/reflect-metadata . TypeScript is a compiler. It has a lot of type information during compilation. We could write that type information out into a file. Instead what we do is throw that informa…

Why not keep the package separate? I also thought of reflect-metadata separately, and it doesn't hurt to allow users to install plugins to augment core compiler behavior. Some people have very tight constraints for payload size, and types could blow up payloads

It's hard for a plugin to always be begging for sufficient hooks & access to read out the data. Maybe an external project is fine, but it needs some real TLC, not just being a side-quest by a maintainer or two.

Conceptually it feels like there should be/needs to be some buy in on high, a shared vision that tsc is not the one, only & singular tool in the typescript-verse that ever can or will care about types. Trying to constantly break in & exfiltrate the data isn't ever going to get a position where the world takes this seriously; typescript needs really should gladly be opening the gates.

As for whether the type information is in fact part of the payload, that's a separate question, and one that should ideally be configurable. It's definitely a bit of a complex situation in general; ideally we'd have good/easy ways for libraries to include this information but then we also want want to be able to strip it out easily.

Maybe we just regenerate it as needed from ts source of libraries when we need it. But that implies not running a single typescript compile with one set of settings but running many compiles, as each library has its own tsconfig it'll need that informs how files are laid out & other sundry details. I might be overcomplicating. Perhaps we could just generate a foo.reflect.js, that has all the reflection data? There's options.

Re: TypeScript please give us reflection/runtime types

#216

Post by ncallaway »

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 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 = { r: number; g: number; b: number; }

type Bar = {...} type Baz = {...}

I couldn't find a clean way to decompose the type that z.infer produced. It would give me a single type object that was deeply structured. For a pretty flat-simple small schema, z.infer was totally fine.

For the more complicated schema it wasn't _terrible_, I still used it. I made it work, but it definitely wasn't the dev experience I was hoping for.

I think something that went the other way would be much preferable for me. I'd rather define the typescript type, then have some validate() function that was available to me.

Basically, I think it's _easier_ to get a generated validate() function to play nicely with the rest of my code, than it is to get the inferred type to play nicely with the rest of my code.

Re: TypeScript please give us reflection/runtime types

#218

Post by vbezhenar »

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 identical code. Look at any validation libraries out there.

The only difference is: you specify types with nice TypeScript language, not with some made-up abomination DSL.

Re: TypeScript please give us reflection/runtime types

#219

Post by vbezhenar »

hajile wrote: post #165
benatkin wrote: post #66

Please give me an integer type. Just kidding, but I'm not pushing for JavaScript anymore. If rust/WASM works as well, I say go with that.

JS added BigInts quite a while ago.

Yet JSON.parse("9007199254740993") returns 9007199254740992, not 9007199254740993n.
Post reply on HN