Allow to override schema order validation error behavior

[buenonadav]

Prerequisites

• I have read the documentation

What theme are you using?

material-ui

Is your feature request related to a problem? Please describe.

I am using react-jsonschema-form (RJSF) in a web application where schemas are dynamically received from the server. These schemas are user-defined and, in some cases, may be incomplete or invalid.

Specifically, when the order field in the schema is incomplete or missing a property, the application renders a hardcoded HTML error that cannot be customized or controlled.

Upon reviewing the code, it appears that a static

element is rendered in such cases, preventing any control over the error handling, customization of the error message, or modifying the template. This issue seems to originate from the following code:

https://github.com/rjsf-team/react-jsonschema-form/blob/main/packages/core/src/components/fields/ObjectField.tsx#L263

Here is an example of the UI that is generated in such scenarios:

Would it be possible to provide a way to handle or customize this error, such as an option to override the default behavior or allow for custom error templates?

Describe the solution you'd like

There are several potential solutions that would provide more control over schema validation errors:

• Allow for a customizable template for schema validation errors, similar to how other TemplateTypes are handled.
• Introduce a schema validation error handler (similar to the onError handler) that enables developers to handle these errors gracefully.
• Provide a way to catch and manage the error programmatically, allowing for custom error handling logic.

The key requirement is gaining the ability to control or customize the behavior when these validation errors occur.

Describe alternatives you've considered

Currently, I am manually validating the order field before passing the schema to RJSF and handling any errors as needed.

[nickgros]

@buenonadav Are you interested in implementing this? All of your potential solutions sound great to me. Introducing a custom template might be the best fit within the rest of our API. I don't have a preference for which one you pick, but maybe @heath-freenome does?

[heath-freenome]

@buenonadav I like the custom template idea, where the default is what we already have