how to implement human readable error wrappers

[jspaaks]

This discussion is to collect ideas about patterns that make the ajv schema validation errors more readable by humans.

[abelsiqueira]

One solution would be to use ajv-errors (ajv-validator/ajv-errors) and modify the schema (either the json file or the read object).

[abelsiqueira]

I created a proof of concept for this idea in #491

[jspaaks]

Error propagation thread

The problem of errors has various aspects, e.g.

1. propagating errors to a higher level
2. showing errors that have no associated input field
3. wrapping a given schema error

This is the start of a thread about mechanisms with which to propagate errors. For example when authors/4/orcid has a schema problem, how does the error get propagated up the "tree" to authors/4 and ScreenAuthors?

[jspaaks]

If it is possible to do this with a compound ajv-errors query, that would obfuscate the need for propagating / aggregating errors.

[abelsiqueira]

I was thinking of a centralized errorCategorized structure, like

errorCategorized = {
  'start': {
    'title': ...
    'message': ...
  },
  ...
}

So we can say useErrorCategorized().start.title for field level, hasError(useErrorCategorized().start) for screen level and similar for Stepper. But I am not sure how to best approach this with reactivity since neither the errors nor the cff objects are used directly.

[jspaaks]

Showing errors that have no associated input field thread

The problem of errors has various aspects, e.g.

1. propagating errors to a higher level
2. showing errors that have no associated input field
3. wrapping a given schema error

For example, errors related to anyOf, minItems, additionalProperties, required, etc have no associated input field. This thread is to discuss how to deal with that, how to combine with lower level errors, how to display, etc.

[abelsiqueira]

My proposal is to do most of what is being done, with some changes:

• Don't show errors twice - e.g., if an e-mail in an author has error, then only show the error on the field
• Show error in the closest place (in the field, rather than in a banner; in the screen, rather than in a separate screen; etc.)
• Show errors that don't have associated fields on the screen - minItems (required authors should not exist? Add an author and delete the author leads to a different state #490 )
• I don't know what error is additionalProperties
• anyOf only error when one of the values inside it errors. So it is an indirect duplicate and should be ignored.

[jspaaks]

• additionalProperties is when you use a keyname that is not defined in the schema. Users should never get that particular error because they don't set the keynames. NB I have had this error a few times when I forgot to kebabcase the cff object somewhere during development.
• ignoring irrelevant anyOf cases can only be done if we test for the value of schemaPath

[abelsiqueira]

• In that case I also suggest ignoring additionalProperties
• It's possible. I am also thinking of something like Pitfall of a different validation strategy #508, with the selection of the matching errors instead of filtering. This way, whatever is not selected is ignored.

[jspaaks]

O I didn't get that from that issue #508, but I agree with it. The general setup would be:

1. have the user edit form fields
2. which updates the model
3. which updates the cff state managed by the composable useCff
4. this triggers validation (maybe in a separate composable, maybe as part of useCff)
5. the resulting plain list is filtered down (not filtered out) to only what is relevant for a given purpose, e.g. using ajv-errors or some homegrown mechanism. The mechanism needs to use at least instancePath and schemaPath, but probably also one of params and message
6. The errors messages are then replaced with more readable / actionable ones.

[abelsiqueira]

I made a proof of concept for the strategy in #517. It doesn't deal with error messages at all for now.

[jspaaks]

Error wrapping thread

The problem of errors has various aspects, e.g.

1. propagating errors to a higher level
2. showing errors that have no associated input field
3. wrapping a given schema error

This thread is to discuss the aspects that have to do with mechanisms to recognize and filter errors from the flat list that ajv produces, how to know what to replace the error with, and how to display the updated error text.

[abelsiqueira]

The ajv-errors approach is to replace errors in the schema level. One or more errors e: ErrorObject = { ... } are wrapped in another ErrorObject with the fields:

• keyword: errorMessage
• message: "our Message"
• params: errors: [e]
• The instancePath can be different
• The schemaPath is changed to something with errorMessage.

In this solution:

recognize and filter errors from the flat list that ajv produces

Unchanged/doesn't depend on refactoring.

how to know what to replace the error with

This is hardcoded in a separate json file.

and how to display the updated error text.

Any system that works for ajv works for this, in principle, by just looking inside the params.errors.

---

More details about the error replacing:

The specificity of the errorMessage defines which errors it captures. For instance, here are 3 options to add the error messages to authors:

{
    "properties": {
        "authors": {
            "errorMessage": "Author screen has errors"
        },
    }
}

or

{
    "properties": {
        "authors": {
            "errorMessage": {
                "minItems": "Needs at least 1 author",
                "uniqueItems": "Each author must be unique"
            }
        },
    }
}

or

...
        "authors": {
            "errorMessage": {
                "minItems": "Needs at least 1 author",
                "uniqueItems": "Each author must be unique"
            },
            "items": {
                "errorMessage": "Some author has errors"
            }
        },
...

• The first will always say Bad in the banner: for empty authors, required, duplicated authors, but also for errors in the individual authors.
• The second will error for empty authors and duplicated authors only.
• The third will error as above but also for individual authors.

[jspaaks]

I wonder if we can use the pattern from the first snippet to replace the error propagation, for example for ScreenStart can you do:

{
    "required": [
        "title",
        "message"
    ]
}

and have it fire when either of these properties is missing? If so, we can use that as the error state for the metroline stop and the screen