Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Radio component defaultValue changes to null after saving. Instead of the desired: "". #5104

Open
LaurensBurger opened this issue Feb 13, 2025 · 0 comments · May be fixed by #5123
Open

Radio component defaultValue changes to null after saving. Instead of the desired: "". #5104

LaurensBurger opened this issue Feb 13, 2025 · 0 comments · May be fixed by #5123
Assignees
Labels
needs-backport Fix must be backported to stable release branch owner: den-haag topic: form builder
Milestone

Comments

@LaurensBurger
Copy link
Collaborator

LaurensBurger commented Feb 13, 2025

Product versie / Product version

3.0.4

Customer reference

reported by: DH, hlm, Ensc

Omschrijf het probleem / Describe the bug

When you add a radio component to a step, the initial defaultValue is set to: "".
By saving the component the defaultValue gets changed to null.

The issue with null is when this radio is hidden with "empty when hidden" is enabled, the component is included in the check_logic as "radio": "", which in turn triggers validation for the step with no user interaction. Unfortunately this issue is pretty prevalent across environments.

After manually changing the null back to "" in the json of the radio component - this validation triggering is no longer an issue.

Image

Image

Verwacht gedrag / Expected behavior

i expect the defaultValue to not cause validation to trigger when a step loads

Screen resolution

None

Device

None

OS

None

Browser

No response

@LaurensBurger LaurensBurger added the triage Issue needs to be validated. Remove this label if the issue considered valid. label Feb 13, 2025
@joeribekker joeribekker added this to the Release 3.1.0 milestone Feb 24, 2025
@joeribekker joeribekker added needs-backport Fix must be backported to stable release branch owner: den-haag and removed triage Issue needs to be validated. Remove this label if the issue considered valid. labels Feb 24, 2025
@robinmolen robinmolen moved this from Todo to In Progress in Development Feb 26, 2025
robinmolen added a commit that referenced this issue Feb 26, 2025
The `FormioUtils.fastCloneDeep(component)` makes a new instance of the component (with a new unique id). For the most part this is okay, but when the `defaultValue` is set to a falsey value (like an empty string), the `defaultValue` from `FormioUtils.fastCloneDeep(component)` will be `null`.

For the bug #4659 this was solved by manually correcting the default value of textfield and email components from `null` to `''`. This corrected the problem for these components (and ensured that these components always have a valid default value), but didn't solve the problem for other components.

By merging `original` and `FormioUtils.fastCloneDeep(component)` into one object, we retain the original component configuration and give the `componentCopy` a unique id.
The id must be unique for proper cancelation functionality (if the id of `componentCopy` is the same as the original, an error will be thrown when you edit the component > cancel editing > edit it again)
@robinmolen robinmolen linked a pull request Feb 26, 2025 that will close this issue
10 tasks
robinmolen added a commit that referenced this issue Feb 26, 2025
The previous solution, derived from #4659, is no-longer needed.
- With the previous changes to the `WebformBuilder` (d64fd73) the correct defaultValue is used when editing a component.
- To ensure that the textfield components start with an empty string as `defaultValue`, we can just define it in the schema and point the `get defaultSchema()` to our own schema.

This also makes the textfield components more predictable. If for some reason you set the defaultValue to `null`, then this will be respected.
robinmolen added a commit that referenced this issue Feb 26, 2025
The previous solution, derived from #4659, is no-longer needed.
- With the previous changes to the `WebformBuilder` (d64fd73) the correct defaultValue is used when editing a component.
- To ensure that the textfield components start with an empty string as `defaultValue`, we can just define it in the schema and point the `get defaultSchema()` to our own schema.

This also makes the textfield components more predictable. If for some reason you set the defaultValue to `null`, then this will be respected.
@robinmolen robinmolen moved this from In Progress to Implemented in Development Feb 26, 2025
@robinmolen robinmolen moved this from Implemented to In Progress in Development Feb 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-backport Fix must be backported to stable release branch owner: den-haag topic: form builder
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

3 participants