Discovery on using different schema validator

A request came in from a potential user about wanting to use a different schema validator because the one we're using validates against an older draft of JSON Schema, which doesn't include all of the features they want to use.

Our library, as well as our fork of Mozilla's rjsf, uses jsonschema as our validator.

The original Mozilla rjsf library uses ajv as their validator.

ajv looks to be one of the most common JSON Schema validator library, and is probably more up to date and thorough than jsonschema. However, it is also a lot larger: minified version of jsonschema is 20kb, whereas minified version of ajv is 113kb. This is one of the reasons Vets.gov forked rjsf is because the move to using ajv from jsonschema added unnecessary bloat.

However, it looks like it would be relatively easy to swap out the validator library used. There is only one entry point for the validator in USFS: https://github.com/usds/us-forms-system/blob/master/src/js/validation.js#L189. This isValidForm function is used in the SubmitController at the very end of the form when submitting.

There is also one entry point for the validator in our fork of rjsf: https://github.com/department-of-veterans-affairs/react-jsonschema-form/blob/master/src/validate.js#L100. This validateFormData is used only in the Form component of rjsf, which USFS uses. This validation is run each time a page is submitted.

I'm not sure exactly how we could swap out the validator library; we could do what we've done in other places where we've added a key to the config that allows the user to overwrite specific functions or features, but not sure if we should keep doing that in every case of customization because it could make the config extremely complex and long. But there may be benefits in keeping all configuration in one object, so... not sure how to weigh these pro/cons. Very eager to hear thoughts on this below!

Inside USFS we have what looks like some error decoding logic that may be specific to the JSON Schema library:

us-forms-system/src/js/validation.js

Lines 62 to 81 in a56896f

    
           export function transformErrors(errors, uiSchema) { 
        
             const newErrors = errors.map(error => { 
        
               if (error.name === 'required') { 
        
                 const path = `${error.property}.${error.argument}`; 
        
                 return _.assign(error, { 
        
                   property: path, 
        
                   message: getMessage(path, error.name, uiSchema, error.argument) 
        
                 }); 
        
               } 
        
               const newMessage = getMessage(error.property, error.name, uiSchema, error.argument); 
        
               if (newMessage) { 
        
                 return _.set('message', newMessage, error); 
        
               } 
        
               return error; 
        
             }); 
        
             return newErrors; 
        
           }

It may be that ajv and jsonschema use the same format for errors, I haven't looked. If not, transformErrors would need to change based on the library in use. This is another case of things not being well encapsulated since USFS does not have either JSON Schema library listed as a dependency--RJSF does--and USFS is assuming a specific error format in transformErrors.

The thing that strikes me in validation.js is that we're essentially implementing two error processing systems, one to translate the schema parser returns and another to do the validation extensions we've added through uiSchema. It seems like the ones implemented by the schema parser are the trivial ones like min/max, pattern, etc. that we could easily do ourselves.

One way around the bundle size of ajv is to precompile a schema into a validator function and bundle just that. See ajv-cli compile, ajv-pack, and ajv-pack-loader for some methods of doing that.

I think we are modifying the schema at runtime and only validate the currently visible page in most cases until we can finally do a full validation just before submit. I'm not sure we can precompile the schema for that reason, at least as long as we have this design.

Just confirming that most of the functions in helpers.js change parts of the schema at runtime, so we can't precompile.

This would be a rather big change and there wasn't a specific need demonstrated for it anyway, so I'll close the ticket.

	export function transformErrors(errors, uiSchema) {
	const newErrors = errors.map(error => {
	if (error.name === 'required') {
	const path = `${error.property}.${error.argument}`;
	return _.assign(error, {
	property: path,
	message: getMessage(path, error.name, uiSchema, error.argument)
	});
	}

	const newMessage = getMessage(error.property, error.name, uiSchema, error.argument);
	if (newMessage) {
	return _.set('message', newMessage, error);
	}

	return error;
	});

	return newErrors;
	}