Open Abhishek-kumar09 opened 1 year ago
Thoughts? // @heath-freenome
What you want may be possible with a custom field.
I've built something like this for a similar use case (link), but I don't think it's a 1:1 fit--in my case I added a field to additionalProperties
where the user can select the data type (e.g. string, boolean, date) that they will enter in the field.
If I'm understanding correctly, maybe you could have a custom field or widget for x-kubernetes-preserve-unknown-field
where the rendered widget is a textbox. Maybe you could perform local validation (NOT through ajv) to ensure the input can be parsed (or is an object, etc.) and call onChange
with the serialized JSON object when the field is valid JSON.
Prerequisites
What theme are you using?
material-ui
What is your question?
We are currently developing our product using RJSF (React JSON Schema Form), and our project involves handling dynamically generated openAPI schemas from Kubernetes. In a specific use case, we encounter fields that are not compliant with RJSF/JSF standards. These fields are commonly referred to as
x-kubernetes
fields, indicating that they extend the Kubernetes schema.One such field is
x-kubernetes-preserve-unknown-field
. This field can accommodate various data types, preferably objects with one or multiple levels of nesting. However, we face the following issue:There is currently no field type that can accept an object of any schema. The
additionalProperties
attribute can only handle key-value pairs at most.To allow users to modify this field, we provide them with a multiline text box. Nonetheless, the data for this field should ideally be represented as a
json object
in the form data, rather than a multiline string.Is there a way to define a custom field type in RJSF that applies a transformation function on that key's value before saving it into the form data? This transformation function would automatically convert the provided data into an object and store it within the form data.
While we have considered an approach, it appears to be quite lengthy, and some team members are concerned about potential future issues. The proposed approach involves schema validation and mapping the form data to the schema that requires this transformation behavior. With the interchangeability of draft-04 and draft-07 schemas, there might be difficulties in the future when locating the correct data with respect to the provided schema. We are wondering whether RJSF already has built-in support for handling such cases. Any insight or suggestion would help us move faster.