Issues when using the library to implement an RJSF validator

[x0k]

Related to rjsf-team/react-jsonschema-form#4923

I continued working on the validator using this library and encountered the following issues:

• The library is not published, so it cannot be specified as a peer dependency.

• Errors still cannot be retrieved synchronously, for two reasons:

1. Localization - in addition to being synchronous, it would be preferable to avoid using platform-specific APIs and ensure tree-shaking support
2. constructErrorIndex is asynchronous and not exposed in the public API

At the moment, I had to duplicate the implementations of Localization and constructErrorIndex in the validator project.

• When validating an object with missing properties, the library returns an error like this:

[
  {
    "message": "Missing required ⁨properties: ⁨id, email, and age⁩⁩",
    "instanceLocation": "#",
    "schemaLocations": [
      "https://example.com/v0#/required"
    ]
  }
]

This is correct and suitable for something like a REST API, but for form validation it would be preferable to get the following list (not structurally identical, but equivalent in content), so that errors can be displayed for specific fields:

[
  {
    "message": "Missing required ⁨property: ⁨id",
    "path": ["id"]
  },
  {
    "message": "Missing required ⁨property: email⁩⁩",
    "path": ["email"]
  },
  {
    "message": "Missing required ⁨property: age⁩⁩",
    "path": ["age"]
  }
]

Here is how it currently works with AJV:

• Each field has its own error
• Errors include metadata such as missingProperty, propertyName
• If metadata is present, the validator appends it to the instancePath during error processing

[jdesrosiers]

The library is not published, so it cannot be specified as a peer dependency.

It'll be published to npm like normal when it's ready. For now, you can use github:hyperjump-io/json-schema-errors to install it and try it out.

1. Make Localization synchronous #216 - in addition to being synchronous, it would be preferable to avoid using platform-specific APIs and ensure tree-shaking support

Yes. That's the plan.

constructErrorIndex is asynchronous and not exposed in the public API

You shouldn't need to use constructErrorIndex. See evaluateCompliedSchema for an example. It uses the JsonSchemaErrorsOutputPlugin to build the normalized output synchronously while validating instead of converting the validation output.

NOTE: Once Localization is synchronous, I'm going to move the validate functionality to @hyperjump/json-schema. I realized that the JsonSchemaErrorsOutputPlugin isn't in the public API yet and it will need to be for both your objective and mine.

This is correct and suitable for something like a REST API, but for form validation it would be preferable [...] that errors can be displayed for specific fields

That's interesting. I see why this representation doesn't work for your use case. But, if we change it to what you suggest, then it doesn't work for another use case we're targeting, which is LSP errors. If the error is on a non-existent location, we can't use it to display the error inline in the editor. That's why it needs to be on the object. This is a good example of how different situations often require different error handling. There's no one-size-fits-all solution.

You can use addErrorHandler to provide those messages yourself. You should be able to make a copy of the required error handler and make some small tweaks to get the behavior you want. Currently there's only a way to add error handlers, not to remove or replace one. So, we'd have to make some changes to allow for that.

[x0k]

That's interesting. I see why this representation doesn't work for your use case. But, if we change it to what you suggest, then it doesn't work for another use case we're targeting, which is LSP errors. If the error is on a non-existent location, we can't use it to display the error inline in the editor. That's why it needs to be on the object. This is a good example of how different situations often require different error handling. There's no one-size-fits-all solution.

I had the following solution in mind:

• Add an option to control error merging in order to preserve the current behavior
• The error’s instanceLocation points to the object with missing fields, and the error contains metadata to determine which specific field it relates to

[jdesrosiers]

I'm not really seeing your vision. Could you provide an example?

[x0k]

[
  {
    "message": "Missing required ⁨property: ⁨id⁩⁩",
    "instanceLocation": "#",
    "schemaLocations": [
      "https://example.com/v0#/required"
    ],
    // https://ajv.js.org/api.html#error-parameters
    "params": {
       "missingProperty": "id"
    }
  },
  {
    "message": "Missing required ⁨property: email⁩⁩⁩⁩",
    "instanceLocation": "#",
    "schemaLocations": [
      "https://example.com/v0#/required"
    ],
    "params": {
       "missingProperty": "email"
    }
  }
]

[jdesrosiers]

Thanks. I get the idea now. params is a catch all place to put arbitrary data associated with an error. I don't think that's the right approach for this project.

The goal of the standard output format was to provide machine readable data that third parties use to produce output appropriate for the user's domain (API, CLI, LSP, Forms, etc). Each domain has their own needs and can have different needs. This project is intended to be one of those third party processors of the standard output that produces an opinionated output. It's not intended to be the thing that provides all the data someone might need to build something that works in their domain.

I think adding params to the standard output would be a good idea, but I don't think it's appropriate here. I think a more appropriate approach would be to eventually introduce different modes aimed at different domains. There could be a mode specifically tailored for the needs of form validation. I think we want to focus on covering one domain first before we start expanding, but you can always get a head start by using the extension mechanisms to provide custom error handlers where needed.