`setKeys()` and `setItems()` do not support ArrayLike Iterables because they use `[].concat()` for a shallow copy

[SamuelTrew]

If I were to call setItems with something like a mobx ObservableArray, to JS it is an iterable object.
So when concat is called at the beginning of the setItems function, it doesn't properly concat, due to not being an actual array. (turns into an array that contains a mobx array that contains an object).

I know this is not exactly the libraries fault, but it would be nice to support ArrayLike Iterables.

I suggest that the spread operator is used instead to copy:

[...items] as opposed to [].concat(items)

Thanks!

[fwextensions]

The idea with this parameter handling was that you could just pass a bare string as the key to score, if you only needed one, rather than an array with one item. The problem with using the spread operator on a string is that [..."foo"] gives you ["f", "o", "o"], which is obviously not what you want.

The constructor requires a single key string be in an array, and it's always been doc'd as an array in setKeys(), so I should just remove that special handling.

[SamuelTrew]

Ahhh yeah I forgot about the string case.
I also thought that the point might have been to use a copy of the keys and not the reference? But I don't think it matters in this case right?

Also, I realised I muddled the title and the text, I was referring to setItems when also setKeys also does it 😅 .
Would setItems be able to be updated as well?
Thanks!

[fwextensions]

You're right, setItems creates a copy of the array as well. I think I was initially avoiding the spread operator/Array.from() for wider compatibility, and avoiding .slice(0) to handle a single bare string. Seems like using slice is the simplest and most compatible solution for making a shallow copy, so I'll make that change.