Add a alias to .size : .length

[jdeniau]

Sometime, you just don't want to know if you are working with an immutable object, or a plain JavaScript one.

Imagine the following pseudo React Component:

type Props = {
  items: Array<Item> | List<Item>
}
function ItemList({ items }: Props) {
  if (items.length === 0) {
    return 'No item found';
  }

  return (<div>
    {items.map(item => <Item item={item} />)}
  </div>)
}

In that case, Array and List do implements .map, but there is an issue because List does not implements .length, but only .size.

In that case, we will have to do something like this:

if (
  Array.isArray(items) && items.length === 0
  || items.size === 0
)

That seems really counterproductive.

My proposition is to add an alias .length on every structure to make the API easier to work with.

If we do that, then we will add length on every data structure that implements .size to be consistant and have an non confusing API.
So not only Immutable.List Immutable.Set will have .length, just like Array and plain Set, but also Map().length will exist, even if Javascript object won't (for the record it might have .keyLength in the future).

I don't see any possible breaking change here. The only change is method like isArrayLike, in immutable or in user-land will now return true.

[jdeniau]

What do you think @bdurrer

[bdurrer]

I had that thought before too. I am fine with that addition, but I wonder if it would just move the "is it native or not" down the line to some other operation

It would be kinda breaking tho, as I bet some of us use it as a poor substitute for "isImmutable"

[jdeniau]

move the "is it native or not" down the line to some other operation

Yes, there will still be, as a matter of fact, even .map or .filter are different as Immutable's List.map/filter have a second parameter context and method like .zip do not exists on array. If you are working with a Javascript Set, then the includes method is named has.

In those cases, you should rely on isImmutable, or another discriminant, but the purpose here is to address a use case that seems pretty large, and can be confusing between JS and immutable API.

It would be kinda breaking tho, as I bet some of us use it as a poor substitute for "isImmutable"

You are right, it's too sensitive to be pushed in v5, but it might come in v6 then.