You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm implementing standard-schema support for my library and I'm currently mapping standard-schema Issues to my own equivalent.
The current documentation currently just says "The path of the issue, if any", but it's not clear to me in which situations Issue.path may be omitted.
My first thought was maybe it could be omitted when enforcing some invariant { isOdd: true, num: 1 }. In such case it may not be desirable to use either of the paths [isOdd] or [num] to express that issue, since neither is individually the issue, and a validator might want to express that a higher level - to display that as an issue with the object as a whole rather than any individual property. But in such case, isn't an empty path ([]) appropriate? Is an empty path ([]) equivalent to a lack of a path (undefined)?
I think the spec would benefit from being more specific about this.
The current documentation currently just says "The path of the issue, if any", but it's not clear to me in which situations Issue.path may be omitted.
If someone provides a wrong input for the outermost schema, the path will be undefined or empty. For example, if you define an object schema but your user enters a string, the validation will return and issue for the object schema without a path because the problem occurred at the root.
Sorry, I asked the question directly but you didn't answer it directly: Is an empty path ([]) equivalent to a lack of a path (undefined)? I think you're saying yes, but I want to be clear.
This wasn't only a question, though. It was also essentially a recommendation for you to clarify the wording in the spec. Specs should be very precise, and this part isn't at the moment.
My interpretation was that undefined should be used in cases where the library could not provide a path associated with the error e.g. because they never track it whereas [] would be used if there is explicitly a problem with the root data.
IMO [] should generally be preferred, as the distinction for a consumer is pretty marginal.
Right now Valibot will never return an empty array. If there is a path you can be sure it includes at least one item. I would say the spec is not opinionated about this at the moment as we can't control how library authors implement it. Even if we advise them, there is no guarantee.
Activity
fabian-hiller commentedon Feb 23, 2025
If someone provides a wrong input for the outermost schema, the path will be
undefinedor empty. For example, if you define an object schema but your user enters a string, the validation will return and issue for the object schema without a path because the problem occurred at the root.michaelboyles commentedon Feb 23, 2025
Sorry, I asked the question directly but you didn't answer it directly: Is an empty path (
[]) equivalent to a lack of a path (undefined)? I think you're saying yes, but I want to be clear.This wasn't only a question, though. It was also essentially a recommendation for you to clarify the wording in the spec. Specs should be very precise, and this part isn't at the moment.
ssalbdivad commentedon Feb 23, 2025
My interpretation was that
undefinedshould be used in cases where the library could not provide a path associated with the error e.g. because they never track it whereas[]would be used if there is explicitly a problem with the root data.IMO
[]should generally be preferred, as the distinction for a consumer is pretty marginal.fabian-hiller commentedon Feb 23, 2025
Right now Valibot will never return an empty array. If there is a path you can be sure it includes at least one item. I would say the spec is not opinionated about this at the moment as we can't control how library authors implement it. Even if we advise them, there is no guarantee.