3 ms·

Ah, yeah the error makes sense. I expected the error, just wanted to understand how Brand was meant to be actually assigned to a primitive. I'm not sure the fun

• spankalee 2y ago
  The function is great in cases where you can validate the string, or paired with lint rules that limit casting.
  • deleted 2y ago
    [deleted]
  • cush 2y ago
    At that point I'd just use a class constructor.
    • spankalee 2y ago
      That has a lot of overhead compared to validating and casting a primitive.
      • cush 2y ago
        Does it though?
        • gliptic 2y ago
          Yes.
• galaxyLogic 2y ago
  That's a very clear example. But what if I instead wrote: const accountId = AccountId ("125314" ); There would be the needed checks and balances in the function AccountId(). Wouldn't that do pretty much the same thing?
  • svieira 2y ago
    Yes, but then there would be runtime overhead for the wrapper (presuming a class or object is returned) or the type of accountId would be the underlying type (if AccountId isn't returning a branded type).
  • cush 2y ago
    I personally prefer less code and more explicit casting
    • whilenot-dev 2y ago
      const accountId = "125314" as AccountId; or const accountId = new AccountId("125314"); or const accountId = accountIdFromString("125314"); is all "explicit" casting in my understanding, one way or the other, and the first ... as ... being on the lowest level. I'd rather go for something like "do the casting close to the source, and in general use 'parse, don’t validate'[0] when getting input from the outer world". [0]: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
      • cush 2y ago
        Agree. I was talking about const accountId = AccountId (“43525”) being less explicit
      • usrusr 2y ago
        The as also does not burden the reader with guessing about the absence of unexpected stuff happening in the functions. Don't pepper the code with mostly unused hidey-holes just to perhaps save some busywork later. If you do add valuation, make it an honest asValidatedAccountId("123"), not an accountIdFromString("123") that may or may not do more than casting. (PS, very much off topic: speaking of hidey-holes, are any of the AOP monstrosities still operational?)
• yencabulator 2y ago
  And herein lies one of the worst features of Typescript. const myCompanyId = something_complicated as CompanyId; where something_complicated actually is a UserId, not a bare string. It is way too easy to accidentally destroy type safety with `as`, there are absolutely 0 safeguards. I fear every single instance of `as` in any Typescript source I see.