ui:widget 'radio' generates random name attribute which leads to instable markup

[jan-bitgrip]

Prerequisites

• [✔] I have read the documentation;
• [✔] In the case of a bug report, I understand that providing a SSCCE example is tremendously useful to the maintainers.
• Ideally, I'm providing a sample JSFiddle or a shared playground link demonstrating the issue.

Description

The ui:widget 'radio' generates a radom name attribute.

See:
https://github.com/rjsf-team/react-jsonschema-form/blob/3ec17f1c0ff40401b7a99c5e9891ac2834a1e73f/packages/core/src/components/widgets/RadioWidget.js
Lines 17 and 18

On using automated tests based on snapshots and specially snapshot regression tests, this leads to an instable markup and to false positives.

Steps to Reproduce

1. Checkout the example in the documentation: https://react-jsonschema-form.readthedocs.io/en/latest/usage/widgets/#for-boolean-fields
2. Open the browser inspector
3. Inspect the yes/no radio toglle
4. You see the name attribute changing on every load and click

Expected behavior

The name attribute shpould be stable within a render and a rerender.

Actual behavior

The name attribute changes all the time on load and on click.

Suggestion

Instead of generation a random string, a hash value of incoming props could achieve the same goal (have a unique identifier for the radio list) but without being random.

Version

2.0.0-alpha.1

[jan-bitgrip]

As you have less or zero dependencies in this library, an option would be to add a hash function to create a unique hsh of a json object to the utils (/src/utils.js), e.g. like:

    var hash = 0;
    for (var i = 0; i < this.length; i++) {
        var character = this.charCodeAt(i);
        hash = ((hash<<5)-hash)+character;
        hash = hash & hash; // Convert to 32bit integer
    }
    return hash;
}```

Then in /src/components/widgets/RadioWidget.js the name could be generated as hash based on 'props' (including all props given).

[epicfaace]

I agree that a random name is non-ideal. We already have a unique identifier for the widget, which is the id passed in the props.

One option is to combine this id with some kind of hash based on the radio option value, but I don't think this option is ideal. What if someone changes the schema and renames an option? With this solution, the option name would change; but perhaps ideally we wouldn't want the option name to change at all once it has been assigned once.

The other option -- which would give the radio options stable values, even if they are renamed -- could be implemented similar to what we do for assigning stable keys for items in an array -- see https://github.com/rjsf-team/react-jsonschema-form/blob/master/packages/core/src/components/fields/ArrayField.js#L180

@jan-bitgrip do you want to give it a try in a PR?

[jan-bitgrip]

I can try - as far as resourcen let me - create a PR. Is it correct, that the code appears on several locations like the different packages? Or is there some kind of code generation behind?

[epicfaace]

I think it depends. Some logic is common and found in the rjsf/core packages, but other logic might be in other packages. As far as possible, it would be best if this sort of change only touches a single package, rjsf/core, if possible. Thanks for your help!

…

On Mon, Jul 5, 2021, 8:43 AM Jan ***@***.***> wrote: I can try - as far as resourcen let me - create a PR. Is it correct, that the code appears on several locations like the different packages? Or is there some kind of code generation behind? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2461 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM4MX34MEDBMSUW5VSTJB3TWGSITANCNFSM472Q6WTQ> .

[jan-bitgrip]

Thx.

[heath-freenome]

Fixed in the v5 beta, see the 5.x migration guide