@adsee42 You're right. I thought a lot about this and I'm on the fence. Should you be able to pass object-style error messages like { foo: bar: 'Invalid phone number' } map to the input foo.bar, or should, when setting error messages, you be required to supply the real name of the field?

The inputs with value one makes more sense, since we output an object at the end.

Of course none of this would matter except that updateInputsWithError throws an error if you supply a string that's not the name of the input, and that feature doesn't make sense if we support deep-error-objects, so we would want to remove it, which would be a "breaking" change, and therefore requires more thought.

@rkuykendall
I understand.
Though, why throwing errors if the names do not match? I suppose people using updateInputsWithError with their customized error object (since different servers or api return different errors), and they would know if they didn't see the error messages supposed to show up?

Yeah it feels like an odd feature. I guess the idea is that if you're passing errors to the form and they're not in the form, that's bad and we should let you know.

I'm going to merge the change as-is and leave the questions about input errors for another conversation.

@ThibautMarechal or @felixmosh Can I get a code review if you're free?