Do not throw error for TypedArrays

[dy]

Hi @blakeembrey!

This tiny enhancement recognizes typed arrays instead of throwing error.

[blakeembrey]

What's the use-case of having TypedArray's not error? Just wondering, seems like you'd just not run arrayFlatten on them.

[coveralls]

Coverage decreased (-1.5%) to 98.485% when pulling 2d33a69 on dfcreative:patch-1 into d5446b9 on blakeembrey:master.

[dy]

One use case is colormap module.
By default it returns nested colors, and it is handy to have them flattened.
But passing them to webgl requires array to be converted to Float32Array, as it is done in gl-spectrum.
As far converting array to floatArray each time data should be passed to webgl is not really a good idea, the data is stored as floatArray. Moreover, any type of pixel data is oftentimes stored in typedarrays.

So the same data can be stored as a nested array, plain array or typed array. And it would be really handy to call flatten to ensure any type of array-like data is flattened.

Of course it can be done manually each time before calling flatten. But considering branching and multiple entries where passed data should be flattened, that just leads to duplicated and too verbose code.

[dy]

Though ok, the package is prefixed array-, and it has some old-node support, so maybe makes sense to leave it as is.
I found that flatten fits better for this use-case. Sorry for disturbing.

[blakeembrey]

@dfcreative If you want to flatten anything into an array, just call flatten.from(...).

[dy]

Ok, thanks. To my misfortune I did not read readme after main use-case.
Is there really a specific need for array-ish structures? What is the point of main entry then, except for checking that the argument is strictly an array? Some performance boost?

[blakeembrey]

No performance difference. It's there for developer UX. In case someone tries to use it with something unexpected (but works) like a string.

[dy]

But the same may happen with flatten.from, how does...
Ok, array check does not justify 4 methods in API where there really should be one. And that is what makes UX, not the validation with fictive usefulness. If validation came at no price, then ok, but there it blocks intuitive expectations.
That is just opinion, nevermind.

[blakeembrey]

If you looked at the README, it's one method validated and one method not. I can't quite understand the rest of what you said, sorry.