与模块联合会，NX和REACT的现代化-DEV365 开发者社区

介绍

许多组织都在谈论他们如何发起现代化的努力，但是似乎有些组织正在努力进行反应18。 p>

有一种现代化策略可以帮助过渡而不会引起干扰。

除了基本事实15和16不再收到React团队的安全补丁以外，组织应该升级React 18的原因有几个原因。

性能，随着每个新版本的反应，性能都会提高。用户要求更多的s饮，此外，对于许多组织而言，SEO变得越来越重要。绩效增长及其可能产生的收入是一个巨大的驱动因素。
开发人员的生产力，超出当前的主要版本，导致维护第三方软件包的可用性大大减少。大多数大型OSS图书馆都支持N-1（当前主要版本减去一个），因此，当团队超出该范围之外的那一刻，他们冒着被弃用的风险，不得不自行支持该包。
新功能，对于使用SSR的组织特别是React 18随附的服务器端悬念是对代码复杂性的性能和降低的真正提升。

我们与之合作的大多数组织都是相当大的企业。他们的发展工作通常由多个团队，多个积压以及有时是竞争的优先事项组成。尝试着陆复杂的升级仅需在协调方面就需要大量的努力。这也对整体交付速度产生了影响，因为它分散了功能工作的注意力。

我们需要以：

的方式工作

虽然本文中提到的主要堆栈是反应的，但重要的是要提及模块联合可以与其他前端堆栈一起使用。 Angular，Next.js，在移动中以及与Nestjs的节点或节点的反应性和nativescript一起移动。

开始涉及前端开发的现代化工作时，在现代化工作中，Valor软件的餐桌赌注之一是使用NX。

在与组织合作时，经常有无证件要求，整个组织中散布的配置，或者只是高度重复的样板。我们在组织中要做的第一件事是根据当前的架构最佳实践来创建一系列发电机。

eslint配置，docker构成配置，声纳立方体，无论他们使用什么，我们都会将其包装成一个不错的企业工作空间生成器，适合其特定需求。

具有组织的一致性，尤其是在现代化努力开始时，有助于稍后缓解采用曲线。

改变方法论本质上是具有挑战性的，而许多开发人员将能够快速采用，而其他开发人员从拥有护栏中受益匪浅。编纂现有的架构最佳实践使组织可以了解人们如何随着时间的流逝而发展。

通常，组织有自己的精品店，它们已经建立了应用程序体系结构生态系统的技术组合。使用React 16与可加载组件的组织，Apollo客户端所有需要SSR并由酶测试支持并使用Make构建的组织将有一些冒险转移到React 18，原因多种原因。

创建增量演示使团队可以从工作参考体系结构开始。这些演示从遵循当前的组织标准开始，并具有其所有利基复杂性。一旦NX Workspace能够正确生成该参考体系结构，现在，组织将在平台演化的下一个阶段都有其起点。

nx再次在可以生成参考体系结构之后的方面再次发光，迁移也可以。在大多数情况下，将模块联合添加到React应用程序中所需的更改是已知数量。还知道要添加哪些配置，添加它们的位置以及以后要测试的内容。参考体系结构创建了NX迁移以执行这些已知操作。对于那些不熟悉的人，NX迁移有点像类固醇上的代码mod。

每个迁移变得越来越具有挑战性，但也揭示了平台的价值。通常，英勇会看到以下步骤。

大多数时候，在其中一个阶段之一中也有迁移到打字稿的迁移。这有助于总体上可测试性和可重复性，同时还提高了开发人员的生产率。

在现有应用程序周围添加应用程序外壳，然后添加了模块联合会为团队提供了更大的自由度。通过这种组合，他们现在能够逐步升级具有较高相对自主权的每个联合遥控器。这使团队可以决定如何优先级迁移应用程序的其余部分。通过清晰的沟通方式和向后兼容性，协调所需的努力显着降低。

架构标准的变化，设计系统会更新，并且与所有软件破坏一样，更改总是可能在拐角处。通过利用企业NX工作区，可以通过单个命令在整个企业中传播这些更改，这也可以自动化。

随着新的NX工作区和缓存构建的使用情况，也会变得更快（通常以10-100倍的订单）。我们看到一个客户的构建功能从零缓存能力和需要90分钟以上的时间来运行，到300-600毫秒左右的高缓存能力。

Valor软件已经与多个组织合作，现在开始了此迁移过程，结果坦率地说，结果令人惊讶。作为与NX，NRWL和模块联合会的独家合作伙伴的合作伙伴，我们希望有机会分享有关我们如何帮助您的组织转向React 18和Module Federation的特定细节，schedule今天打电话！