4 ms·

This seems extremely hard to read for me, I would have an hard time trying to understand what it does if I found it in any source code

by yulaow 5y ago

skywal_l 5y ago
type Ensure I define a type called Ensure <T, K extends keyof T> This type takes two type parameters, one called T and the other K which will consist of Keys belonging to the type T (in our case, "foo", "bar" or "baz"). = T & This new type (called Ensure) will be equal to the union of two types: One will be T and the other will be: { [U in keyof Pick<T, K>] A new type which keys will be picked among the key listed in K -? To which we will remove the potential optional qualifier : T[U] }; And which types will be the same as in T.
- alpha_squared 5y ago
  This feels like considerable cognitive load for any developer that needs to work in more than one language.
  - chana_masala 5y ago
    Isn't that the main challenge of being a programmer? Anyways I don't find it hard to read, but I write TS like that every day
    - bcrosby95 5y ago
      Probably depends upon your job. The main challenge of being a programmer, in the sorts of projects I work on, is communication - with customers, management, and other developers.
  - jorisd 5y ago
    Most of the implementation details here don't really matter until you need to modify these advanced types directly. That Ensure type definition line in that example is a low level detail that you put in a library somewhere, import throughout your codebase, and then mostly forget about. In practice you'd have someone that understands this set it up once, and then document its usage for others, maybe document the implementation to make it easier to modify later. The TS compiler is surprisingly good at giving you good readable error messages as well when your code violates these advanced types; the errors tell you what you specified and what is supported, it doesn't display the low level type logic as part of the error users see. This means that there's very little need for anyone to really how these type definitions work. EDIT: clarifications and spelling.
    - alpha_squared 5y ago
      Until it's the root cause of code not working as expected, by another developer far removed from initial implementation. Non-obvious code is harder to maintain. Code is written for people, not machines; that means the harder it is for people to maintain, the less useful it actually is.
      - jorisd 5y ago
        Valid point. On the other hand, these kinds of advanced types can prevent lots of bugs and maintenance work, and may therefore be worth the day of debugging when it breaks after two or three years of usage. I've used types like this in a pretty advanced TypeScript UI project consuming lots of services to enforce compile time errors. We were using generated TS clients for all of the APIs we consumed, and the compiler would automatically throw readable errors wherever we were missing form fields or types became incompatible. I committed the advanced type once, documented its usage, and I don't think anyone has had to deal with it since, whilst the types have steadily prevented errors. And even then: it's just type definitions. If it really becomes a maintenance burden or someone has no clue what it does, you can simply replace the type with "any" or something similar and all of your problems are gone and typescript won't complain anymore (at the expense of less type error checking). EDIT: improved wording
        dllthomas 5y ago
        Complicated types (like any complicated code) need their own tests demonstrating that they do what the author thinks (and fails to think about, as it's changed).
    - pavel_lishin 5y ago
      > In practice you'd have someone that understands this set it up once, and then document its usage for others, maybe document the implementation to make it easier to modify later. In practice, that someone then leaves the company, leaving this nightmare underfoot. > The TS compiler is surprisingly good at giving you good readable error messages as well when your code violates these advanced types Only if you're that original person who understands it! I would still have no idea what is happening, no matter how clear.
- jgwil2 5y ago
  > This new type (called Ensure) will be equal to the union of two types You mean intersection, right? EDIT: link to docs on intersection types: https://www.typescriptlang.org/docs/handbook/2/objects.html#intersection-types https://www.typescriptlang.org/docs/handbook/2/objects.html#...
- 0x6c6f6c 5y ago
  Only one small terminology issue: & is an intersection of types, a union is |. So Ensure is an intersection of T and the latter type. Wouldn't Required suffice here as well for this as opposed to removing the optional qualifier?
handrous 5y ago
Me, reading the link at the top of this thread: oh wow, those are really cool. Me, reading this example: oh no, those all need to be added to our project's lint rules to make sure no-one uses them.
- chana_masala 5y ago
  Why would you prevent their usage? They're incredibly helpful
  - handrous 5y ago
    I guess it'd be OK as long as everyone always accompanied such lines with a comment, with at least one line per symbol or character it's identifying & explaining. As all but the most trivial regexes warrant.

This seems extremely hard to read for me, I would have an hard time trying to understand what it does if I found it in any source code

by yulaow 5y ago

This seems extremely hard to read for me, I would have an hard time trying to understand what it does if I found it in any source code

skywal_l 5y ago

type Ensure I define a type called Ensure <T, K extends keyof T> This type takes two type parameters, one called T and the other K which will consist of Keys belonging to the type T (in our case, "foo", "bar" or "baz"). = T & This new type (called Ensure) will be equal to the union of two types: One will be T and the other will be: { [U in keyof Pick<T, K>] A new type which keys will be picked among the key listed in K -? To which we will remove the potential optional qualifier : T[U] }; And which types will be the same as in T.

alpha_squared 5y ago
This feels like considerable cognitive load for any developer that needs to work in more than one language.
- chana_masala 5y ago
  Isn't that the main challenge of being a programmer? Anyways I don't find it hard to read, but I write TS like that every day
  - bcrosby95 5y ago
    Probably depends upon your job. The main challenge of being a programmer, in the sorts of projects I work on, is communication - with customers, management, and other developers.
- jorisd 5y ago
  Most of the implementation details here don't really matter until you need to modify these advanced types directly. That Ensure type definition line in that example is a low level detail that you put in a library somewhere, import throughout your codebase, and then mostly forget about. In practice you'd have someone that understands this set it up once, and then document its usage for others, maybe document the implementation to make it easier to modify later. The TS compiler is surprisingly good at giving you good readable error messages as well when your code violates these advanced types; the errors tell you what you specified and what is supported, it doesn't display the low level type logic as part of the error users see. This means that there's very little need for anyone to really how these type definitions work. EDIT: clarifications and spelling.
  - alpha_squared 5y ago
    Until it's the root cause of code not working as expected, by another developer far removed from initial implementation. Non-obvious code is harder to maintain. Code is written for people, not machines; that means the harder it is for people to maintain, the less useful it actually is.
    - jorisd 5y ago
      Valid point. On the other hand, these kinds of advanced types can prevent lots of bugs and maintenance work, and may therefore be worth the day of debugging when it breaks after two or three years of usage. I've used types like this in a pretty advanced TypeScript UI project consuming lots of services to enforce compile time errors. We were using generated TS clients for all of the APIs we consumed, and the compiler would automatically throw readable errors wherever we were missing form fields or types became incompatible. I committed the advanced type once, documented its usage, and I don't think anyone has had to deal with it since, whilst the types have steadily prevented errors. And even then: it's just type definitions. If it really becomes a maintenance burden or someone has no clue what it does, you can simply replace the type with "any" or something similar and all of your problems are gone and typescript won't complain anymore (at the expense of less type error checking). EDIT: improved wording
      - dllthomas 5y ago
        Complicated types (like any complicated code) need their own tests demonstrating that they do what the author thinks (and fails to think about, as it's changed).
  - pavel_lishin 5y ago
    > In practice you'd have someone that understands this set it up once, and then document its usage for others, maybe document the implementation to make it easier to modify later. In practice, that someone then leaves the company, leaving this nightmare underfoot. > The TS compiler is surprisingly good at giving you good readable error messages as well when your code violates these advanced types Only if you're that original person who understands it! I would still have no idea what is happening, no matter how clear.
jgwil2 5y ago
> This new type (called Ensure) will be equal to the union of two types You mean intersection, right? EDIT: link to docs on intersection types: https://www.typescriptlang.org/docs/handbook/2/objects.html#intersection-types https://www.typescriptlang.org/docs/handbook/2/objects.html#...
0x6c6f6c 5y ago
Only one small terminology issue: & is an intersection of types, a union is |. So Ensure is an intersection of T and the latter type. Wouldn't Required suffice here as well for this as opposed to removing the optional qualifier?

handrous 5y ago

Me, reading the link at the top of this thread: oh wow, those are really cool. Me, reading this example: oh no, those all need to be added to our project's lint rules to make sure no-one uses them.

chana_masala 5y ago
Why would you prevent their usage? They're incredibly helpful
- handrous 5y ago
  I guess it'd be OK as long as everyone always accompanied such lines with a comment, with at least one line per symbol or character it's identifying & explaining. As all but the most trivial regexes warrant.