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

251–260 of 287 posts

Re: TypeScript please give us reflection/runtime types

#251

Post by LtWorf »

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…

Given that several projects exist in python to do this… I guess if you know about types at runtime, it is possible to do it.

I write one of them (typedload).

If it's a union, it has a bunch of heuristics to guess right at the 1st try, but otherwise it will just try them all.

Re: TypeScript please give us reflection/runtime types

#252

Post by thanksgiving »

Eric_WVGG wrote: post #33
thanksgiving wrote: post #29

I’m not an expert or anything but I sincerely feel like this is barking up the wrong tree. To anyone who works on typescript/JavaScript outside the context of a web browser, you DO NOT matter as far as I am concerned. If I was in control of JavaScript/typescript, I’d give zero attention to your demands. You are not my top priority. Go away. I feel like we are losing focus here. Should JavaScript be an all purpose lan…

I don't understand this comment at all. I mostly work on client-side front-end and am absolutely desperate for better type generation. Zod is making me want to jump out a window right now.

My comment is simple. Don’t add anything to JavaScript if it does not help in the context of a web browser. Don’t add anything to typescript emitted output if it isn’t in JavaScript.

Re: TypeScript please give us reflection/runtime types

#253

Post by golergka »

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…

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

Re: TypeScript please give us reflection/runtime types

#254

Post by golergka »

0xb0565e487 wrote: post #153
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…

I'm relatively new to programming and had a question about TypeScript's functionality. Is there any specific reason why TypeScript doesn't allow for the creation of custom and intricate data types? For example, I'm unable to define a number type within a specific range, or a string that adheres to a certain pattern (like a postal code). I'm imagining a language where I could define a custom data type with a regular f…

You can do exactly this with io-ts and fp-ts: https://gist.github.com/golergka/64b06f711e4cb07c67367bdace7...

Re: TypeScript please give us reflection/runtime types

#255

Post by pas »

jitl wrote: post #194
pas wrote: post #186

Earlier quoted context omitted.

Maybe I'm very mistaken, but to me it seems this code snippet is basically an alternative to writing a ton of "infer"-s and overloads, no? So the same pattern matching could be used in the "switch". Whatever the complier knows can be locally matched, and the combinations have to be already handled by the developer.

It's hard to come up with a compiler that produces a sound checker for arbitrarily complex union/intersection types. Perhaps there could be a restriction on reflection to "simple enough" types, but that's always going to be a weirdly moving target based on heuristics. There's already cases where Typescript tries to generate ~40MB+ .d.ts files which are just re-stating the types themselves. So it's easy to imagine a v…

Size, computation and other budgets seem like useful knobs to expose to developers. And anything that's locally decidable (so can be run on multiple cores easily).

Re: TypeScript please give us reflection/runtime types

#256

Post by kristiandupont »

lf-non wrote: post #250
kristiandupont wrote: post #243

Earlier quoted context omitted.

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…

That's a good point.

I just realized that I am working around this problem by explicitly setting a `z.Schema` type: [link redacted]. The reason was to retain JSDoc comments on the types, but I guess this was another positive side effect.

In any case, I agree with you that there is room for improvement.

Re: TypeScript please give us reflection/runtime types

#257

Post by flohofwoe »

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…

The Typescript compiler could probably emit additional JS files with reflection info just as it currently emits .map and .d.ts files (basically a 'type database' that exposes the information that's already in the .d.ts file as JS module, and which can be queried at runtime by type- and property-names (e.g. stuff like "what was the original Typescript type for this Javascript property").

The only missing link is then that Javascript objects don't know their original Typescript type, that would need to be magically injected by the TS compiler as a custom property.

How useful that would be in practice, no idea... I can pretty much only see downsides (mainly increasing bloat).

Also the same thing can probably be implemented in 'user space' by a tool which parses .d.ts files and code-generates such type-database modules from that information.

Re: TypeScript please give us reflection/runtime types

#259

Post by baxuz »

__jem wrote: post #115
baxuz wrote: post #75

Earlier quoted context omitted.

I'm not sure what `generateTypeInfo! ();` is supposed to be, but as far as I'm aware there is no way to execute anything in a JS engine from a type generic.

It's meant to represent a hypothetical TS compiler builtin that does codegen for you.

Ah, yeah I get it.

Re: TypeScript please give us reflection/runtime types

#260

Post by lf-non »

kristiandupont wrote: post #256
lf-non wrote: post #250

Earlier quoted context omitted.

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…

That's a good point. I just realized that I am working around this problem by explicitly setting a `z.Schema ` type: [link redacted]. The reason was to retain JSDoc comments on the types, but I guess this was another positive side effect. In any case, I agree with you that there is room for improvement.

Ah ok. However, typescript is mostly smart enough to propagate comments [1] from zod schema properties to inferred types on its own.

Thanks for maintaining kanel btw. We used to use this in a previous role alongside knex. It was very useful.

[1] https://lorefnon.me/2022/06/25/generating-api-docs-for-zod-t...

Post reply on HN