TypeScript: Template string types and mapped type 'as' clauses | Hacker News Reader

TypeScript: Template string types and mapped type 'as' clauses

github.com

31 pointsKinrany15 comments

Ok for real, is Typescript going to collapse one day from the complexity of its type system?

Typescript's type system became Turing complete years ago, and hilariously, someone linked that issue to the new types mentioned in this post :) https://github.com/microsoft/TypeScript/issues/14833

I've been using Typescript for years, and I still like it. But I'm starting to get frustrated by the sheer amount of "stuff" they keep adding to the type system. My coworkers are too. They don't want to spend weeks reading about "advanced types", just want TS to be a nice wrapper around JS.

Typescript doesn't have a standard library or a runtime, so eventually can't they just call it done? Just do occasional maintenance releases to keep up with new JS features

What is wrong just using what you're comfortable with? Why are you asking TS to halt any new feature development because you don't want to keep up?

On the one hand, yes, the code examples in that PR thread are kind of terrifying.

On the other, the ability to map mechanically between type names would be really useful, and is something I’ve previously wished for. It would, for example, enormously simplify type generation for Zapatos[1], which currently creates multiple long object mappings for this purpose, such as:

    export type SelectableForTable<T extends Table> = {
        accounts: accounts.Selectable;
        appleTransactions: appleTransactions.Selectable;
        authors: authors.Selectable;
        books: books.Selectable;
        emailAuthentication: emailAuthentication.Selectable;
        employees: employees.Selectable;
        identityTest: identityTest.Selectable;
        stores: stores.Selectable;
        tags: tags.Selectable;
        tableInOtherSchema: tableInOtherSchema.Selectable;
    }[T];

[1] https://jawj.github.io/zapatos/

Since you're generating types anyway, can't this be simplified to `tableTypes[T]['Selectable']`?

Nice thought, thanks, but I don't think so.

The way things are set up, your `tableTypes[T]` would need to map table names to namespaces, and this gives errors like "Cannot use namespace 'X' as a type".

Would be pleased to be proved wrong, though. :)

I still really, really want RegExp types

Is the javascript regex literal or builtin RegExp type not sufficient for your needs? What are they missing?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I think the op is asking for actual type refinement by a regex condition.

That would make a lot of sense given the topic at hand. Thanks for the clarification.

especially as a library maintainer, I would really love to be able to say, for example, "you have to pass an email address to this prop" or "you have to pass a US phone number"

This can be fairly smoothly achieved already: https://dev.to/gcanti/functional-design-smart-constructors-1...

Yeah I'm familiar with branded types, but they're cumbersome and require API changes beyond just type narrowing to implement. I just wish they'd figure out how to implement strong types in typescript without js side effects.

So you're the one I should blame whenever some regex fails to validate my perfectly standards compliant email address!

I get very frustrated when I sign up for storefronts using an email with a `.dev` address and some wanker decides that I shouldn't be allowed to give them money because my email address doesn't end in `@gmail.com`.

Stop this. Regex is not the right tool for this job. If you're going to use the regex hammer at least use the full standards compliant one shown here: https://stackoverflow.com/a/201378

> The problem with regular expressions is that telling someone that their perfectly valid e-mail address is invalid (a false positive) because your regular expression can't handle it is just rude and impolite from the user's perspective. A state engine for the purpose can both validate and even correct e-mail addresses that would otherwise be considered invalid as it disassembles the e-mail address according to each RFC.

No, it's an inner-source library, but thanks for expressing your generalized frustration at me!

But also I would use a standards-compliant regex. I also hate it when people don't implement standards to spec.

Or if you're even too lazy for that, just match `.+@.+` and handle errors properly if sending an email fails (which you'll obviously have to handle anyways as a valid email address might not be in service)

Reply on news.ycombinator.com