6 ms·

I’d say generally the opposite is true. Most commercial software I’ve worked on typically contained only simple typing—discriminated unions are about as complex

I’d say generally the opposite is true. Most commercial software I’ve worked on typically contained only simple typing—discriminated unions are about as complex as it gets—and it’s more of a problem that people get lazy and start using “any” too much than they go overboard. Where complex types can be a problem is when working with open source libraries, especially when the types are community-developed, separate to the library itself. The library API may not be particularly amenable to easy typing, and the community types can end up being rather confusing, especially to people who developed neither the types nor the original library.

TheCleric 4y ago
I tell my fellow developers at work: "Any is banned. If you want any, use JavaScript, and we don't use JavaScript here. Perhaps you haven't heard about unknown?" In my experience, 90% of the time when a developer uses any, they just don't know about unknown. 9% it's because they are lazy. 1% is because you are implementing something from an imported library, and they fell into the other 99%.
- oblak 4y ago
  Use "unknown" and TS complains that you're treating something as an object. Use Object.defineProperties and TS complains because that stuff is invisible to it after how many years? I think you're right, of course, but TS is hardly perfect and treating its ways as gospel is not an improvement over JS. The "right ways" change over time and beliefs are not shared among everyone.
  - TheCleric 4y ago
    If you know what's in the object cast it as that type or be sure by saying if ('propertyName' in unknownObject). TS is far from perfect. These aren't its ways (it provides any, so of course it's fine with it). These are my restrictions: if you're using a type system, actually use it. Don't lie to yourself and throw anys in your code.
    - beebeepka 4y ago
      any is the last resort. How do you get around properties assigned via Object.defineProperties recognised by TS, though? I really don't know. Is is an unrelated question
      - TheCleric 4y ago
        Here's how I would do it: interface IOptionsX { x: number; } interface IOptionsY { y: number; } const testObj: IOptionsX = {x : 0}; Object.defineProperties(testObj, { y: { value: 100, writable: true }, }); if ('y' in testObj) { // Could also do `&& typeof testObj.y === 'number'` to be VERY sure. const testObjWithY = testObj as typeof testObj & IOptionsY; console.log(testObjWithY.y) }
        TheCleric 4y ago
        Though honestly I've gotten this far without EVER using defineProperty so I'd probably continue that streak.
- eyelidlessness 4y ago
  I make an exception for using any in type params which extend type params, eg const foo = <T extends Record<string, any>>(dict: T) => … This is a good signal that foo maps over dict in some generic way that cares more about its dictionary-ness than its values. Sure, unknown works in that position too, but at least IMO the “doesn’t care” bit is more informative than “doesn’t know”. The latter might imply more type narrowing will happen than is the case.
  - alexgrover 4y ago
    The problem with that is that when consuming of the dictionary, “doesn’t know” is actually more appropriate. If you then access Object.values(foo) in your method you are given an iterable of anys which is unsafe.
    - eyelidlessness 4y ago
      If the function is doing something with the values which is unsafe, sure. My point was the more relaxed constrain on the type signature can be used to imply it’s only concerned with the dictionary’s keys.
      - alexgrover 4y ago
        Coming back to this after the other thread cooled down a bit lol - to me, unknown actually implies that the function doesn’t care about the values more than any, as the compiler will enforce that they’re unused. And in any case, I’d almost always lean towards the option with stronger type safety guarantees. Especially in a team environment when someone else may be modifying your code later. As a convention, I almost never use any.
        eyelidlessness 4y ago
        To me `unknown` signals an intent to know, as in “I don’t know yet” (or put another way, “I don’t have any prerequisites for accepting this value, I can and will narrow it as appropriate”). In a codebase that otherwise takes type safety seriously, `any` in a type parameter (again to me) means “I don’t have any type narrowing agenda for this thing, it’s along for the ride and coming out the other side the same way it showed up”.

TheCleric 4y ago

I tell my fellow developers at work: "Any is banned. If you want any, use JavaScript, and we don't use JavaScript here. Perhaps you haven't heard about unknown?" In my experience, 90% of the time when a developer uses any, they just don't know about unknown. 9% it's because they are lazy. 1% is because you are implementing something from an imported library, and they fell into the other 99%.

oblak 4y ago
Use "unknown" and TS complains that you're treating something as an object. Use Object.defineProperties and TS complains because that stuff is invisible to it after how many years? I think you're right, of course, but TS is hardly perfect and treating its ways as gospel is not an improvement over JS. The "right ways" change over time and beliefs are not shared among everyone.
- TheCleric 4y ago
  If you know what's in the object cast it as that type or be sure by saying if ('propertyName' in unknownObject). TS is far from perfect. These aren't its ways (it provides any, so of course it's fine with it). These are my restrictions: if you're using a type system, actually use it. Don't lie to yourself and throw anys in your code.
  - beebeepka 4y ago
    any is the last resort. How do you get around properties assigned via Object.defineProperties recognised by TS, though? I really don't know. Is is an unrelated question
    - TheCleric 4y ago
      Here's how I would do it: interface IOptionsX { x: number; } interface IOptionsY { y: number; } const testObj: IOptionsX = {x : 0}; Object.defineProperties(testObj, { y: { value: 100, writable: true }, }); if ('y' in testObj) { // Could also do `&& typeof testObj.y === 'number'` to be VERY sure. const testObjWithY = testObj as typeof testObj & IOptionsY; console.log(testObjWithY.y) }
      - TheCleric 4y ago
        Though honestly I've gotten this far without EVER using defineProperty so I'd probably continue that streak.
eyelidlessness 4y ago
I make an exception for using any in type params which extend type params, eg const foo = <T extends Record<string, any>>(dict: T) => … This is a good signal that foo maps over dict in some generic way that cares more about its dictionary-ness than its values. Sure, unknown works in that position too, but at least IMO the “doesn’t care” bit is more informative than “doesn’t know”. The latter might imply more type narrowing will happen than is the case.
- alexgrover 4y ago
  The problem with that is that when consuming of the dictionary, “doesn’t know” is actually more appropriate. If you then access Object.values(foo) in your method you are given an iterable of anys which is unsafe.
  - eyelidlessness 4y ago
    If the function is doing something with the values which is unsafe, sure. My point was the more relaxed constrain on the type signature can be used to imply it’s only concerned with the dictionary’s keys.
    - alexgrover 4y ago
      Coming back to this after the other thread cooled down a bit lol - to me, unknown actually implies that the function doesn’t care about the values more than any, as the compiler will enforce that they’re unused. And in any case, I’d almost always lean towards the option with stronger type safety guarantees. Especially in a team environment when someone else may be modifying your code later. As a convention, I almost never use any.
      - eyelidlessness 4y ago
        To me `unknown` signals an intent to know, as in “I don’t know yet” (or put another way, “I don’t have any prerequisites for accepting this value, I can and will narrow it as appropriate”). In a codebase that otherwise takes type safety seriously, `any` in a type parameter (again to me) means “I don’t have any type narrowing agenda for this thing, it’s along for the ride and coming out the other side the same way it showed up”.