Custom(Unknown) Validation Rules with Custom Error messages

#1

In our implementation of JsonForms we have built a drag and drop interface which our users can use to build forms that will be filled out by their customers. To explain the app in a simplistic way, we have built a user interface for generating schema to render forms using this library.

We are looking to allow users to create their own validations on a field by field basis.

For example if a user adds an input field into their form and labels it Membership Account ID. We want to allow them to attach a custom validation rule to this field. The validation rule needs to show a custom error message when it is not met. An example of the types of random validations that would be made are: the first four characters must be ACBD, followed by seven numbers, followed by one character, and must end in a -0. These types of validation rules are completely unknown to us before they are created. We are hoping to do this with a Regex rule and error message structure like follows. So the user would be putting in their own regex string and error message when this regex does not meet the value returned by the control.

As far as I can tell by reading previous posts and questions there are two approaches to this. The first would be to create a new type for any field they create a validation for. Then we would inject the new rules for each type into JsonForms using AJV. In the example above the schema type for their input field would be something like type: membership-account-id or something. This seems like a straight forward approach and has the benefit of using the pre-packed validation. It seems to not play well with testers though. We would need to build in some backdoor with very high rank that determines the renderer that is chosen regardless of type.

The second approach appears to create a custom validation layer ourselves. This seems to be a nicer approach for testers but I have a few questions. In this scenario do we store our errors within the JsonForms state or manage it externally? Is there a HOC outside of the basic ones that injects some sort of addErrors function that we can use to inject a way to manually add errors inside our custom renderers? Is there any built in handling for things like clearing errors in this scenario? Or is it completely custom endeavor.

All in all any recommendations or sources of more information would be helpful to guide us in a decision. Is there any sort of middle ground here? Can we change what key AJV uses in the schema to determine the validator that is ran instead of type? Thanks in advance.

#2

Hi @kiwdahc,

This is an interesting use case. Generally speaking, at the moment it’s not so easy to mixin an additional validation strategy next to the one of AJV. However we’re looking at options to allow that at some point and maybe even add a generic middleware concept. What the best strategy is with the currently released JSON Forms depends heavily on the exact requirements.

An example of the types of random validations that would be made are: the first four characters must be ACBD , followed by seven numbers, followed by one character, and must end in a -0 . These types of validation rules are completely unknown to us before they are created

This is already covered by JSON Schema itself via the pattern validation. So you could just let the user specify this pattern attribute.

So the user would be putting in their own regex string and error message when this regex does not meet the value returned by the control.

The error message could be handled via ajv-errors. It allows to specify custom error messages within the JSON Schema. So in your case you would customize either the error message of the attribute generically or only for the pattern validation.

Using this approach has the advantage that it does not require any changes to JSON Forms besides handing over an AJV instance with ajv-errors support.

As far as I can tell by reading previous posts and questions there are two approaches to this. The first would be to create a new type for any field they create a validation for. Then we would inject the new rules for each type into JsonForms using AJV. In the example above the schema type for their input field would be something like type: membership-account-id or something. This seems like a straight forward approach and has the benefit of using the pre-packed validation. It seems to not play well with testers though. We would need to build in some backdoor with very high rank that determines the renderer that is chosen regardless of type.

There is something more straightforward than changing the whole type. You can simply add a custom sibling attribute via AJV’s keyword mechanism. So no need to touch the testers. This is also a feasible approach, however you will need to implement this custom validator, so users can’t do arbitrary validations but only patterns which you foresee.

The second approach appears to create a custom validation layer ourselves. This seems to be a nicer approach for testers but I have a few questions. In this scenario do we store our errors within the JsonForms state or manage it externally? Is there a HOC outside of the basic ones that injects some sort of addErrors function that we can use to inject a way to manually add errors inside our custom renderers? Is there any built in handling for things like clearing errors in this scenario? Or is it completely custom endeavor.

This is hard to comment as too much is unknown here. For example is it enough to show the error visually or does it also need to be emitted by the JSON Forms errors event? Where is the validation code actually running? Do you already have a complete own renderer set or do you mostly rely on the off-the-shelf renderers etc?

Generally speaking at the moment it’s quite some effort when customizing the error behavior without going through AJV. Via custom renderers and custom bindings any use case could be implemented though. Depending on the needs it could also be easier to wait or implement a generic middleware support, or even simpler just a way to mixin errors from the outside of the form.

Regarding your specific questions: There is a built-in way to manipulate the currently stored errors in JSON Forms by dispatching an update errors action, however the update data action, which is triggered on any input change, will overwrite them again, so it’s not as useful. Of course all of this is only necessary if you want to actually reuse the internal error storage. If just showing an error visually is enough a very simple set of custom renderers/bindings can take care of that.

To summarize: If the mentioned regex use cases are enough I have the impression that simply using the pattern validation plus ajv-errors is the way to go. If that does not apply you would need to share more information on the validation details, e.g. what can the user actually specify, where is the validation code executed and what are the consequences of a validation error.