TypeScript please give us reflection/runtime types • Hacker News Board

Re: TypeScript please give us reflection/runtime types

#281

Post by ncallaway » Sat, Jul 08, 2023, 10:15 PM UTC

cjdell wrote: post #232

rizky05 wrote: post #214

Earlier quoted context omitted.

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 ;

Interesting! I'll probably start doing that. I hadn't connected the satisfies keyword to this problem, but it seems like a good solution.

My complaint about writing the schemas twice isn't the busywork (which is, like, annoying, but whatever I'll live). But the concern about small discrepancies between the two causing problems later.

I'll definitely use this going forward.

Re: TypeScript please give us reflection/runtime types

#282

Post by ouraf » Sun, Jul 09, 2023, 12:40 AM UTC

Can anyone do a "explain lime I'm five" summary of the problem and how the solution would work when typescript is converted down to JavaScript again so the interpreter takes it? Looking from the top it seems like it would add more complexity (and potentially new bugs or exceptions) than it could make things faster and safer.

IF typescript was 100% its own thing and not built on top of JS, it would make complete sense to do it, but with a js engine below it...

Re: TypeScript please give us reflection/runtime types

#283

Post by jpc0 » Sun, Jul 09, 2023, 7:50 AM UTC

Stated differently.

Our JavaScript bundles are not large enough or slow enough. Could you please make it so we can ship even more data to the client and add more branching so we can give our customers an even worse experience.

You want reflection, use a language that has it and ship webassembly to the client, it will likely be significantly more performant than adding even more bloat to what is already needing to run in the JS interpreter.

Re: TypeScript please give us reflection/runtime types

#284

Post by JoBrad » Sun, Jul 09, 2023, 9:00 AM UTC

golergka wrote: post #253

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…

I just declare these structures with io-ts, and get validation, serialization, deserialization code and types for free.

That library is mentioned in the article

Re: TypeScript please give us reflection/runtime types

#285

Post by SergeAx » Mon, Jul 10, 2023, 12:55 PM UTC

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…

> This is not possible at all because TypeScript is a compiler

I don't understand. Go is a compiler too, but here's https://pkg.go.dev/reflect

Re: TypeScript please give us reflection/runtime types

#286

Post by justinmchase » Mon, Jul 17, 2023, 4:30 PM UTC

KnobbleMcKnees wrote: post #244

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…

It is easy. It's just a terrible idea. (So as it turns out having thought about it a bit, I am vehemently against this idea.) Type reflection at runtime would require polluting the JS environment with a lot of cruft. That might be a global object and lots of helper functions to query types. It might also be tagging objects and fields with additional properties that need to be treated as reserved. There is certainly n…

I mostly agree, having every single type checked all the time like other static languages is not appropriate and probably not even a good idea but on the other hand it is also kind of annoying to have your validation code be divorced from your types totally.

For example suppose I have a web request coming in and I have essentially just a string of input coming in on the body. I have an expectation of what it needs to be but there is a step where it is of type `unknown` and I need to convert it into `IMyHandlerInput`. Just casting it is obviously a bad idea and so now I need to essentially use some kind of library such as ajv to do json schema or jtd validation, _then_ I can cast it into my interface.

This is all fine but it definitely feels redundant to me. It would be a cool _ecmascript_ feature to essentially support, not runtime types per-se but syntactic _validation_ which can also be used by typescript to derive types automatically.

This is totally hypothetical but I'm imagining something like this for example:

```ts schema Example { @min 0 id: number

  @pattern /^\w+ \w+$/
  name: string

  @future
  expiresAt: Date

}

const data: Example = new Example(JSON.parse(body)) ```

Something that the JS runtime can use to allow developers to opt-in to extensible validation which can also be used by the typescript interpreter to essentially derive types.

Re: TypeScript please give us reflection/runtime types

#287

Post by justinmchase » Mon, Jul 17, 2023, 4:45 PM UTC

TheRealPomax wrote: post #105

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…

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…

It would be nice if the runtime validation was an ecmascript feature designed in such a way that typescript could infer the types for them automatically... Such as

    schema Example { ... }
    cosnt example: Example = new Example(unkonwnData)

Where a schema applied runtime validation based on declarative syntax and which typescript could use to derive a `type` from