`patternProperties` invalid regex keys' behaviour is unintuitive to the user

[TheOneTheOnlyJJ]

Prerequisites

• [x] I have searched the existing issues
• [x] I understand that providing a SSCCE example is tremendously useful to the maintainers.
• [x] I have read the documentation
• [ ] Ideally, I'm providing a sample JSFiddle, Codesandbox.io or preferably a shared playground link demonstrating the issue.

What theme are you using?

core

Version

6.0.0-beta.8

Current Behavior

~~If a patternProperty with a key length of 1 is introduced, the Form does not display any input field for the value. Like this, from the playground:~~

~~This applies to all themes.~~

I opened this issue thinking that keys of length 1 were not handled correctly by the library. Upon closer inspection and playing around, I realised this is not the case. My keys did not match the regex required by patternProperties, thus not displaying a value input field.

This is very unintuitive. I would not expect a user to be aware of the regex not matching just by the absence of the value input field (I clearly was not). A proper error should be rendered in the key name field.

Expected Behavior

~~A value field is rendered no matter the key length.~~

It should be clear that the key name does not match the patternProperties regex when such is the case.

Steps To Reproduce

1. Go to the playground patternProperties example.
2. Add a new key of length 1, or any key that does not match the patternProperties regex.
3. Observe how the value input field does not get rendered.
4. Notice how, as a user, you have no feedback for why the value input field is not rendered.

Environment

Irrelevant

Anything else?

No response

[nickgros]

@GlassOfWhiskey Since you added the patternProperties feature, would you like to weigh in on this proposed UX enhancement?

[GlassOfWhiskey]

Hi @nickgros, the patternProperties definition is not only a red/green semaphore. Multiple patternProperties definitions can be combined together, and even augment some of the standard properties of the parent object. Therefore, this kind of message should probably be something configured by the user, e.g., in the uiSchema.

[GlassOfWhiskey]

Another option is to display a message only if the key does not match ANY of the patternProperties regular expressions

[GlassOfWhiskey]

The blank field derives from the fact that a null type is assigned to the property whenever it does not match any of the patternProperties definitions:

https://github.com/rjsf-team/react-jsonschema-form/blob/b5b95514eb7fee693b5bc603cd71be4dd2f4b463/packages/utils/src/schema/retrieveSchema.ts#L472-L473

If I simply omit the type by deleting line 473, this is the result:

If this is the desired behavior, I can proceed opening a PR.

[TheOneTheOnlyJJ]

Hmm, exposing variable names and internal error messages like this to the user is not good for UX. The way the message is formatted looks good layout-wise, but for a non-developer, this does not mean much, right?

How many error causes can there be in these fields? Are there multiple, or is this the only one? We could have fixed messages such as "Given key does not match the required format" or something similar, mapped to the different error types. If only one error type (the one in the image) is ever possible on these fields, we could have a single fixed error message. Exposing the key value may be useful for the error message, and allowing the error messages to be changed for custom reasons or i18n is also something that would be welcome. I'm not sure how one could go about this, though.

@nickgros Any thoughts?

[x0k]

I ran into the same issue while developing my own library, and here’s the solution I came up with:

0. By default, the behavior remains the same as described in the issue
1. Allow the user to override the function that generates the new key (so the key can match a desired pattern)
2. Allow the user to add a validateAdditionalPropertyKey method to the validator, which is called before the field is renamed source

demo