Expose title property for validated fields

[lazaromenezes]

Reasons for making this change

This exposes the title property on RJSFValidationError to allow further custom message formating.

Fixes #4504

In #4504 discussion is mentioned a rjsf-v6 branch that I couldn't find so I'm targeting main instead. If there's another branch I could retarget this PR please let me know.

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 npx nx run-many --target=build --exclude=@rjsf/docs && 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]

Thanks for the fix... can you add a unit test in utils to verify this fix? And update the CHANGELOG.md as well.

[lazaromenezes]

Sure! I'll try getting something done in the next few days.

[lazaromenezes]

Fixed some failing tests after my change and updated the changelog. Still thinking in the best way to make a specific test for the change.

[TheOneTheOnlyJJ]

As the author of #4504, I'm very thankful to see this being taken care of.

I have a single proposal/update here, which is also mentioned in #4504.

Would it be feasible to expose the entire uiOptions object of the incorrect field in its RJSFValidationError?
This way, custom error messages could also be based on information from other uiOptions, such as the description, help, label, emptyvalue, placeholder, etc. This would enable more complex use cases by allowing the creation of custom error messages based on any and every UI option the field has, not strictly limited to the title.
This is especially important when working with runtime dynamic JSON schemas (like my project does).
The title, if present, would be included in the uiOptions object, fixing #4504 as well, but in an even more elegant way, opening up even more possibilities.

With the ui:title being retrieved from uiOptions in this PR, could the parameters and typings of RJSFValidationError be updated to pass the entire uiOptions object instead of just the title?

[nickgros]

@TheOneTheOnlyJJ would it make sense to merge this, and later you (or @lazaromenezes, or another contributor) could enhance the object with the full uiOptions? Or should we wait for @lazaromenezes to weigh in on your request?

[lazaromenezes]

@nickgros if maintainers are okay with merging as it is I'm also okay and address uiOptions in a later pull request and put more work on the tests when exposing the full object.

[heath-freenome]

@nickgros if maintainers are okay with merging as it is I'm also okay and address uiOptions in a later pull request and put more work on the tests when exposing the full object.

The one hesitation I have is that, in adding support for the uiOptions, you will cause a breaking change if you transition from title to uiOptions.

[lazaromenezes]

@nickgros if maintainers are okay with merging as it is I'm also okay and address uiOptions in a later pull request and put more work on the tests when exposing the full object.

The one hesitation I have is that, in adding support for the uiOptions, you will cause a breaking change if you transition from title to uiOptions.

My original thought was adding uiOptions as an additional property instead of replacing title. If you think it makes more sense having a single new property, I can change it to be uiOptions this week.

[heath-freenome]

@nickgros if maintainers are okay with merging as it is I'm also okay and address uiOptions in a later pull request and put more work on the tests when exposing the full object.

The one hesitation I have is that, in adding support for the uiOptions, you will cause a breaking change if you transition from title to uiOptions.

My original thought was adding uiOptions as an additional property instead of replacing title. If you think it makes more sense having a single new property, I can change it to be uiOptions this week.

If that is the case, then I'm fine with this merging... Please rebase

[TheOneTheOnlyJJ]

But would it really make sense to expose both title and uiOptions separately, given that title is included in uiOptions?

It only makes sense when keeping into account that the title may come from the JSON schema and not exclusively from the UI Schema, but in this case, should't all the other options where this can be the case be treated the same way?

I hope I'm not unnecessarily delaying the work on this issue, but I'm just trying to keep into account all the details that may impact the usefulness of this feature, based on my experience with having no access to the title property.

[nickgros]

It only makes sense when keeping into account that the title may come from the JSON schema and not exclusively from the UI Schema

For this reason, I think it's a good idea to have a top-level title property.

[...] in this case, should't all the other options where this can be the case be treated the same way?

Those other options can be incrementally added to the top level as needed. I don't think it's harmful to also have the uiOptions.title available as well. I think the proposed API (hopefully) makes it obvious that that the uiOptions data exclusively comes from the uiSchema.

Let's merge this. @lazaromenezes thanks for the contribution and @TheOneTheOnlyJJ thanks for your input!