5 ms·

> Like isObject([]) returning true - arrays aren't objects in my mental model. Correct me if I am wrong, but Array factually are JS objects and "[] instanceof

by 7bit 1y ago

> Like isObject([]) returning true - arrays aren't objects in my mental model. Correct me if I am wrong, but Array factually are JS objects and "[] instanceof Object" is true. Fair enough if that does not fit your mental model, but I would not use any library that treats facts like opinions.

ivanjermakov 1y ago
Distinction is tricky since you can use indexing on plain objects, e.g. const foo = {}; foo[0] = "bar";
- rafram 1y ago
  Right. For the purposes of standard library functions that operate on array-like objects, { length: 1, 0: "item" } is an array.
williamdclt 1y ago
I agree with the author that it’s almost never what you want. But I agree with you that it’s the reality of the platform, ignoring it will cause its own problems. I’d surface the footgun rather than trying to pretend it’s not there: isNonArrayObject and isObjectOrArray, or something like that
- 7bit 1y ago
  Absolutely agree. I also hate that empty arrays are true, which is different from other languages. But I agree that it's better to face the reality of the language than create a function that evaluates [] to false. It trains you a bad habitnand some day that will cause you to introduce a bug.
  - williamdclt 1y ago
    > I also hate that empty arrays are true, which is different from other languages I don’t mind that actually! I don’t think I have much use cases for “empty array is semantically different from non-empty”. Usually I find null/undefined are better choices, an empty array is just a normal array, I don’t expect it to be handled differently
    - 7bit 1y ago
      What do you think about empty strings being falsy in most languages including js? Null/undefined is a better choice, but there's many occasions where you do not have the power of choice. For example with document.querySelectorAll, which returns an empty array if nothing is found. The simple thing to do is to just check for it's length or just iterate over it's nodes, but still. I prefer empty arrays being falsy. Just to clarify, I'm not saying one is better than the other. I just prefer how it works in other languages like Python. But I still would rather work with the JS language properties, than import a library that changes how I test for empty arrays.
      - nothrabannosir 1y ago
        Akshually, implicitly casting any non Boolean type to true or false is no better than implicitly casting “0” to 0. :) B-)
        7bit 1y ago
        No better based on what criteria? In what language? This is typical in Python and done even by core-devs. It is how the language was designed and it was designed to support that.
        nothrabannosir 1y ago
        In the "akshually" sense. "Zen of programming" (or "I'm smart because I use the word monoid unironically"). "If is an anti pattern", "null values are an anti pattern", "`string' is an anti-type", "util libraries are an anti pattern", etc. And of course "boolean is an anti type" but let's not get into that. :D (Nor into the value of "idiomatic python" as an argument on healthy programming habits....)
        7bit 1y ago
        Ah got it. Based on personal opinion. Thanks for explaining.
- dcsan 1y ago
  your option is a bit more verbose but definitely more clear. confusing the underlying definitions of the language itself will lead to problems later.
  - PUSH_AX 1y ago
    Will it? Will it really? I’ve been writing JS for so long I’ve forgotten all these language quirks, I feel like it’s fair for most people, these language choices are kind of meaningless in day to day, what’s meaningful is a function returning things that will make sense to most people. Or at least have two functions, languageStrictIsObject()
    - williamdclt 1y ago
      Yeah, in practice I would only encounter the case of arrays being objects when doing something highly polymorphic (eg reading some JSON that can be anything), which likely would have test cases for every type anyway. But when I’m writing a reusable lib and I can’t perfectly abstract a gotcha, I design the API so that the dev _has_ to make an explicit decision rather than defaulting on their behalf (defaults are evil). So, isObjectOrArray and isObjectNonArray: you have to think about which applies. Another example is sorting: does it sort in-place or immutably? Make it explicit in the function name. Does a function expect a sorted array or will it sort itself? Make it explicit in the function name. And maybe provide both variants.
- moritzwarhier 1y ago
  Lodash also has "isPlainObject". Not sure if that's as performant as using Array.isArray or even simpler trickery (see below), but it seems that this fixes it. "isObject" is just not well-defined for other cases that might be interesting, in my opinion. Not just "null" or arrays. Functions can have properties (although they don't have the object prototype or primitive type). Class instances behave differently compared to plain objects when used with libraries or other code that inspects the shape or prototype of objects, or wants to serialize them to JSON. If you deal with unknown foreign values that are expected to be a JSON-serializable value, you could go with something like isObject = (o) => !!o && typeof o === "object" && !Array.isArray(o) But it does not deal with all the non-JSON objects, e.g. Map or other class instances that are not even JSON-serializable by default. When data comes from parsing unknown JSON, the check above should be enough. In other cases, the program should already know what is being passed into a function. No matter if through discipline or with the aid of an additional type syntax. For library code that needs to reflect on unknown data at runtime, I think it's worth looking at Vue2's hilarious solution, probably a very good and performant choice, no matter how icky it might look: https://github.com/vuejs/vue/blob/547a64e9b93d24ca5927f653710b5734fa909673/src/util/lang.js#L293 Since the string representations of built-ins have long ago become part of the spec, it seems that there is no real issue with this!
bryanrasmussen 1y ago
libraries of this sort, especially in JavaScript, often exist to enforce a more reasonable mental model rather than the model baked into the language.
- 7bit 1y ago
  I understand that. I just don't think that it is a good habit. Instead of just learning the languages and it's quirks now you form a bad habit and start to rely on one dependency for all your projects.
  - bryanrasmussen 1y ago
    this is generally the view I have on these sorts of things as well, although I must admit that my views are often out of step with what everybody else I work with feel on the matter.
dschuessler 1y ago
> any library that treats facts like opinions The word 'object' has different meanings. One includes arrays and the other does not. They prefer the latter. You prefer the former. I don't think this has much to do with 'facts' and 'opinions', but rather with the practicality of choosing a certain way to speak. I’d liken it to the word 'sorting'. JavaScript libraries sort in a certain way that is simple to implement. However, this is so different from what we typically mean by 'sorting' that people came up with natural sorting algorithms. Are these people treating facts like opinions on how to sort? I’d rather say, they acknowledge the relevance of a certain way to speak.

by 7bit 1y ago

ivanjermakov 1y ago

Distinction is tricky since you can use indexing on plain objects, e.g. const foo = {}; foo[0] = "bar";

rafram 1y ago
Right. For the purposes of standard library functions that operate on array-like objects, { length: 1, 0: "item" } is an array.

williamdclt 1y ago

I agree with the author that it’s almost never what you want. But I agree with you that it’s the reality of the platform, ignoring it will cause its own problems. I’d surface the footgun rather than trying to pretend it’s not there: isNonArrayObject and isObjectOrArray, or something like that

7bit 1y ago
Absolutely agree. I also hate that empty arrays are true, which is different from other languages. But I agree that it's better to face the reality of the language than create a function that evaluates [] to false. It trains you a bad habitnand some day that will cause you to introduce a bug.
- williamdclt 1y ago
  > I also hate that empty arrays are true, which is different from other languages I don’t mind that actually! I don’t think I have much use cases for “empty array is semantically different from non-empty”. Usually I find null/undefined are better choices, an empty array is just a normal array, I don’t expect it to be handled differently
  - 7bit 1y ago
    What do you think about empty strings being falsy in most languages including js? Null/undefined is a better choice, but there's many occasions where you do not have the power of choice. For example with document.querySelectorAll, which returns an empty array if nothing is found. The simple thing to do is to just check for it's length or just iterate over it's nodes, but still. I prefer empty arrays being falsy. Just to clarify, I'm not saying one is better than the other. I just prefer how it works in other languages like Python. But I still would rather work with the JS language properties, than import a library that changes how I test for empty arrays.
    - nothrabannosir 1y ago
      Akshually, implicitly casting any non Boolean type to true or false is no better than implicitly casting “0” to 0. :) B-)
      - 7bit 1y ago
        No better based on what criteria? In what language? This is typical in Python and done even by core-devs. It is how the language was designed and it was designed to support that.
        nothrabannosir 1y ago
        In the "akshually" sense. "Zen of programming" (or "I'm smart because I use the word monoid unironically"). "If is an anti pattern", "null values are an anti pattern", "`string' is an anti-type", "util libraries are an anti pattern", etc. And of course "boolean is an anti type" but let's not get into that. :D (Nor into the value of "idiomatic python" as an argument on healthy programming habits....)
        7bit 1y ago
        Ah got it. Based on personal opinion. Thanks for explaining.
dcsan 1y ago
your option is a bit more verbose but definitely more clear. confusing the underlying definitions of the language itself will lead to problems later.
- PUSH_AX 1y ago
  Will it? Will it really? I’ve been writing JS for so long I’ve forgotten all these language quirks, I feel like it’s fair for most people, these language choices are kind of meaningless in day to day, what’s meaningful is a function returning things that will make sense to most people. Or at least have two functions, languageStrictIsObject()
  - williamdclt 1y ago
    Yeah, in practice I would only encounter the case of arrays being objects when doing something highly polymorphic (eg reading some JSON that can be anything), which likely would have test cases for every type anyway. But when I’m writing a reusable lib and I can’t perfectly abstract a gotcha, I design the API so that the dev _has_ to make an explicit decision rather than defaulting on their behalf (defaults are evil). So, isObjectOrArray and isObjectNonArray: you have to think about which applies. Another example is sorting: does it sort in-place or immutably? Make it explicit in the function name. Does a function expect a sorted array or will it sort itself? Make it explicit in the function name. And maybe provide both variants.
moritzwarhier 1y ago
Lodash also has "isPlainObject". Not sure if that's as performant as using Array.isArray or even simpler trickery (see below), but it seems that this fixes it. "isObject" is just not well-defined for other cases that might be interesting, in my opinion. Not just "null" or arrays. Functions can have properties (although they don't have the object prototype or primitive type). Class instances behave differently compared to plain objects when used with libraries or other code that inspects the shape or prototype of objects, or wants to serialize them to JSON. If you deal with unknown foreign values that are expected to be a JSON-serializable value, you could go with something like isObject = (o) => !!o && typeof o === "object" && !Array.isArray(o) But it does not deal with all the non-JSON objects, e.g. Map or other class instances that are not even JSON-serializable by default. When data comes from parsing unknown JSON, the check above should be enough. In other cases, the program should already know what is being passed into a function. No matter if through discipline or with the aid of an additional type syntax. For library code that needs to reflect on unknown data at runtime, I think it's worth looking at Vue2's hilarious solution, probably a very good and performant choice, no matter how icky it might look: https://github.com/vuejs/vue/blob/547a64e9b93d24ca5927f653710b5734fa909673/src/util/lang.js#L293 Since the string representations of built-ins have long ago become part of the spec, it seems that there is no real issue with this!

bryanrasmussen 1y ago

libraries of this sort, especially in JavaScript, often exist to enforce a more reasonable mental model rather than the model baked into the language.

7bit 1y ago
I understand that. I just don't think that it is a good habit. Instead of just learning the languages and it's quirks now you form a bad habit and start to rely on one dependency for all your projects.
- bryanrasmussen 1y ago
  this is generally the view I have on these sorts of things as well, although I must admit that my views are often out of step with what everybody else I work with feel on the matter.

dschuessler 1y ago

> any library that treats facts like opinions The word 'object' has different meanings. One includes arrays and the other does not. They prefer the latter. You prefer the former. I don't think this has much to do with 'facts' and 'opinions', but rather with the practicality of choosing a certain way to speak. I’d liken it to the word 'sorting'. JavaScript libraries sort in a certain way that is simple to implement. However, this is so different from what we typically mean by 'sorting' that people came up with natural sorting algorithms. Are these people treating facts like opinions on how to sort? I’d rather say, they acknowledge the relevance of a certain way to speak.