与特性请求相关的@angular/*包有哪些？

forms

描述

问题

目前，添加额外控件的唯一方法是使用诸如 addControl 在 FormGroup 或 insert 在 FormArray 上的方法。然而，这种方法为应用程序引入了显著的样板代码，因为它们必须完全管理自己的动态表单。这些是响应式表单对象，它们在其子控件上执行动态CRUD操作。此仓库中存在许多源于缺乏动态表单管理解决方案的问题，即可以自动管理其子项的表单。FormBuilder 是一个出色的工具，但它缺乏对控件的自动化CRUD操作。

建议的解决方案

为了解决这个问题，我们可以扩展 FormBuilder 并添加：

1. 一个动态表单对象， Package AbstractControl,原因如下文进一步讨论
2. 在 FormBuilder 上添加额外的方法 auto,该方法将接受一个模式并返回一个动态表单构建器。此模式主要表示自动创建的 AbstractControl 的结构，包括初始化 AbstractControl 所需的所有附加参数。

// data can be primitives or complex objects that adhere to the schema
type DynamicFormBuilder = (data: any) => AbstractControl
auto(DynamicFormSchema schema): DynamicFormBuilder

那么为什么不直接在 FormBuilder 上编写一个名为 auto 的标准递归方法呢？

这实际上有几个原因。首先是即时订阅的问题：

// common code in angular apps, won't work for a raw dynamic solution
const fb = new FormBuilder()
const control = fb.auto({})
const valueChanges$ = control.valueChanges.subscribe((value) => {/** Some operation */})

如果 auto 方法尚未创建控件，这可能会中断。因此，动态表单构建器(由 auto 返回)将输出适当的错误，因为它将用 _isCreated Package valueChange。

_isCreated: boolean = false
create(value: any) {
  // check constrains, if any E.g. node count
  // now do the recursion
  this._isCreated = true
}

valueChanges(fn) {
  if(!this._isCreated) throw Error('Control has not been initialized yet')
  /** */
}

另一个问题是数据大小。将天文数字般的数组数据传递给创建动态 FormArray 可能会使页面变慢，这只会导致此仓库中出现更多问题。相反，我们会向动态表单添加约束，以限制可以放入 AbstractControl 树中的节点数量，并向开发人员提供一些建议，例如在他们的数据数组上引入分页功能。

性能如何？

如上所述，我们将向 auto 添加约束以处理这些常见情况，但递归本身是一个 O(n),其中 n 是传递给它的任何给定数据对象中的嵌套键的总数。

考虑过的替代方案

我愿意考虑其他方案，但我想不出任何