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

161–170 of 287 posts

Re: TypeScript please give us reflection/runtime types

#161

Post by JulianChastain »

IggleSniggle wrote: post #147
thanzex wrote: post #130

Earlier quoted context omitted.

Except for the fact that usually there is not just one single typescript agent working within itself, for which you don't need validation. There are many cases in which you need to verify some object, anything that does not come from your code i would argue is untrusted, I come across this almost daily, it would be absolutely fantastic to just have a way to check does this object conform to this type? Instead, i need…

Just use a run-type transformer like typia, hooked right into typescript-compile. Get your runtime type validators generated from nothing but the typescript definitions. Alternatively, use a runtime validator the provides good type inference out of the box so you're still only declaring your types once.

I would recommend `zod` as a good typescript schema runtime validation library as well. It does require strict type checking to be on however.

Re: TypeScript please give us reflection/runtime types

#162

Post by shortrounddev2 »

lucidone wrote: post #10

OP and those who feel a similar sentiment should give C# a shot, it's what they want regardless of whether they know it or not.

I love C#. At work, when I write standalone tools, I always do them in C#. My boss tolerates this since I'm usually the only one using them. But I don't get to choose what our backend is written in

Re: TypeScript please give us reflection/runtime types

#163

Post by 0xb0565e487 »

bern4444 wrote: post #160
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…

Some of this is possible in the type system like a range: From stackoverflow: https://stackoverflow.com/questions/39494689/is-it-possible-... type Enumerate = Acc['length'] extends N ? Acc[number] : Enumerate type NumberRange = Exclude , Enumerate > type ZeroToOneHundred = NumberRange One limitation is that this has to be bounded on both ends so constructing a type for something like GreaterThanZero is not possible.…

Interesting, thanks!

Re: TypeScript please give us reflection/runtime types

#164

Post by eyelidlessness »

graypegg wrote: post #46
moystard wrote: post #30

Earlier quoted context omitted.

Why does typescript enum really suck?

Typescript enums emit a really weird object at runtime enum CheckboxState { On; ParentOn; Off; } Becomes { [0]: “On”, “On”: 0, [1]: “ParentOn”, “ParentOn”: 1, [2]: “Off”, “Off”: 2 } So things like Object.keys give bizarre results. It’s done this way so you can use the name or the value as an index.

To be clear, this kind of structure is only emitted for numeric enums. String enums with explicitly declared static values are roughly equivalent to the equivalent Record (runtime) and a corresponding type T[keyof T] (type check time).

IME, most of the complaints about enums apply only to numeric ones.

The major exception to that AFAIK is the fact that enum members of any type are treated as nominally typed (as in A.Foo is not assignable to B.Foo even if they resolve to the same static value). I am among the minority who consider this a good thing, but I recognize that it violates expectations and so I understand why my position isn’t widely shared.

Re: TypeScript please give us reflection/runtime types

#166

Post by n2d4 »

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…

> Is the lack of such a feature in TypeScript (or any language) a deliberate design decision to avoid unnecessary complexity, or due to technical constraints such as performance considerations?

It makes a lot of things impossible. For example, if you defined two different types of ranges, OneToFifty and OneToHundred similarly to your PercentType above, the following code would be problematic:

    let x: OneToFifty = ;
    let y: OneToHundred = ;
    y = x;
Any human programmer would say the third line makes sense because every OneToFifty number is also OneToHundred. But for a compiler, that's impossible to determine because JavaScript code is Turing-complete, and so it can't generally say that one is certainly a subset of the other.

In other words, any two custom-defined types like that would be unassignable from and to each other, making the language much less usable. Now add generics, co-/contravariance, type deduction, etc., and suddenly it becomes clear how much work adding a new type to the type system is; much more than just a boolean function.

That said, TypeScript has a lot of primitives, for example, template string types for five-digit zip codes:

    type Digit = '0' | '1' | '2' | '3' |  | '9';
    type FiveDigitZipCode = `${Digit}${Digit}${Digit}${Digit}${Digit}`;
(Actually, some of these are Turing-complete too, which means type-checking will sometimes fail, but those cases are rare enough for the TS team to deem the tradeoff worth.)

Re: TypeScript please give us reflection/runtime types

#167

Post by mixedCase »

JulianChastain wrote: post #161
IggleSniggle wrote: post #147

Earlier quoted context omitted.

Just use a run-type transformer like typia, hooked right into typescript-compile. Get your runtime type validators generated from nothing but the typescript definitions. Alternatively, use a runtime validator the provides good type inference out of the box so you're still only declaring your types once.

I would recommend `zod` as a good typescript schema runtime validation library as well. It does require strict type checking to be on however.

Alternatively, io-ts is more performant and has been around for a while longer. Although it does have a more functional interface.

Re: TypeScript please give us reflection/runtime types

#168

Post by 0xb0565e487 »

n2d4 wrote: post #166
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…

> Is the lack of such a feature in TypeScript (or any language) a deliberate design decision to avoid unnecessary complexity, or due to technical constraints such as performance considerations? It makes a lot of things impossible. For example, if you defined two different types of ranges, OneToFifty and OneToHundred similarly to your PercentType above, the following code would be problematic: let x: OneToFifty = ; le…

Thanks :)

Re: TypeScript please give us reflection/runtime types

#169

Post by seanmcdirmid »

anonzzzies wrote: post #99
seanmcdirmid wrote: post #69

Earlier quoted context omitted.

The point of TypeScript was always to run on web, it wasn't meant to give you a language advantage over say, C#. You use C# if you have to develop for .NET, you use TypeScript if you have to develop for Web, you wouldn't use one or the other in another context. That being said, TypeScript is differently capable from C#. C# is nominally typed, with decent reified generics. I like programming in C#, and miss its featur…

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 running web apps on the CLR, or are you running them in the browser. I don’t really get nodejs, or, i guess it only seems like you would go that route if you wanted to reuse your web browser devs or web browser code to run also in the server.

Re: TypeScript please give us reflection/runtime types

#170

Post by eyelidlessness »

Waterluvian wrote: post #7

Above all of what I write below, I think that this is a very valid issue for discussion and debate. I don't think there's one objective correct answer. So this isn't me dictating what TypeScript shalt be. TypeScript is an entirely optional layer on top of JavaScript, with the exception of `Enum` that emits an object, many of which see as a mistake. You don't even have to "transform" TS code to get JS: you just have t…

> with the exception of `Enum` that emits an object, many of which see as a mistake

There are other exceptions, most of which are considered mistakes as well, the most obvious which come to mind being `module` and `namespace` as runtime constructs. But I’m fairly sure these have been primarily used by TypeScript itself for at least a few years, and even they recently migrated away.

Another one that comes to mind is, I believe, actually pretty popular: what they refer to as “parameter properties”, ie class members whose types are defined in a constructor’s parameters. These seem to have escaped controversy because they eliminate a lot of redundant boilerplate, and generally behave in obvious ways (at least as obvious as their redundant boilerplate JS equivalents).

Post reply on HN