Description
If there is a dropdown or a radio input type, the possible options are fixed. One possible use case is where we want to change the options based on the value of another element. Ex: if the country is U.S., could have one set of options for “State”, but if the country is Canada, different set of options. Right now, you need to create a whole new element, but would be nice to change the options in the same element.
If this is not possible, then when the form builder detects schema trying to do this, it should throw an error or raise a warning somewhere.
Suggested Approach:
This issue is likely related to #8.
It ultimately stems from the fact that the “value based dependency” is ultimately an abstraction and simplification of the true oneOf dependency that it is based on. Right now, in src/formBuilder/utils.js, the issue is likely coming up with this if statement:
if (!Object.keys(elementDict).includes(parameter)) {
elementDict[parameter] = {};
elementCount += 1;
}
the elementDict is populated with form elements that the form builder has already “seen”. Therefore, when a child is marked as a dependent twice, it will appear twice in the dataSchema’s corresponding dependency, however, it will only be parsed the first time (the second time around, the if statement will resolve to false).
For this issue and #8, it may be necessary to raise a warning to the user if the schema detects that an element that appears in the dependency section appears in more than one dependency possibility.
This should avoid doing the same with “base” elements that exist in the root properties section, because we actually do support, and expect, those elements to appear multiple times (for example, a dropdown that renders things differently based on the value should and does appropriately appear in multiple dependency possibilities). As such, in the copied statement, instead of
elementDict[parameter] = {};
we should store this key value pairing in a different hash table, to handle those cases differently.