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
I don't think we want to restrict the types of forms inside indent or array, since we are nesting these in our specs forms currently (and it seems like it works fine and that they were intended to work that way, even).
Were you imagining restricting the types just to avoid making forms which look messy when rendered, or restricting types in order to ensure that the resulting editable table actually functions correctly? I'm not sure I'm a huge fan of restricting the forms in editableTable components either; I think the FormBuilder type probably has enough type parameters as-is, so if it's just to help avoid messy-looking forms I'm not sure I'd consider the type system to be appropriate for that.
@hdgarrood You might be right, because we can't stop users from wrapping any old component in a form and putting it into an editable table.
I'm more bothered by the flattening of Forest in EditableTable. It indicates to me that we should be able to generalize forms over the structure used to represent their nesting. The same thing also shows up in the validation API - adding a validator to a nested form requires us to walk down the tree to look for a leaf to attach the message to - but I think the better solution is to disallow validators on nested forms.
So we can't stop users from wrapping arbitrary rubbish in a FormBuilder and calling it primitive, but we can at least prevent misuse if you stick to the primitives we provide.
Currently there is no way of restricting the type of forms allowed inside certain compound
FormBuilder
s (e.g.indent
,array
,editableTable
see #1).It would be interesting to not allow indented forms inside some specific form builders.
The text was updated successfully, but these errors were encountered: