No not necessarily! I just haven’t written type import support yet; though you’re welcome to help.
And no — type safety is applied at the HTTP interface. API consumers need no special library to get all the benefits.
And no — type safety is applied at the HTTP interface. API consumers need no special library to get all the benefits.
So it's basically validation middleware. The HTTP protocol does not define any such thing.
There are various tools for it already, but the JS ecosystem has always been up for yet another framework.
I use a JsonObject to do type narrowing and generate appropriate error messages when I receive invalid data over the wire: https://www.npmjs.com/package/@retrohacker/json-types
In every codebase I’ve added this to, I’ve found invalid parsing logic.
I feel like this type, or something similar, should be bundled in the official TypeScript project. That untested data comes out as “any” is not a good developer experience in my opinion.
And “unknown” is basically broken for type narrowing.
How? Typescript 4.9 improved it for type narrowing significantly. https://devblogs.microsoft.com/typescript/announcing-typescr...
Last weekend I actually hacked an an experiment to codegen narrowing unknown to a specific type and it works pretty well https://github.com/joshhunt/codegen-json-validator-experimen...
https://github.com/microsoft/TypeScript/issues/25720
Working with untrusted types in a GraphQL project lead me to creating that JsonObject module.
I wrote up what I was thinking at the time here: http://www.blankenship.io/essays/2022-12-01/
Maybe this has improved.
You mean you could use a library that helps you with checking the shapes?
Using the json-types module above, you assign your incoming json object to the JsonObject type. Then you type narrow by validating the payload contains the properties you are using.
So you can:
const user = (await body.json()) as JsonObject;
// This is properly type narrowed and will work
if (typeof user.emailAddress === "string") {
// do something with user.emailAddress
}
// The compiler will let you know you can't trust
// user.name to be a string at this point. This
// would have generated an exception at runtime
// for a malformed payload if the compiler didn't
// catch it.
user.username.split(" ")
// You can also do type narrowing with early returns
if(typeof user.age !== number) {
return new Error("user.age is expected to be a number");
}
// You can now use user.age with type safety
```Not sure what particular use case you have in mind but which language has built-in functionality to validate chunks of bytes without some kind of type definition? To me this is an orthogonal problem to language design. Every web framework has to serialize and deserialize data.
What I was getting at is that TypeScript is perfectly suited to define type safe data structures wihtout reinventing the wheel. If you're going to parse type definitions for your validation middleware you might as well use something that can also applied to your business logic.