Fix: Better validation messages using schema/uiSchema title if it exists

[dagda1]

Reasons for making this change

Fixes #3246 by reimplementing #2634

• The ajv8 ErrorObject message is enhanced by replacing the error message field with either the uiSchema's ui:title field if one exists or the parentSchema title if one exists.

Checklist

• I'm updating documentation
  • I've checked the rendering of the Markdown text I've added
• I'm adding or updating code
  • I've added and/or updated tests. I've run npm run test:update to update snapshots, if needed.
  • I've updated docs if needed
  • I've updated the changelog with a description of the PR
• I'm adding a new feature
  • I've updated the playground with an example use of the feature

[heath-freenome]

Whoops, these have been sitting pending for days as I forgot to click submit, sorry

[heath-freenome]

@dagda1 Would you please revert the package-lock.json changes

[heath-freenome]

Finally, once this is merged, we will release 5.0.0

[dagda1]

@dagda1 Would you please revert the package-lock.json changes

oops, I think I might have a different version of npm than you. What version are you using.

I have reverted the files.

[heath-freenome]

@dagda1 Would you please revert the package-lock.json changes

oops, I think I might have a different version of npm than you. What version are you using.

I have reverted the files.

I'm using node 18 although node 16 also uses the same formats. I'm pushing a PR #3372 to bump the package-lock.json files using clean node_modules directories which is how new developers like you start out

[dagda1]

@heath-freenome I'm getting yellow lines in the coverage report because of the optional chaining around both message and parentSchema.

e.g.

message = message?.replace(currentProperty, uiSchemaTitle);

and

parentSchema?.[PROPERTIES_KEY]?.[currentProperty]?.title;

[dagda1]

@heath-freenome I am getting yellow lines in the coverage report around the optional chaining on message and parentSchema.

I notice the existing code does this with message

stack = message!;

This tells the typescript compiler that message will not be null or undefined. If this is the case, would it not make sense to make message in ErrorObject not optional?

And for parentSchema, do you know how I could be able to test it is undefined? The only way I can think is if transformRJSFValidationErrors was not private.

[heath-freenome]

@heath-freenome I am getting yellow lines in the coverage report around the optional chaining on message and parentSchema.

I notice the existing code does this with message

stack = message!;

This tells the typescript compiler that message will not be null or undefined. If this is the case, would it not make sense to make message in ErrorObject not optional?

ErrorObject comes from ajv and from all the testing it normally has a value so that's the reason for the !

And for parentSchema, do you know how I could be able to test it is undefined? The only way I can think is if transformRJSFValidationErrors was not private.

If you look up the top of validator.test.ts around line 16 you'll see how you can "expose" that function in a manner similar to how we exposed the private withIdRefPrefix so it could be tested for similar boundary conditions

[heath-freenome]

One last thing, don't forget to update the CHANGELOG.md similar to how it is done here

[heath-freenome]

One required and one optional change and then we can merge it!

[heath-freenome]

Ah... Sorry for being so picky, but a few more little things. I'd make them myself except I can't easily update the location of the import

[heath-freenome]

@dagda1 Thanks for all your hard work on this PR and dealing with the feedback. I'm just awaiting the final move of the import in the test then I will merge

[dagda1]

@dagda1 Thanks for all your hard work on this PR and dealing with the feedback. I'm just awaiting the final move of the import in the test then I will merge

the feedback was constructive so thank you for the good review