Open ArmorDarks opened 7 years ago
Is it per design?
Yes (in order to handle nested types), however you can change the default behaviour adding a prefix through the path
option
function myvalidate(value, type) {
return t.validate(value, type, { path: [type.displayName] })
}
Hm, I see. Though, it's unclear, why tcomb-validate
can't try to access struct's name at first place, without need to specify path?
Also, maybe it worth to add in readme?
Obviously, I'm not familiar with all pitfalls and tcomb
is very new for me, so, I'm sorry if I'm raising something that already has been discussed hundreds times.
IIRC validations are assumed to be relative (hence the "/name"
string in the error message) to a root type which is never mentioned, except in this trivial case
console.log(t.validate(1, Schema).errors) // => Invalid value 1 supplied to Person
The path of the root however can be customized through the path
option.
(I don't necessarily agree with the old me on this topic, I'm just explaining why it works like that)
Hm, I'm quite confused. I'm probably missing something...
So, this
console.log(t.validate(1, Schema).errors) // => Invalid value 1 supplied to Person
will mention Schema
name (Person
)?
But this one will not?
console.log(tv.validate(data, Schema).errors) // => Invalid value undefined supplied to /name: String
For some reason
tcomb-validation
outputs different fromtcomb
error message — it doesn't account forname
option oft.struct
.Example:
tcomb
will producetcomb-validation
will produceNote how
tcomb
printsPerson
as name fromstruct
, buttcomb-validate
does not.Is it per design?