与功能请求相关的@angular/*包有哪些？
- 无响应*
描述
新的Angular版本会创建新的弃用，
我希望在Angular中看到一个标志系统！作为一名开发者，我经常挣扎于维护仍在工作但可能会在未来版本中被移除的已弃用或实验性功能。这就像是在一个没有明确出口路线的猫道上行走，让我对前进的最佳路径感到不确定。如果你从新的紧身衣服开始，一切都很好，但是旧的大件衣服就有问题了。
一个标志系统将赋予我明确选择退出这些功能并确保我的代码保持可维护性和未来兼容性的能力，让我能够在继续使用现有语法的同时，仍然有选择采用新语法的权利。
这种灵活性将极大地提高我的开发体验，使我能够平衡创新与稳定性，减少破坏性更改的风险。
你认为呢，Angular团队？能否为开发者添加一个标志系统，以便他们可以更好地控制自己项目的演进？
建议的解决方案
所有当前的弃用都将被移除
尽管在某些情况下这可能会带来问题，但我们可以在环境.ts设置中保留一些东西，比如旧式的路由守卫等。
然后，人们也可以选择启用一组特定的新语言特性
由于这位于项目级别，因此应特别注意导入，因为外部导入可能涉及不同的标志设置。
考虑过的其他方案
冻结语言，不再有弃用，但通过扩展模块来丰富语言。
5条答案
按热度按时间thigvfpy1#
你能详细解释一下你所说的旗子系统是什么意思吗？
作为替代方案，有tslint/eslint规则可以防止依赖已弃用的API。
inkz8wg92#
你需要的东西可能已经被 ngx-flagr 覆盖了。查看一下吧。
egmofgnx3#
嗯，我并不是想在我的项目中实施一个标志系统。
我说的是Angular本身的语言。
各种方法已经被弃用，有些甚至早在Angular 15之前就被弃用了。
尽管它们仍然可以工作，但不推荐使用。
尤其是对于大型项目，不容易进行更改。
因此，在长时间弃用之后，接受它们、保留它们并移除弃用标记。在可能的情况下修复它们，但不要打算移除它们。
当新的语言特性被开发出来时，将它们放在一个标志系统的后面。
这将允许进行beta测试、工作和调试代码，人们可以然后升级Angular,根据他们想要或不想要的未来特性，这样语言就可以成熟起来。
旧的Angular项目可以升级或获得修复，但保持一些有限的未来特性集。
Angular的问题在于，你可以构建它，但是在一个未来的基础之上构建它是有风险的，你永远不知道哪些会变得过时，而且这样的活动也会导致其他人的项目无法结束。所有依赖项目也需要与之合作，如果有一个开源库没有更新，你的代码就会出问题。
我们应该更多地思考如何让Angular获得稳定的生命周期，而不是花哨的新着装代码。我有工业自动化的背景，告诉一个核电站他们需要每两年更新一次软件，他们的一些代码将会被废弃，所以你需要为他们编写永远的代码。
这根本行不通。尽管浏览器会发生变化，但语言需要获得稳定性。
这不是一篇抱怨文章，而是对重新思考生命周期以及可能的解决方法的紧急呼吁，比如扩展导入注解。
63lcw9qa4#
你必须通过更好的设计和延迟实施新功能来减轻问题。对于重大更改，Angular通常会提供代码迁移，以便自动更新你的代码。
ngxtension也有一些迁移可以自动更新你的代码。为了使代码更易于维护，你可以采用
facade设计模式。你创建一个中间服务，调用第三方库的方法。你可以随时用另一个第三方库替换它。依赖于该服务的组件无需更新。你还可以考虑将组件拆分为表现层和容器组件。容器组件具有逻辑，你使用
input和output在组件之间传递数据。表现层组件仅渲染接收到的数据，当逻辑发生变化时无需触及它们。hgncfbus5#
关键是，由于这种语言不够健壮，与此相反，PLC结构化文本编码是一种NEN规范，它已经存在了数十年。没有保证的语言不能保证新未来的未来不会破坏，那么它应该被放在旗帜后面，因为这种语言本身在更新时不应该引起问题。这听起来可能很奇怪，但编码项目应该能够完成。而且不需要开发人员每两年关注一次新的LTS版本发布。实现这一点不需要任何技巧，因为没有规则说明哪个砖块会被标记为过时，甚至不可能使用技巧。使这种语言真正具有未来保障性，以便在未来的场景中使用。如果新的未来破坏了过去，将其放在旗帜后面，这样人们就可以选择不使用它。模块的好处将是一个里程碑式的改变者。
安卓Outlook下载< https://aka.ms/ghei36 >...