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

261–270 of 287 posts

Re: TypeScript please give us reflection/runtime types

#261

Post by kristiandupont »

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

Earlier quoted context omitted.

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

Hah, I wasn't aware! I think that must have been fixed after I tried it the first time because I definitely concluded that it was necessary back then. And thank you for the kind words!

Re: TypeScript please give us reflection/runtime types

#262

Post by yewenjie »

chmod775 wrote: post #188

Since it's not explicitly listed there, I feel I should shout out David Blass and his incredibly cool ArkType project[1]. It's typescript wizardry. He sometimes (used to?) streams himself working on twitch and it's a really comfy place to hang out.[2] [1] https://github.com/arktypeio/arktype [2] https://www.twitch.tv/arktypeio

How complete is arktype actually? The README says a lot of the syntax is yet to be developed, and don't even get me started on the horror of the docs site.

Re: TypeScript please give us reflection/runtime types

#263

Post by fouc »

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…

thoughts on the other poster asking for type info to be kept around in the Class objects after compilation?

Re: TypeScript please give us reflection/runtime types

#264

Post by haskman »

A lo of people in this thread seem to be misunderstanding what is being asked for. There is no runtime reflection needed. What is really needed is -

1. A way to get a value that represents the type of any statically known type (i.e. known at compile time). 2. A way to compare two typereps for equality. 3. A way to convert between types if the typereps are equal.

This is basically the equivalent of the `Typeable` class in Haskell and PureScript (https://hackage.haskell.org/package/base/docs/Data-Typeable....). Both Haskell and PureScript erase types at runtime, so it is possible to do without adding a runtime to TypeScript as well.

Re: TypeScript please give us reflection/runtime types

#265

Post by chmod775 »

yewenjie wrote: post #262
chmod775 wrote: post #188

Since it's not explicitly listed there, I feel I should shout out David Blass and his incredibly cool ArkType project[1]. It's typescript wizardry. He sometimes (used to?) streams himself working on twitch and it's a really comfy place to hang out.[2] [1] https://github.com/arktypeio/arktype [2] https://www.twitch.tv/arktypeio

How complete is arktype actually? The README says a lot of the syntax is yet to be developed, and don't even get me started on the horror of the docs site.

Until a short while ago it was still very much work in progress.

Right now a lot of work seems to be going into getting a 1.0 release out of the door (the current one is still marked alpha).

Re: TypeScript please give us reflection/runtime types

#266

Post by 0xb0565e487 »

wk_end wrote: post #177
0xb0565e487 wrote: post #153

Earlier quoted context omitted.

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…

This is a feature some (experimental) programming languages have - look into dependent types. The long-and-short of it is that it adds a lot of power, but comes at an ergonomic cost - the more your types say about your code, the more the type checker needs to be able to understand and reason about your code, and you start to run up against some fundamental limits of computation unless you start making trade-offs: giv…

Awesome, thanks for the pointers!

Re: TypeScript please give us reflection/runtime types

#267

Post by shortrounddev2 »

kristiandupont wrote: post #247
shortrounddev2 wrote: post #158

Earlier quoted context omitted.

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.

No, I'm sure you have your reasons, but deserializing and validating is much more painful in typescript than it is in .Net or Java so I'm not sure why you would choose that

Re: TypeScript please give us reflection/runtime types

#269

Post by andix »

pjmlp wrote: post #248
andix wrote: post #152

Earlier quoted context omitted.

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.

Type script does a very good job not to hide the underlying platform. In it's essence it is just a development time linter and does not interfere with the JavaScript runtime at all (except enums).

And I think that's actually the reason why it won the competition against Googles Dart. They even used Microsofts TypeScript for Angular instead of their own language Dart.

Re: TypeScript please give us reflection/runtime types

#270

Post by shortrounddev2 »

mrloba wrote: post #249
shortrounddev2 wrote: post #156

Earlier quoted context omitted.

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

My preference is to have my types defined in code first, rather than in markup language files which generate the code. Having to rely on 3rd party code generation tools because your language lacks a feature is, as I see it, code smell. I'm not sure how to handle the scenario of undefined fields in a PATCH, but I also don't tend to write APIs that way
Post reply on HN