Our great sponsors
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
There's an old issue open in TypeScript for _exact_ types, which might help in some cases here: https://github.com/microsoft/TypeScript/issues/12936
But there are some problems with that approach, mainly that exact types would be somewhat infectious: A regular type is no longer assignable to its exact type, ie `User` is not assignable to `exact User`, so if you want to use an exact type in a function, you must accept the exact type as a parameter, which spreads to the whole call stack where that parameter is passed. Then union types don't quite work as expected anymore either.
I'm pretty happy with the status quo: Object.keys() is unsafe, so either cast your way around it and let the cast be the signal that you're doing something unsafe, or handle unexpected keys explicitly.
You should take a look at https://zod.dev/ if you haven't already - it's a library for runtime parsing that works really well for your use case.
Types are inferred from the schema though personally I like to handwrite types as well to sense check that the schema describes the type I think it does
You might like TS Reset: https://github.com/total-typescript/ts-reset, which fixes this particular problem. I don't personally find it to be a big issue though.
Regarding runtime type checking, if you were to write something that can handle the total space of possible TS types, you would end up with incredibly complex machinery. It would be hard to make it perform, both in terms of speed and bundle size, and it would be hard to predict. I think Zod or perhaps https://arktype.io/ which target a reasonable subset are the only way to go.
It's also possible -- for specific cases, probably not generally -- define your schema object as const and use type manipulation to generate "real" types automagically. Toy example here: https://github.com/andrewaylett/aylett.co.uk/blob/3fffae1bab...
This lets me run my inputs through a schema validator, and ensure that the type I'm using statically will match the schema used at runtime.
<https://github.com/angular/angular/issues/50439>
The main proposal from a community member is to replace them with the Service Locator pattern (ew). Thankfully someone in-thread provided them with a little wisdom regarding why that's a terrible idea. Here's hoping Angular keeps a nice API.