intersection() function for array

[cybertino]

I am surprised that there is intersects() but no intersection() function which would return common items from both arrays.

Would that be useful to add?

[cybertino]

Any thoughts, @aleclarson?

[aleclarson]

Hey @cybertino, thanks for bringing this up. I've given it some thought, and I wonder if we shouldn't just deprecate the intersects and diff functions. They all seem to be mere syntax sugar. See below for examples.

const a = [1, 2]
const b = [2, 3]

intersects(a, b) // => true
// …identical to:
a.some(n => b.includes(n)) // => true

diff(a, b) // => [1]
// …identical to:
a.filter(n => !b.includes(n)) // => [1]

Same goes for your proposed intersection function:

intersection(a, b) // => [1, 2, 3]
// …identical to:
a.concat(b.filter(n => !a.includes(n)))

So I guess the question is whether it's actually worth having these functions if they're so easy to implement with native APIs. If anyone wants to argue in favor of keeping them (and adding intersection), feel free to chime in below.

Also, I should briefly mention the optional identity argument that both intersects and diff accept:

const a = [{ id: 1 }, { id: 2 }]
const b = [{ id: 2 }, { id: 3 }]

intersects(a, b, obj => obj.id) // => true

diff(a, b, obj => obj.id) // => [{ id: 1 }]

Since the native API patterns always use a callback, it's straight-forward to manipulate the values, but may become a little verbose:

a.some(aObj => b.some(bObj => aObj.id === bObj.id)) // => true

a.filter(aObj => !b.some(bObj => aObj.id === bObj.id)) // => [{ id: 1 }]

Too verbose? I'm not so sure. For this more advanced use case, we could consider adding a comparing function that can be used for "identity mapping" as well as other things:

// This would be provided by Radashi.
export const comparing = (toKey) => {
  return (a) => {
    const key = toKey(a)
    return (b) => key === toKey(b)
  }
}

const compareId = comparing(obj => obj.id)

a.some(aObj => b.some(compareId(aObj)))

For expensive comparisons, we could introduce lazyTransform for caching the compared values:

// This would be provided by Radashi. It returns a transformer function backed by a cache.
export const lazyTransform = (transform, cache = new Map()) => (input) => {
  if (cache.has(input)) {
    return cache.get(input)
  }
  const output = transform(input)
  cache.set(input, output)
  return output
}

// For expensive mapping, use lazyTransform for caching:
const compareSum = comparing(lazyTransform(obj => sum(obj.numbers)))

a.filter(aObj => !b.some(compareSum(aObj)))

Curious what the @radashi-org/core team thinks of this, too. 😄

[cybertino]

Thanks for the reply @aleclarson !

In your example given that

const a = [1, 2]
const b = [2, 3]

I would expect intersection(a, b) to return [2] and not [1, 2, 3]. Otherwise I would call it union().

I guess the implementation would look like:

a.filter(n => b.includes(n))

I agree that is easy enough to implement. But IMO having functions in the library that are easy to implement is just fine. Depends on how frequently they are used. Thus, if they are in demand you don't have to implement it again in each project you work on. Just install radashi and have them. This is just convenient, especially if you already using not-that-simple radashi functions.

I personally find intersection() a common case. That's why I posted this suggestion.

As for identity function, I did not even find that option in docs.

[aleclarson]

Hey again, @cybertino. My apologies for the misunderstanding about intersection's behavior. In truth, I've never needed such a function. 😅

One of Radashi's core values is to avoid syntax sugar. That said, if intersection could be considered an order of magnitude “easier to read”, then there may be a case for adding it. Of course, that heuristic is subjective, so I would prefer more community input before adding this.