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

Do not use "default" values from schema to initialize the form and underlying data structure #2980

Closed
1 task done
TheRealJon opened this issue Aug 1, 2022 · 9 comments · Fixed by #3663
Closed
1 task done
Assignees
Labels
feature Is a feature request

Comments

@TheRealJon
Copy link
Contributor

Prerequisites

What theme are you using?

core

Is your feature request related to a problem? Please describe.

JSON Schema defines the "default" property as such:

The default keyword specifies a default value. This value is not used to fill in missing values during the validation process. Non-validation tools such as documentation generators or form generators may use this value to give hints to users about how to use a value. However, default is typically used to express that if a value is missing, then the value is semantically the same as if the value was present with the default value. The value of default should validate against the schema in which it resides, but that isn’t required.

The key here is that the "default is typically used to express that if a value is missing, then the value is semantically the same as if the value was present with the default value"

If a missing value is semantically the same as a present default value, then it is probably best to exclude it for the sake of simplicity. The client shouldn't be concerned with the schema default, except for informational purposes ("...give hints to users about how to use a value."). It's a fallback value used on the server-side when no value is provided by the client. As such the client doesn't need to provide it at all unless it is different from the default.

Describe the solution you'd like

Do not fill in the form fields or underlying data structure with "default" values from the JSON schema, or at the very least, make this an opt-in behavior.

Describe alternatives you've considered

We do not want rjsf-generated forms to be pre-filled with default values from the schema. As a workaround, I'm currently working on a solution that will ignore values that are equal to schema defaults. If that doesn't work, we might have to modify the schema itself and remove defaults before rendering the form, which is definitely not ideal.

@TheRealJon TheRealJon added feature Is a feature request needs triage Initial label given, to be assigned correct labels and assigned labels Aug 1, 2022
@heath-freenome
Copy link
Member

@TheRealJon would it be ok to have an opt-out behavior instead since switching it to an opt-in behavior would be a major breaking change?

@TheRealJon
Copy link
Contributor Author

Yes, I think the ideal solution would be opt-in (maybe in the next major release?), but even an opt-out option would be better than nothing in the meantime.

@heath-freenome
Copy link
Member

There won't be time to get an opt-in into the upcoming v5 beta, unless you want to submit the feature into the rjsf-v5 branch. Building an opt-out is faster and easier, but would likely arrive in a 5.x release given how busy I am wrapping up what I've already committed to.

@TheRealJon
Copy link
Contributor Author

TheRealJon commented Aug 3, 2022

I might be able to contribute an opt-out solution, it just depends on how quickly I can get spun up on the repo and if I have the bandwidth.

@heath-freenome heath-freenome removed the needs triage Initial label given, to be assigned correct labels and assigned label Aug 24, 2022
@heath-freenome
Copy link
Member

@TheRealJon Feel free to join the Friday meetings to discuss a way to potentially provide the opt-out solution in the v5 beta

heath-freenome added a commit to heath-freenome/react-jsonschema-form that referenced this issue Jan 25, 2023
Fixes: rjsf-team#2691 better by providing an opt-out behavior for the automatic wrapping of fields by anyOf/oneOf components

The original fix (rjsf-team#2980) to never wrap components is a breaking change from 4.x and could cause existing users problems.
This new fix provides the opt-out instead thereby reversing the breaking change

- In `@rjsf/utils`, updated just the `UiSchema` type to add the new `ui:fieldReplacesAnyOrOneOf` flag
- In `@rjsf/core`, updated `SchemaField` to only skip wrapping a custom field in the `anyOf`/`oneOf` if the `ui:fieldReplacesAnyOrOneOf` is true along with there being a custom field
  - Updated/added tests to verify the fix
- Updated the `uiSchema` documentation to include `ui:fieldReplacesAnyOrOneOf`
- Updated the `CHANGELOG.md` accordingly
heath-freenome added a commit to heath-freenome/react-jsonschema-form that referenced this issue Jan 25, 2023
Fixes: rjsf-team#2691 better by providing an opt-out behavior for the automatic wrapping of fields by anyOf/oneOf components

The original fix (rjsf-team#2980) to never wrap components is a breaking change from 4.x and could cause existing users problems.
This new fix provides the opt-out instead thereby reversing the breaking change

- In `@rjsf/utils`, updated just the `UiSchema` type to add the new `ui:fieldReplacesAnyOrOneOf` flag
- In `@rjsf/core`, updated `SchemaField` to only skip wrapping a custom field in the `anyOf`/`oneOf` if the `ui:fieldReplacesAnyOrOneOf` is true along with there being a custom field
  - Updated/added tests to verify the fix
- Updated the `uiSchema` documentation to include `ui:fieldReplacesAnyOrOneOf`
- Updated the `CHANGELOG.md` accordingly
heath-freenome added a commit that referenced this issue Jan 26, 2023
* Fix: 2691 with an opt-out for custom fields for anyOf/oneOf
Fixes: #2691 better by providing an opt-out behavior for the automatic wrapping of fields by anyOf/oneOf components

The original fix (#2980) to never wrap components is a breaking change from 4.x and could cause existing users problems.
This new fix provides the opt-out instead thereby reversing the breaking change

- In `@rjsf/utils`, updated just the `UiSchema` type to add the new `ui:fieldReplacesAnyOrOneOf` flag
- In `@rjsf/core`, updated `SchemaField` to only skip wrapping a custom field in the `anyOf`/`oneOf` if the `ui:fieldReplacesAnyOrOneOf` is true along with there being a custom field
  - Updated/added tests to verify the fix
- Updated the `uiSchema` documentation to include `ui:fieldReplacesAnyOrOneOf`
- Updated the `CHANGELOG.md` accordingly

* - Responded to reviewer feedback
@nickgros nickgros linked a pull request May 12, 2023 that will close this issue
8 tasks
@nickgros
Copy link
Contributor

#3663 should at least partially address this with an experimental fix in 5.X. We'd plan to remove the experimental prefix in v6.0

@TheRealJon
Copy link
Contributor Author

TheRealJon commented May 15, 2023

@nickgros Is it possible to keep this open until the current "pre-fill" behavior is opt-in rather than opt-out? Opting out provides a workaround, but the default behavior still doesn't semantically match what the JSON schema spec describes for "default" fields.

@nickgros
Copy link
Contributor

nickgros commented May 15, 2023

@TheRealJon I think we have that covered in #3664 (which is slated to be addressed in v6), I'll add a note to that issue to clarify that the default behavior should change to more closely match the JSON Schema spec

@TheRealJon
Copy link
Contributor Author

Great, I think that works!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Is a feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants