Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use json-pointer instead of dot-joined paths for the field property of errors #84

Open
mike-marcacci opened this issue Jun 21, 2015 · 3 comments

Comments

@mike-marcacci
Copy link

Right now the an error message looks something like this:

[
    { field: 'data.y', message: 'is required'},
    { field: 'data.x', message: 'is the wrong type'}
]

This makes it easy to work with until one of the field names contains a period. Using json-pointer would solve this. It's extremely fast to build and parse, is a well known standard, and is already part of json-schema.

// the object
{
    'domains': {
        'www.google.com': {
            'company_name': 22
        }
    }
}

// the error
[
    { field: 'domains.www.google.com.company_name', message: 'is the wrong type'}
]


// using json-pointer
[
    { field: '/domains/www.google.com/company_name', message: 'is the wrong type'}
]
@watson
Copy link
Collaborator

watson commented Jun 21, 2015

A forward slash is also a valid key in JSON unfortunately - in fact any valid string can be used as a key. So for this to work simply switching the delimiter will not do the trick :(

I haven't really thought through the implications of fixing this issue - so I'm purely speaking from a technical perspective here - but I think apart from moving to a nested structure in the error messages as well, we'd have to resort to escaping to non-delimiters... at least that's the only thing I can think of right now.

@mike-marcacci
Copy link
Author

Ah yes, the json-pointer spec already handles escaping by using ~1 to replace a slash, and ~0 to replace a tilda. This makes for really performant single-pass encoding/decoding.

Honestly, I suggest using this mostly because it is a well accepted standard; IMHO the best way to specify a path is an array of segments, which is more useful and used language constructs instead of convention to ensure fidelity.

@LinusU
Copy link
Collaborator

LinusU commented Feb 16, 2016

I would love to have this implemented, since currently a root-object called data is appended to the fields. This means that your first error in the second example actually is this:

[
    { field: 'data.domains.www.google.com.company_name', message: 'is the wrong type'}
]

Notice the data. part. This confused me big time as documented in #109.

I think that it would be immensely useful for it to print / for the root instead of data..

@mafintosh If you give the go-ahead, I would be happy to implement this for you :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants