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

Re: TypeScript please give us reflection/runtime types

#241

Post by can16358p » Sat, Jul 08, 2023, 8:09 AM UTC

mrkeen wrote: post #98

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…

No runtime necessary, if I understand the problem. Input is bytes. Bytes will never carry their type information (and if they did, you couldn't trust them). So the type information needs to be used in the Deserialiser, not its input. To get typed deserialisation of Foo, the compiler needs to generate a FooDeserialiser automatically for you. The compiler can't depend directly on Foo (Foo is written after the compiler)…

Then I'm all in. I thought something done at runtime dynamically, instead of statically genereting type information at compile time.

It'd be lovely the way you described.

Re: TypeScript please give us reflection/runtime types

#242

Post by auggierose » Sat, Jul 08, 2023, 8:32 AM UTC

Dylan16807 wrote: post #195

paxys wrote: post #176

Earlier quoted context omitted.

No, they have a plugin into the typescript compiler which uses their API. tsc already exposes all of the info they need.

Okay so it's not a forked compiler but it's adding a feature to the compiler. At which point it makes a lot of sense to ask why that feature shouldn't be merged.

Because of feature creep. I don't need that feature. Don't merge things that can be kept separate. It is called modularity.

Re: TypeScript please give us reflection/runtime types

#243

Post by kristiandupont » Sat, Jul 08, 2023, 8:38 AM UTC

lf-non wrote: post #230

rizky05 wrote: post #214

Earlier quoted context omitted.

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.…

Why would a ts-native offering produce better error messages when it comes to complex types? That is an issue with TS in general (or rather, with complex types in any typesafe language).

Re: TypeScript please give us reflection/runtime types

#244

Post by KnobbleMcKnees » Sat, Jul 08, 2023, 8:38 AM UTC

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…

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 no way to do this that doesn't make assumptions about the runtime environment in a way that will cause a mountain of issues further down the line.

The other reason for my disdain is: the need to infer types at runtime is almost certainly indicative of an architectural issue with your code. If you aren't able to write viable code in a given context without requiring runtime type querying then you should step back from your intent and re-evaluate your code structure.

Re: TypeScript please give us reflection/runtime types

#245

Post by anonzzzies » Sat, Jul 08, 2023, 8:39 AM UTC

seanmcdirmid wrote: post #169

anonzzzies wrote: post #99

Earlier quoted context omitted.

But that’s when you focus on the type system theory and I agree with that. I don’t see how enforcing types after compilation has anything to do with a programming language for the web vs ‘not for the web’ though, but I understand it is the philosophy to check the types and then drop to plain JS. Best tool for the job, sure, but literally losing everything typed you wrote and designed after compilation is just not as…

TypeScripts goal of being just a layer over JavaScript led to its type system design being primarily productivity based: the goal was to make programming nicer, using types to get more performance wasn’t a goal or option. C#, and the CLR underneath it, were performance based, and the types feed into that. The reason they both are as they are is because of the environments they are meant to be used in. So ya, are you…

Yes, and I am aware of the histories, we just want (and need) something more now. Typescript still seems well positioned for this. Not many reasons you cannot fix this with a compiler flag (which is default off).

Re: TypeScript please give us reflection/runtime types

#246

Post by mrloba » Sat, Jul 08, 2023, 8:42 AM UTC

vbezhenar wrote: post #77

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…

TypeScript is not JavaScript with type annotations. One of the modes, may be. TypeScript supports emitting old JS constructions which look nothing like original typescript code. So it's more like type annotations + babel. Adding one more thing to this set. Extremely useful thing. I think it's a good idea. I miss it. It's crazy that I can't JSON.parse string into typed structure safely. Every other language can do tha…

You can easily parse json into types using something like typebox. Not only does this work, it works much better than many other languages. Have fun trying to represent even a simple patch request, or discriminated union, in something like c#

Re: TypeScript please give us reflection/runtime types

#247

Post by kristiandupont » Sat, Jul 08, 2023, 9:00 AM UTC

shortrounddev2 wrote: post #158

andix wrote: post #145

Earlier quoted context omitted.

So you want TypeScript to be Java, but you don't want to use Java, because your developers only know TypeScipt. Sounds like an unsolvable problem.

The solution is to pile features onto typescript that were never intended to be there, the same way we have done with Javascript, HTML, CSS, and HTTP. None of these things are pure, and all of them have been ravaged by competing interests and committees who were all making financially driven decisions when writing the standards. It would be best to abandon javascript and typescript as backend languages. I don't mind…

I, on the other hand, would pick TS over .NET or Java any day. But I am sure you will conclude that it can only be because I am no good at my job.

Re: TypeScript please give us reflection/runtime types

#248

Post by pjmlp » Sat, Jul 08, 2023, 9:23 AM UTC

andix wrote: post #152

scotty79 wrote: post #135

Earlier quoted context omitted.

Maybe official preprocessor plugins for TypeScript compiler could help? I understand that everybody who needs it can already put their own preprocessor that generates runtime objects from type information before the code is passed to tsc for compilation. But the effort is inconsistent and distributed. If TypeScript officially supported pluggable preprocessor and plugin ecosystem for it some good solutions might get d…

What's next? An official TypeScript UI framework, will it be Vue, React, Next.js or Svelte? An official TypeScript date library?

This is the curse of guest languages, after the initial adoption pain everyone wants idiomatic libraries and pretends the underlying platform doesn't exist.

Until they hit a roadblock caused by a leaky abstraction, that proves them otherwise.

Re: TypeScript please give us reflection/runtime types

#249

Post by mrloba » Sat, Jul 08, 2023, 9:30 AM UTC

shortrounddev2 wrote: post #156

medler wrote: post #18

I’m mainly a backend programmer, so I know just a little typescript, but I don’t really understand what they’re asking for here. It sounds like they want to serialize and deserialize typescript types automatically? If so, that sounds like a good fit for a library, not something most languages offer. (Please educate me if I’m missing the point)

There is currently no good way to automatically validate the object input to a typescript API. In the way that you can simply specify the class of a POST body to a spring boot controller or Asp.Net controller, every class in typescript requires you write the type information twice: once for the typescript compiler, and once again for the runtime deserializer, in the form of decorators. Having to write extra code to m…

My experience is the opposite of yours. With typescript I use an openapi spec to validate and generate types. For other entry points I use typebox to create validators and generate types. It requires a bit of work, but it adds a lot of capability even beyond basic deserialization.

With c# I've seen openapi interface generators that don't validate properly, only basic deserialization. I've seen dto's that are deserialized wrong due to lacking null checking attributes. I've seen the way put requests are misused due to how difficult it is to separate null and undefined in patch requests. I've seen dto's with all nullables due to the lack of union types. Maybe I've yet to see a good c# codebase, but I certainly prefer typescript over the above.

Re: TypeScript please give us reflection/runtime types

#250

Post by lf-non » Sat, Jul 08, 2023, 9:44 AM UTC

kristiandupont wrote: post #243

lf-non wrote: post #230

Earlier quoted context omitted.

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.…

Why would a ts-native offering produce better error messages when it comes to complex types? That is an issue with TS in general (or rather, with complex types in any typesafe language).

No.

Imagine a Zod schema like:

const UserLocation = z.object({ address: Address, coords: Coords })

where Address, Coords are other zod schemas.

Now if I infer a type like:

type IUserLocation = z.infer

Th inferred IUserLocation is something like:

type IUserLocation = { address: { city: string, country: string, ... }, coords: { lat: string, long: string } }

The extracted type does not refer to separate Address, Coords type, it is a single complex type that represents the complete nested structure.

So if I do something like:

const userLocation: IUserLocation = { address: { ... }, coords: { lat: 0, long: 0 }}

The error message is complex because it (effectively) says that coords.lat was expected to be a string from IUserLocation["coords"]["lat"] but it was number

However, if I define a ts interface directly:

interface IUserLocation { address: IAddress coords: ICoords }

now any errors reported against this interface will be more comprehensible because they will (effectively) say that coords I am providing does not comply with ICoords.

This is a contrived example, but this becomes more complex when you have deep compositions of zod types.

This issue of typescript not using well named intermediate types when types are "extracted" from schema definitions like zod is what makes the error messages complex.

This would not apply if typescript was to provide runtime type checking for interfaces defined in typescript (as opposed to them being inferred) because ts will have a way to "know" about these intermediate types. Then the type errors would not have to be always reported against the complex top level type.