Inconsistent `ui:title` behavior

[markgreenburg]

Is your feature request related to a problem? Please describe.
Different fields accept different things for the ui:title uiSchema property.

Describe the solution you'd like

• All fields (ObjectField, StringField, etc.) have consistent ui:title behavior
• All fields accept a function for ui:title, with access to formData at least
• Should these points also be true for ui:description?

Describe alternatives you've considered

• Creating a custom field to replicate base fields with slight modifications in handling of ui:title

Additional context

• Sometimes, it's desirable to include form data within a question's title. This is possible if using ObjectField or ArrayField (or maybe even the BooleanField as long as it's using a radio widget?), but not possible with some other field type (e.g., StringField). This seems somewhat arbitrary and might not be that hard to change.

Implementation Thoughts
Seems as though to fix this, we'd need to:
1.) Update the conditional rendering logic in FieldTemplate
2.) Update the StringField to be capable of handling its own ui:title

Does that seem about right?

[dmethvin-gov]

So I think I can see situations where this would be handy, but just to be certain can you give some examples? Would you only want the form data, or would you also want other things like the title or validation criteria from other fields?

This has i18n implications but I can imagine needing something similar for i18n anyway so it's not clearly pro or con in that aspect.

I'm more concerned that these functions have access to all data on the form and thus require unoptimizable global recalc on a change anywhere on the form. Since that's already the case in 1.x it's not making things worse, but as I mentioned in #224 I'd like to explore ways to avoid this for 2.0.

[markgreenburg]

Sure thing - we recently had a page with a type: 'string' schema property that needed a title of
Please briefly describe how {other disability selected} caused your new disability.
Where the other disability selected was something that the user typed in on a previous page. Given that in this case we're asking people to add disabilities to other disabilities, the wording gets really tricky without specifically calling out the disability you're talking about.

Oh and just to clarify, this is possible to do depending on what field type you use. I'm advocating for consistent treatment across all the included field types.

As to accessing things outside the form data itself, I'm not sure - I could see use-cases there but we don't have one right this moment.

[dmethvin-gov]

I think we're consistent here, it's just that RJSF used (and now has visited upon us) the ambiguous term title or ui:title for what HTML calls either a <fieldset><legend> or a <label>.

The ObjectField has special-case code to let you change what becomes the <legend>, and because an ArrayField usually consists of ObjectFields you get that feature on arrays as well.

All the standard form fields go through RJSF's SchemaField which doesn't provide a way to have a <label> be a React component. So I think allowing custom React components for a label would require us to copy SchemaField and do the whole thing of passing it stuff including formData via props.

Stepping away from the implementation for a minute, does this feature end up being a good UX? I can imagine multiple instances of the same disability (knee injury, drug rehab, etc.) that someone might have and asking a question about something answered several pages earlier isn't ideal. If it's always in the context of the current set of disability questions then it seems like a page title would be enough.