我没有几个表单可以创建/更新资源(例如,员工资源),这些资源根据所选类型略有不同。请建议以下哪一种方案我应该考虑?
1.独立组件:
对于每种类型,都会添加重复/额外的工作,并且需要在新表单的初始版本很少之后进行代码更改。
2.可重用组件:
我尝试了可重用组件,但是基于类型的不同字段的管理变得越来越复杂,表单中的输入字段很少,需要基于某些搜索文本的用户选择,并基于API调用填充下拉列表。例如,根据员工的几个字符选择员工,并根据搜索文本执行API查找。
利用formArray、formGroup创建独立的表单,并为不同的输入字段创建独立的组件,并重用这些组件。创建一个配置,将类型映射到相应的输入字段和一些元数据,如必需的、可搜索的、可选择的等等。
3.具有提取表单和逻辑的泛型组件:
在此选项中,角创建表单容器,并根据选定的类型从外部存储中提取特定的表单文件。该文件具有jQuery函数,它更新由角创建的表单容器,并添加实际的表单内容,如html (输入字段、选择选项、复选框等)、样式(针对每个html元素)、操作(基于字段类型的API调用)。因此,任何新的表单添加只需要在外部存储中创建新的jQuery文件。该选项在一定程度上实现了控制的抽象/反转。
从领域的角度来看,角度应用程序是从第三方创建/更新不同应用程序的资源,这些应用程序没有UI,或者UI很差,很难完全替换。因此,这些表格属于外部应用程序。
我的偏好是2->1->3
发布于 2021-12-30 10:45:10
第一个想法是:
我要区分抽象级别:
我将尝试创建可重用的表单组件。它们可以处理特定的API调用--如果有必要,也可以处理可重用的<address-component>。
然后,我将为不同的用例/视图使用单独的组件。
有一个大视图组件负责不同的使用-用例可能很快变成一个混乱,海事组织。
再想一想:
如果您已经知道将来会有1000多个不同的视图,我将尝试使用ngx-formly和自定义模板的完全动态解决方案。
第三种想法:
我总是喜欢引用令人敬畏的桑迪·梅茨,在这种情况下:
复制比错误的抽象要便宜得多。
因此,如果您不确定,我将从复制开始,因为随着时间的推移,您将识别(基于复制)哪些用例可以抽象,哪些不能。
https://stackoverflow.com/questions/70529319
复制相似问题