-
Notifications
You must be signed in to change notification settings - Fork 27
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
Labels
Milestone
Comments
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
added a commit
that referenced
this issue
Feb 26, 2025
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
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.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
The text was updated successfully, but these errors were encountered: