Open chickencoding123 opened 2 years ago
Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.
Find more details about Angular's feature request process in our documentation.
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.
We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.
You can find more details about the feature request process in our documentation.
We agree that dynamic forms could use some love. We're marking this canonical since we know design work is needed here.
Which @angular/* package(s) are relevant/releated to the feature request?
forms
Description
Problem Currently the only way to add additional controls is by using methods such as the
addControl
onFormGroup
orinsert
onFormArray
. However this approach introduces a significant boilerplate for apps since they must entirely manage their own dynamic forms. These are reactive form objects that perform dynamic CRUD operations on their child controls. There's an abundance of issues in this repo that are rooted in lack of a managed solution for dynamic form, that is, a form that can auto-manage its children.FormBuilder
is a fantastic tool, but it lack automated CRUD operations for controls.Proposed solution
To address this we can extend the
FormBuilder
and add:AbstractControl
, reason is discussed further belowauto
onFormBuilder
which will take a schema and returns a dynamic form builder. This schema will mainly represent the structure of auto createdAbstractControl
including all the additional parameters required to initialize anAbstractControl
.So why not just write a standard recursive method called
auto
onFormBuilder
? This is actually a problem for a few reasons. Firstly there's the case of immediate subscriptions:This can break if the
auto
method hasn't created the control yet. So instead dynamic form builder (which is returned by theauto
) will output the proper error since it'll wrapvalueChange
with a_isCreated
check.Another issue is the data size. Passing an astronomical array data to create a dynamic
FormArray
can slow down the page which will only result in more issues to pop up in this repo. Instead we add a constraint to the dynamic form to restrict the amount of nodes that can go in theAbstractControl
tree and output a few suggestions to the developer such as to introduce pagination on their data array.What about the performance? As mentioned above we'll add constrains to the
auto
for these common cases, but the recursion itself is anO(n)
wheren
is the total number of nested keys in any given data object that's passed in.Alternatives considered
I'm open to alternatives, but I can't think of any