Allow data to be an array

[daffl]

Closes #64

[marshallswain]

@daffl is there some pending work, here? If not feel free to

[daffl]

Yes, there was some further discussion in #64.

[ekryski]

Yeah, I might be missing something but I'm not sure if this is necessary. See my comment #64 (comment)

[eddyystop]

I've seen errors being passed back as an array for UI's which display all errors together, rather than field by field. Whereas errors being passed back as an object for Ui's that display errors by the field in question.

Is this what this issue is really about?

[daffl]

I'm not sure why this is controversial. The test shows an issue with a use case someone discovered and fixes it in a non-breaking way.

[ekryski]

There is a side effect here. If data.errors is undefined then the data object won't be cloned. If that data object is modified elsewhere it will also be modified here.

The intention was that once the data object is passed in during the creation of a new Error, that data object should be immutable.

[kernelwhisperer]

Can't we just clone the object using:

let clone = JSON.parse(JSON.stringify(data));

In contract to Object.assign() this works well with arrays.

[ekryski]

It is potentially breaking. I don't care whether data is an object or an array. It's fine if it handles both. This just needs to be tuned up a bit. I was merely pointing out that if the intention was for the errors object to be an array then that's already possible.

The data object is meant for any additional metadata beyond the errors object. For example, if you wanted to include the hook method or the user id.

[daffl]

Superseded by #75