Ajv Errors to Data Tree

Map ajv errors into a tree that resembles the structure of the validated data. I.e., parse the errors' instancePaths into a tree.
Example:
instancePath: /a/b/c
``javascript
{
node: {
a: {
errors: [],
node: {
b: {
errors: [],
node: {
c: {
errors: [{instancePath: "a/b/c", ...}]
}
}
}
}
}
}
}
`
See more examples.

JSONSchema standard

This package handles errors, generated for the draft-7 jsonschema spec, which is the default in ajv.

What it doesn't do

I haven't actually tested it thoroughly, with real errors and all the possible keywords. What I did test it with is what's in the demos. Although, in parsing the tree it relies solely on the instancePath property.

Contributing

Improvement suggestions, issue reports, contributions are kindly welcome.

Usage

Install

`bash
npm i --save ajv ajv-errors-to-data-tree
`

Use

`javascript
import Ajv from 'ajv'
import {toTree} from 'ajv-errors-to-data-tree'
const ajv = new Ajv({allErrors: true, strictRequired: true})

const validate = ajv.compile({
type: 'object',
properties: {
obj: {
type: 'object',
properties: {
num: {type: "number"},
str: {type: "string"}
}
required: ['str'],
additionalProperties: false
}
}
})

const badData = {
obj: {
num: "a string, despite the schema says this must be a number",
c: "an additional property, which is not allowed by the schema"
}
}

validate(badData)

const errorsTree = toTree(validate.errors)

// access errors following the structure of the data
const numErr = errorsTree.node.obj.node.num
`

Customize Errors


`javascript
class CustomErrorFormat {
constructor(data) {
this.data = data
}
}

const customErrorsTree = toTree(validate.errors, (data) => {
return new CustomErrorFormat(data)
})

// returns true:
customErrorsTree.node.obj.node.num.errors[0] instanceof CustomErrorFormat
`

Traverse Error Trees


WARNING: this is a prototype, might be buggy.
`javascript
import {traverseTree} from 'ajv-errors-to-data-tree/src/helpers.js'

traverseTree(customErrorsTree, (e, fieldName, parentNode) => {
if (!(e instanceof CustomErrorFormat)) throw new TypeError("errors must inherit CustomErrorFormat")

// remove the error from the tree, by returning null
if (!Object.keys(e.data).length) return null

// modify the error, by returning a non-undefined value
if (e.data.message) return {...e, message: e.data.message}

// else, keep the error unchanged
})
`
demo: demoTraverseTree in ./src/demo/helpers.js

More examples


Demos of these examples can be found in ./demo/to-tree.js

Basic

instancePaths: /a/b/c, /a/b/d
`javascript
{
node: {
a: {
errors: [],
node: {
b: {
errors: [],
node: {
c: {
errors: [{instancePath: "a/b/c", ...}]
},
c: {
errors: [{instancePath: "a/b/d", ...}]
}
}
}
}
}
}
}
`
demo: mergePathsOfNamedNodes

With array items

instancePaths: /a/0/0/b, /a/0/0/c
`javascript
{
node: {
a: {
errors: [],
node: [{
index: 0, errors: [],
node: [
{index: 0, errors: [], node: {
c: {errors: [{instancePath: "/a/0/0/c", ...}], ...},
d: {errors: [{instancePath: "/a/0/0/d", ...}], ...}
}}
]
}]
}
}
}
`
demo: mergePathsWithArrItems

Some of the keywords for the object type

The errors for the required, additionalProperties and propertyNames keywords (among others) will have their instancePath set to the path of the instance that should(n't) contain the properties. But toTree will attach these errors to the nodes, corresponding to the properties themselves.

E.g., for errors:
`javascript
[
{
instancePath: "/a/b",
keyword: "required",
params: {
missingProperty: "c"
}
},
{
instancePath: "/a/b/d"
}
]
`

the result will be:
`javascript
{
node: {
a: {
erorrs: [],
node: {
b: {
errors: [],
node: {
c: {errors: [{instancePath: "/a/b", keyword: "required", params: {missingProperty: "c"}, ...}], ...},
d: {errors: [{instancePath: "/a/b/d"}, ...], ...}
}
}
}
}
}
}
`
toTree does this by using the params property in the errors, which specifies the name of the property which violated the rule.

demo: paramsToTree

Multiple errors for the same path


errors:
`javascript
[
{instancePath: '/a/b', v: 'b0'},
{instancePath: '/a/b', v: 'b1'}
]
`

output:
`javascript
{
node: {
a: {
errors: [],
node: {
errors: [],
node: {
b: {
errors: [
{instancePath: '/a/b', v: 'b0'},
{instancePath: '/a/b', v: 'b1'}
],
node: null
}
}
}
}
}
}
`
demo: samePathErrors

empty-string instancePath


errors:
`javascript
[
{
instancePath: '',
},
{
instancePath: '',
keyword: 'required',
params: {
missingProperty: "a"
}
}
]
`

output:
`javascript
{
errors: [{instancePath: ''}],
node: {
a: {
errors: [{instancePath: '', keyword: 'required', params: {missingProperty: 'a'}}]
}
}
}
`
demo: emptyInstancePathC

Bad input handling


Here are some examples of bad input that I could come up with (you can find demos in ./demo/to-tree.js):
1. instancePath bad format: the value not being formatted like a path.
If, for example, it doesn't contain slashes, than it simply be treated as a single node name. I don't do anything to handle such case.
2. Contradictions in the errors data.
What if there's two errors for the same path, one with a keyword relating to the number type and another with a keyword, relating to the string type. toTree won't do anything about it, it will just push both errors to the same node.
3. instancePath bad format: e.g., ///, /a//c. This could result in node names being empty strings. toTree generates exception if this happens (demo: conflictingNodesA, conflictingNodesB).
4. Conflicting node specifications in instancePaths of different errors. E.g., /a/0/b, /a/c/d: the a node according to the former must be an array, but according to the latter - an object. Such cases cause an exception in toTree (demo: emptyNodeName`).