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

Object defaults for "additionalProperties" result in rows that cannot be deleted and have side effects when modified #3759

Open
4 tasks done
dd12440 opened this issue Jul 10, 2023 · 6 comments

Comments

@dd12440
Copy link

dd12440 commented Jul 10, 2023

Prerequisites

What theme are you using?

mui

Version

5.9.0

Current Behavior

For an object type, default values are seemingly assumed to map to "properties" rather than "additionalProperties," or at the very least, mapping them to "additionalProperties" does not seem to work as expected. Take the following JSONSchema example:

{
  "title": "Test Defaults",
  "default": {
    "test-key": "test-value"
  },
  "description": "A simple form with additional properties example.",
  "type": "object",
  "additionalProperties": {
    "type": "string"
  }
}

As the linked playground shows, when the form renders, it does render with an entry matching the "test-key" entry in the default. However, the following issues are present:

  1. It is not possible to delete the entry (despite it being an "additional" property)
  2. Changing the key and blurring results in additional rows being generated
  3. The initial key remains in formData but does not appear in the form anymore

Expected Behavior

Any object key specified within the default object should be understood to be an "additional" property if it does not match some property specified in "properties". Thus, the following conditions would hold:

  1. The entry would appear as it currently does
  2. The entry could be deleted
  3. The entry could have its key changed with no side effects e.g. generating additional rows

Steps To Reproduce

  1. View the shared playground here.
  2. Attempt to delete the defaulted row and observe that it is not possible
  3. Change "test-key" to "test-key2" and blur; observe the newly created row

Environment

Shared playground

Anything else?

No response

@dd12440 dd12440 added bug needs triage Initial label given, to be assigned correct labels and assigned labels Jul 10, 2023
@heath-freenome heath-freenome added help wanted additionalProperties and removed needs triage Initial label given, to be assigned correct labels and assigned labels Jul 14, 2023
@heath-freenome
Copy link
Member

@dd12440 Wow! great bug find. Given how little time us few maintainers get to spend on the project (we volunteer a few hours a week generally), we could really use some help fixing this. Is this something you can help us with?

@dd12440
Copy link
Author

dd12440 commented Aug 29, 2023

@heath-freenome, I'm going to plan to try to find time to prioritize this. With that said, if anyone else is experiencing this issue and is motivated to address it, then there will be no complaints from me.

@heath-freenome
Copy link
Member

@dd12440 that would be awesome

@HanJaeJoon
Copy link
Contributor

HanJaeJoon commented Apr 26, 2024

if (isObject(formData)) {
return mergeDefaultsWithFormData<T>(defaults as T, formData, mergeExtraDefaults);
}

When the above code called immediately after changing the form, the formData value come as { test-key1: 'test-value' }.
But default value ({ "test-key": "test-value" }) is still in defaults.
The result of merging the two values (formData and defaults) is {test-key: 'test-value', test-key1: 'test-value'}.

HanJaeJoon pushed a commit to HanJaeJoon/react-jsonschema-form that referenced this issue May 3, 2024
@Piotr-Debicki
Copy link

Any update on this? I just ran into the same issue. Looks like onChange is regenerating the defaults and merging them every time something changes (edit/remove). Is that expected behavior?

@dd12440
Copy link
Author

dd12440 commented Jun 7, 2024

My only update here is that I have not and (unfortunately) do not expect to be able to work on this in the foreseeable future. If someone else has time, this would certainly be a major improvement to the library.

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

No branches or pull requests

4 participants