哪个@angular/*包是bug的来源？
forms
这是回归吗？
否
描述
请查看下面的stackblitz。
TL;DR 即使我们使用一个FormControl<number>,它的值也可能为null,仅仅是因为输入类型的CVA将值设置为null。
严格类型化的表单在提供类型保险方面并不一致，我认为。例如：
- 它们迫使我们在万一有人调用
reset()的情况下，仅仅为了以防万一，将值设置为null,除非我们明确使用选项initialValueIsDefault。尽管在我的经验中，调用reset()是非常罕见的。 - 它们迫使我们在表单组中具有可取消的值，以防有人禁用控件，从而使其值成为表单组的值的缺失。在我的经验中，禁用字段比调用
reset()更常见，但仍然相当罕见。
但是另一方面：
- 如果用于设置控件值的CVA将其设置为null(如stackblitz中的示例),它们根本不关心。在我的经验中，使用数字输入或带有默认空选项的选择框是非常常见的。在这种情况下，表单控件的不非空性是一个谎言。
我希望有更多的一致性：
- 或者表单非常谨慎，永远不让打字错误，但在这种情况下，使用
initialValueIsDefault选项初始化表单控件并具有非空初始值的表单控件应该检查其值是否从未被设置为null,如果是这样，则抛出异常(如提供的示例) - 或者表单应该将控件类型交给开发者：如果他们知道他们永远不会调用reset(),永远不会禁用控件，并且CVA永远不会将值设置为null,那么让他们选择他们想要的类型，如果他们搞砸了(基本上就是每次你执行
http.get<Something>()时发生的情况)
请提供一个最小重现bug的链接
请提供您看到的异常或错误
NA请提供您在此处发现此bug的环境(运行ng version)
Angular 14.0.0-rc.0还有其他吗？
- 无响应*
6条答案
按热度按时间qni6mghb1#
我意识到这确实相当复杂，因为一个人可能会做
new FormControl<null | number>(10, { initialValueIsDefault: true }),因此希望控制为可空，因此在这种情况下将值设置为null时抛出异常可能不正确。所以这可能不是决定的正确选项。因此，它可能需要另一个选项来解决这个问题...ltqd579y2#
你好，感谢你的反馈。
我们对表单类型的总体意图是尽可能严格(或者你可以说“偏执狂”)。目前，类型涵盖了来自TypeScript的所有
null和undefined可能性。然而，目前没有任何与
ControlValueAccessor的集成。这意味着这个问题实际上比 CVA 将控件设置为null要大得多——CVA 可以将控件设置为完全不相关类型的值！例如，你可以将一个FormControl<string>绑定到一个input type="number",并且不会有类型错误。这是我们打算在未来解决的问题——我们讨论过是否要等到 CVA 和模板类型检查集成就绪后再延迟这个功能，但我们决定不这样做。特别是，尽管模板类型不如 TypeScript 那么丰富，但我们应该能够在将来生成一些关于类型不对齐的警告。
P.S. 关于你关于禁用控件的评论——如果你不介意控件的禁用状态，我强烈建议你改用
.getRawValue()而不是.value!P.P.S. 如果你不设置
initialValueIsDefault,那么null将保留在你的数据类型中，如果 CVA 经常将控件设置为null,这确实会更安全一点。gopyfrb33#
这个功能请求现在已经成为我们的待办事项候选！在接下来的阶段，社区有60天的时间进行投票。如果请求获得超过20票的赞成，我们将把它移到我们的考虑列表中。
你可以在我们的文档中找到更多关于功能请求流程的详细信息。
x7rlezfr4#
(尽管Angular机器人像往常一样收集投票，但我们意识到这很重要，并且它已经列入了路线图)
iaqfqrcu5#
请注意，我们已经开始了针对您的功能请求的社区投票过程。距离投票过程结束还有20天。
有关Angular功能请求流程的更多详细信息，请参阅我们的文档。
5lwkijsr6#
感谢您提交您的功能请求！看起来在投票过程中，它没有收集到足够的票数进入下一阶段。
我们希望保持Angular丰富且符合人体工程学，同时关注其范围和学习过程。如果您认为您的请求可能超出了Angular的范围，我们鼓励您与community合作，将其发布为开源项目package。
您可以在我们的文档中找到有关功能请求过程的更多详细信息。