41–50 of 64 posts
You can do some truly silly things with sufficiently ridiculous uses of typescript. I built a typecheck-time spell checker[0] in it such that: import { ValidWords } from "./spellcheck"; // Typechecks cleanly: const result: ValidWords = "valid"; // Throws a type error const result: ValidWords = "valid"; [0] https://github.com/kkuchta/TSpell
How long does this take to compile?
> If you do find a need to use type operations, please—for the sake of any developer who has to read your code, including a future you—try to keep them to a minimum if possible. Use readable names that help readers understand the code as they read it. Leave descriptive comments for anything you think future readers might struggle with. Also, as you start getting complicated logic in your types, you need to test your…
I lost it when at my previous job I found a 20 multiline super complex type defined by another dev, asked him to describe it because I was in a tight deadline and had not time to parse whatever he was defining. He starts with "it's pretty simple" and then used like 10 minutes to describe me what he meant while writing on paper the various pieces getting confused two times. At the end of the day it could be simplified…
Typescript is just one of those languages where things can get carried away but then reigned in again with a nice complexity gradient.
You can do some truly silly things with sufficiently ridiculous uses of typescript. I built a typecheck-time spell checker[0] in it such that: import { ValidWords } from "./spellcheck"; // Typechecks cleanly: const result: ValidWords = "valid"; // Throws a type error const result: ValidWords = "valid"; [0] https://github.com/kkuchta/TSpell
so that's great and I know this wasn't your point but .... I use this VSCode extension https://marketplace.visualstudio.com/items?itemName=streetsi... To spell check my code. It's surprisingly useful. It doesn't check at compile time but it does check camelCase and snake_case and even in typescript code I've found it highlight various actual issues.
Example of the code: https://github.com/pj/typeshaman/blob/main/packages/graphql/...
Documentation is incomplete, unfortunately I had to get a job. I started working on encoding all of SQL as well.
You can do some truly silly things with sufficiently ridiculous uses of typescript. I built a typecheck-time spell checker[0] in it such that: import { ValidWords } from "./spellcheck"; // Typechecks cleanly: const result: ValidWords = "valid"; // Throws a type error const result: ValidWords = "valid"; [0] https://github.com/kkuchta/TSpell
Earlier quoted context omitted.
Hey Mark, I’m actually currently looking at a similar problem. I’m writing a HTTP client based on composition. The exact details aren’t important, but one of the goals is to have a strong type system for describing a valid pipeline of things like response parsers. Imagine something like Doing “type tests” alone isn’t too hard - we can just use conditional types and the extends keyword. If the code compiles, fine. But…
I use @ts-expect-error for testing the negative case, but if there was a practical way of testing the actual error reported that would be wonderful.
https://github.com/noppa/get-optional/tree/master/tests/typi...
Earlier quoted context omitted.
I believe that typescript type system is so flexible, powerful and complex just because it had to be adapted and built around the shortcomings and limitation of javascript. It makes no sense to have something like it if you build a language from the ground up (or if you could just scrap backward compatibility in a bad designed one)
I think I disagree (though happy to be corrected). It's common to have dervied types (example Base = Shape, Derived = Circle, Rectangle, Hexagon). Often you have a collection of Shape and often there is some runtime code that can go from a Base type to a Dervied type based on some key or value but the relationship between the key and the Dervied type is rarely directly expressed in the type system where as in typescr…
Earlier quoted context omitted.
We do a _lot_ of this in the Redux library repos (examples: [0] [1] [2] ). We have some incredibly complicated types in our libraries, and we have a bunch of type tests to confirm expected behavior. Generally, these can just be some TS files that get compiled with `tsc`, but it helps to have a bunch of type-level assertions about expected types. I actually recently gave a talk on "Lessons Learned Maintaining TS Libra…
Hey Mark, I’m actually currently looking at a similar problem. I’m writing a HTTP client based on composition. The exact details aren’t important, but one of the goals is to have a strong type system for describing a valid pipeline of things like response parsers. Imagine something like Doing “type tests” alone isn’t too hard - we can just use conditional types and the extends keyword. If the code compiles, fine. But…
When doing fancy things with typescript types, be really careful - it's possible to accidentally construct typescript types that will increase your tsc compile times by multiple seconds and the tooling for troubleshooting this is nonexistent. A tiny change to one codebase I work on made compile times go from 300ms to something like 7 seconds and it took me something like 14 hours of grepping and manually bisecting so…
https://docs.microsoft.com/en-us/archive/blogs/ericlippert/l...
Wordle: https://codesandbox.io/s/wordle-typescript-d4srgi?file=/src/...
Anadrome(Anagram Palindrome): https://codesandbox.io/s/anagram-palindrome-7u14xr?file=/src...
Candy Crush 1D: https://codesandbox.io/s/candycrush-u2v5pr?file=/src/index.t...