You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
bhyman
changed the title
[Bug] Cannot change the enum options for a dropdown or radio based on another element
Cannot change the enum options for a dropdown or radio based on another element
Dec 21, 2020
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:
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.
The text was updated successfully, but these errors were encountered: