71–80 of 88 posts
[flagged]
This comment encapsulates perfectly what's wrong about the ts talibans... Astonishing to see how their minds can't comprehend that businesses can and do thrive with js.
What I can't comprehend is wanting types and building a custom library instead of using the right tool
I also just don't get the resistance to TS that we see so often in public projects and npm libraries, it's not harder or any more complicated:
JS REPL: "node"
TS REPL: "npx ts-node"
Run JS file: "node file.js"
Run TS file: "npx ts-node file.ts"
Just do it.
Earlier quoted context omitted.
No, and neither does Typescript. One of the biggest weaknesses in Typescript is that it can't validate data across the wire. Which is a major use case for the language. There are various tools for it already, but the JS ecosystem has always been up for yet another framework.
I hear you, but I don’t think this is necessarily true. It does leave type checking to your parsing logic, but the compiler can give you strong guarantees that you’re being defensive about untrusted structured data. 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 adde…
You mean you could use a library that helps you with checking the shapes?
Earlier quoted context omitted.
I hear you, but I don’t think this is necessarily true. It does leave type checking to your parsing logic, but the compiler can give you strong guarantees that you’re being defensive about untrusted structured data. 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 adde…
The compiler can't help you at all when reading and validating data at runtime. 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
```Earlier quoted context omitted.
I hear you, but I don’t think this is necessarily true. It does leave type checking to your parsing logic, but the compiler can give you strong guarantees that you’re being defensive about untrusted structured data. 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 adde…
> 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.
Type Safety != Runtime Type Validation. Something being Type Safe means that I, the programmer, am Safe from making type mistakes while developing and maintaining the software. For that to be possible, you need a type system that is embedded in the language and the editor and can continously analyze all of your code types to be correct. Type safe means that any breaking change to any interface will immediately error…
And you can use TypeScript all day but not be protected from missing or wrong data validation. No compiler in the world can help you there.
Earlier quoted context omitted.
> 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...
I haven't worked much in typescript over the last 10 months, but last time I tried type narrowing on untrusted data typecast to unknown I ran into a handful of problems documented here: 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-…
Seems like you put a lot of work into this and as such I'm hesitant to criticize. But what in the world made you think this is superior to using an actual type-safe language like TypeScript? /** * Streams results for our lovable assistant * @param {string} query The question for our assistant * @stream {object} chunk * @stream {string} chunk.id * @stream {string} chunk.object * @stream {integer} chunk.created * @stre…
Earlier quoted context omitted.
…or just use Zod?
I don't like writing type definitions with zod's DSL. I want to write definitions in the "first party syntax" - which both JSDoc and Typescript types are - and have everything else generated out from that.