SAP 电商云 Spartacus UI 4.1 版本的延迟加载

2021-12-11  本文已影响0人  _扫地僧_

延迟加载，也称为代码拆分，可让您将 JavaScript 代码分成多个块。 结果是当用户访问第一页时，您不必加载完整应用程序的所有 JavaScript。 相反，只加载给定页面所需的块。 在浏览店面时，会在真正需要使用到某些功能时，再加载这些功能块的实现模块。

这种方法可以显着改善“交互时间”，尤其是在低端移动设备访问复杂 Web 应用程序的情况下。

Spartacus Approach to Lazy Loading

代码拆分是一种必须在应用程序构建时完成的技术。 Angular 提供的代码拆分通常是基于路由的，这意味着着陆页有一个块，产品页面有另一个块，依此类推。 由于 Spartacus 主要是 CMS 驱动的，因此无法在构建时决定每个路由的实际应用逻辑。 业务用户最终将通过引入或删除组件来改变页面结构。 这就是为什么需要另一种延迟加载方法的原因，Spartacus 支持以下两种不同粒度的延迟加载技术：

Defining Dynamic Imports Only in the Main Application

动态导入是一种用于促进延迟加载并允许代码拆分的技术，只能在类型为 Application 的 Angular 应用程序中使用。无法在预构建库(类型为 Library )中定义动态导入。

这是一个不幸的限制，导致必须由客户添加一些应用程序代码。 尽管自定义代码的数量被限制在最低限度，但我们将在未来版本的原理图库中添加一项功能，以自动添加延迟加载模块。

Avoiding Static Imports for Lazy-Loaded Code

为了使代码拆分成为可能，您的静态 JavaScript 代码（主应用程序包）不应该对您想要延迟加载的代码进行任何静态导入。一个例子就是 QuickOrderService. 构建器会注意到代码已经包含在内，因此不会为其生成单独的块。 这在从库中导入 symbol 的情况下尤其重要。

至少在 Angular 9 和 Angular 10 里，将静态导入与动态导入混合用于相同的库入口点，即使对于不同的 symbol，也会破坏该库入口点的延迟加载和 tree shaking 优化。 如果您要这样做，它将在构建中静态地包含整个入口点。 因此，强烈建议您为必须静态加载的代码创建特定的入口点，并为可以延迟加载的代码创建单独的入口点。

Configuration in Lazy-Loaded Modules

如果在延迟加载模块内部提供了额外的配置，Spartacus 会将其合并到全局应用程序配置中，以支持现有组件和服务的延迟加载场景。 在大多数情况下，尤其是当延迟加载的模块主要提供默认配置时，这可以可靠地工作。 但是，如果过度使用它会导致问题，尤其是当两个模块为配置的同一部分提供不同的配置时。 可以通过在主应用程序中提供必要的覆盖来修复诸如此类的场景。

这种合并功能是通过默认启用的兼容性机制实现的，但您可以使用 disableConfigUpdates 功能标志禁用它。 如果您正在开发必须从延迟加载的模块中挂钩到配置的新模块，则应改用 ConfigurationService.unifiedConfig$。

Providers in Lazy-Loaded Modules

延迟加载模块中提供的注入令牌对根应用程序中提供的服务不可见。

这尤其适用于 multi-provided 的令牌，例如 HttpInterceptors、各种处理程序等。

为了减轻这个缺点，一些 Spartacus 功能，例如 PageMetaService（使用 PageMetaResolver 令牌）或 ConverterService（主要使用适配器序列化器和规范化器），在我们的实现里使用 unified 注入器。 只有这样做，根应用程序才可以访问延迟加载的令牌，并可以利用它们来实现全局功能。

对于不依赖于统一注入器的机制（例如，来自大多数非 Spartacus 库的功能，例如核心 Angular 库），建议您始终使用 eager 模式加载包含了这些令牌的模块。

Unified Injector

统一注入器提供了一种注入令牌或多提供令牌的方法，这种方法同时考虑到根注入器和来自延迟加载功能的注入器。 注入器公开一个可观察的对象，每次统一注入器的状态发生变化时，该观察对象都会为指定的令牌发出一组新的可注入对象。

Avoiding Importing the HttpClientModule in Your Lazy-Loaded Modules

一般来说，HttpClientModule 应该在根应用程序中导入，而不是在库中。 例如，如果您将它导入到延迟加载的库中，则根库中的所有注入器对于源自延迟加载模块的 HTTP 调用都是不可见的。

虽然技术上可以在库中导入 HttpClientModule ，但在大多数情况下这不是预期的，并且可能会导致难以解释的错误，因此请记住这一点。

Lazy Loading of CMS Components

CMS 代码的延迟加载是通过在 CMS 映射配置中指定动态导入代替静态引用的组件类来实现的。 下面是一个例子：

{
  cmsComponents: {
    SimpleResponsiveBannerComponent: {
      component: () => import('./lazy/lazy.component').then(m => m.LazyComponent)
    }
  }
}

Lazy Loading of Modules

CMS 驱动的功能模块延迟加载允许以下内容：

Exposing Smart Proxy Facades From lazy loaded Features

代理外观提供了一种灵活的方式来从延迟加载的功能模块中公开核心功能，这样使用这些外观的组件就不必知道它是否延迟加载以及是否需要初始化。

对代理外观的方法或属性的任何访问都会触发所有相关功能的延迟加载和初始化。

Combined Injector

任何延迟加载的模块都可以从根应用程序注入器和依赖模块注入器注入（即可以访问）服务和令牌。 这是可能的，因为每次实例化具有依赖项的功能模块时都会创建 CombinedInjector。

当一个被延迟加载模块覆盖的 CMS 组件被实例化时，它可以注入（即访问）以下服务：

Preparing Libraries to Work with Lazy Loading

Providing Fine-Grained Entry Points in Your Library

从相同的入口点混合静态和动态导入会破坏延迟加载并影响摇树，因此任何将直接用于动态导入的库都应该公开细粒度的辅助入口点以优化代码拆分。

作为惯例，Spartacus 公开功能的根入口点(root entry points)，例如 @spartacus/orgainzation/administration/root。 这种类型的入口点包含所有不应或不能延迟加载的代码，比如 Proxy Facade 层。来自根入口点的模块应该在根应用程序中静态导入，这意味着它们将被预先加载并在主应用程序块中可用。

有关对 Angular 库中辅助入口点的支持的更多信息，请参阅 GitHub 上 ng-packagr 文档中的辅助入口点。

Separating Static Code from Lazy-Loaded Code

当您使用 Angular Dependency Injection 时，注入器中的提供程序列表不应在注入器初始化后更改。这种范式特别适用于任何多提供的令牌、处理程序，尤其适用于任何 Angular 原生多提供的令牌，例如 HTTP_INTERCEPTOR、APP_INITIALIZER 等。

结果是延迟加载模块中的任何多提供令牌对于根或其他延迟加载块中提供的模块和服务将不可见，但使用注入的多提供令牌除外统一喷油器。

一些 Spartacus 功能，例如 PageMetaService 或 ConverterService，使用 UnifiedInjector 来了解可以延迟加载的令牌，以便全局逻辑（例如 SEO 功能）即使逻辑延迟加载该功能也能可靠地工作。例如，商店定位器页面元解析器可以使用商店定位器功能延迟加载。

Spartacus 配置也是通过提供配置块来定义的，由于兼容机制将配置从延迟加载功能贡献到全局配置，因此处理方式略有不同。这种机制可以通过功能标志禁用，将来会默认关闭，以支持统一配置功能。

如果根服务无法看到延迟加载提供程序的问题，则始终可以将此类代码包含在预先可用的静态链接模块中。建议在您的库中创建一个单独的入口点（按照惯例，命名为 root，例如 my-library/root），其中包含最少的代码，将包含在主包中，并且从一开始就可用。

Simple Strategies for Optimized and Balanced Code Splitting

每个业务功能都略有不同，但总的来说，出于折中考虑，可以按照以下几点进行优化：

上一篇下一篇

猜你喜欢

热点阅读