最近在角度社区中，关于即将发生的变化对角反应性原始的成本和含义的讨论。
很多人可以看到光明的未来，但随着时间的流逝，越来越多的开发人员开始注意到潜在的陷阱。 Angular团队具有高度反应性，并根据社区反应来适应愿景。
SUB-RFC 3：基于信号的组件 - 关注
Florian Spier在Sub-RFC 3中开始非常有趣的讨论。
我真的很害怕看到所有混合所有内容的应用：信号API，旧的API与装饰器，混合观察物和信号
这是关键部分，您可以在Sub-RFC 3 Discussion部分中看到更多详细的想法。
基于这个非常有趣的讨论进行了涉及角核团队成员。
信号API集成的三个选项
在讨论中， Andrew Scott（Angular Core Team）提出了三个集成信号API的选项：
-
保留当前基于装饰的语法以兼容。
-
过渡到新的语法，但保持向后兼容。
-
完全拥抱新的语法和模式，无视旧语法。
选项1：最小变化
@Input({alias, required, initial: X}) prop!: Signal<string|undefined>;
选项2：介于两者之间
@Input({alias}) prop = input('', {required});
@ViewChild() vc = viewChild('x', {read: ViewContainerRef});
选项3：RFC建议
prop = input('', {alias, required});
vc = viewChild('x', {read: ViewContainerRef});
讨论中的开发人员主要偏爱选项3 ，这强调了为新API做出正确选择而不是紧贴旧模式的重要性。这将使我们更加避免避免在我们混合进场时可能会发生的混乱。
关注信号API
尽管基于上述 Andrew Scott 的反应产生了普遍的兴奋。
-
信号与现有角概念之间的潜在混淆的可能性
-
编写简洁文档来指导开发人员
-
信号可能会导致更多的问题。
Angular's常绿途径
应对这些问题， Alex Rickabaugh（Angular Core Team）强调，Angular应该努力成为常绿的框架，不断发展以结合新的思想和技术。 这种方法可确保现有的角度开发人员可以从改进中受益，而无需昂贵且耗时的重写。
这里的目标非常好。通过实现该框架最终可以通过其核心解决方案稳定。
新老式和新API之间的兼容性
Alex Rickabaugh 解释说，新老式和新API之间的兼容性是Angular团队的重中之重。 现有的组件和指令将与新的基于信号的组件一起使用，反之亦然，这清除了社区中的许多混乱。
但是，两种类型的组件之间的语法和内部生命周期函数可能会有所不同。
信号API的批判性反射
Florian Spier要求Angular团队批判性地检查引入信号API的风险和好处。 提出的问题包括它是否可以解决比原因更多的问题，如果完全接受RXJ是一个更好的替代方案，或者是否有可能在使用RXJS保持一致的公共API的同时使信号成为内部实现。
我们需要拭目以待，看看所有这些如何展开
我们必须仔细观察并使用讨论参与即将来临的更改。 Angular Team 非常机敏，欢迎我们的投入。
尽管许多人对潜在的改进感到兴奋 - 对兼容性的担忧持续存在。 Angular团队将需要仔细考虑引入信号的含义，并确保新的API受益于开发人员而不会对现有生态系统造成不必要的破坏。