将Angular CLI应用拆分至Nx库的技术咨询

问题1：以该方式共享实体集合是否可行？ #

完全可行，这是跨懒加载特性模块共享数据的典型方案，核心优势包括：

• 避免重复请求后端数据，降低服务器压力与用户等待时长
• 统一数据来源，杜绝不同模块维护独立实体副本引发的数据不一致问题
• 支持后台静默刷新数据，不干扰当前UI展示，提升用户体验

需注意几个关键细节：

• 确保实体唯一标识（如ID）全局唯一，防止不同类型实体ID冲突导致数据覆盖
• 设计合理的实体清理策略，避免核心状态随使用时间过度膨胀，比如用户退出相关模块后清理无用实体，或采用分页加载减少单次存入的实体数量
• 统一实体更新逻辑，核心reducer仅处理通用的增、删、改、批量操作，特性模块仅负责触发action，保持职责分离

问题2：核心reducer是否应监听懒加载特性模块的action？ #

可以这么做，只要当前仅导入action定义文件、未引入特性模块组件/服务等其他代码的方式没有破坏懒加载，这种方案就是合理的。

实践中要注意：

• 所有action必须是纯类型定义，不依赖特性模块的业务代码，确保核心状态库仅依赖action的类型与创建器，而非整个特性模块
• 为action添加唯一前缀（如[User] Load Success、[Order] Load Success），避免不同特性模块的action命名冲突
• 核心reducer只负责实体集合的通用维护逻辑，特性模块仅负责触发action（比如发起数据请求、通知加载完成），不破坏特性模块的独立性

问题3：如何将核心服务与状态重构至Nx工作区库？ #

按以下步骤完成重构：

1. 创建Nx核心库
   分别创建核心状态库与核心服务库（职责分离更清晰）：

   nx generate library core-state --directory=libs/core
   nx generate library core-services --directory=libs/core
   

2. 迁移核心状态代码
   • 将根状态配置、实体集合reducer、全局selectors、effects（如有）移到core-state库中
   • 在库的public-api.ts导出对外暴露的内容：

     export * from './lib/reducers';
     export * from './lib/selectors';
     export * from './lib/actions';
     

   • 在core-state库的module中配置NgRx模块：

     @NgModule({
       imports: [
         StoreModule.forFeature('sharedEntities', sharedEntitiesReducer),
         EffectsModule.forFeature([SharedEntitiesEffects])
       ]
     })
     export class CoreStateModule {}
     

3. 迁移核心服务代码
   • 将providedIn: 'root'的REST API通信服务移到core-services库中
   • 在public-api.ts导出服务类，由于使用providedIn: 'root'，无需在库module中声明providers，导入库后服务会自动注册
4. 主应用集成
   在AppModule中导入CoreStateModule，Nx会自动处理core-services库的依赖关联

问题4：如何将特性模块重构为库以避免静态导入整个库破坏懒加载？action应独立为库还是设为次级入口？ #

特性模块转Nx库的步骤 #

1. 为每个特性创建独立库
   为30个特性模块分别创建专属Nx库，确保单个库仅包含对应特性的代码：

   nx generate library feature-user --directory=libs/features
   nx generate library feature-order --directory=libs/features
   

2. 配置动态路由懒加载
   在主应用路由配置中使用动态导入指向特性库模块，确保不会静态加载整个库：

   const routes: Routes = [
     {
       path: 'users',
       loadChildren: () => import('@your-workspace/features/feature-user').then(m => m.FeatureUserModule)
     }
   ];
   

3. action的共享处理
   分两种场景处理：
   • 跨特性共享的通用action：比如实体加载成功/失败这类通用action，建议创建独立的shared-actions库，所有需要使用的核心状态库与特性库都导入该库的action，避免重复定义
   • 特性专属但需核心reducer监听的action：在对应特性库中创建次级入口（如libs/features/feature-user/src/lib/actions），并在库的package.json中配置：

     "exports": {
       ".": "./src/index.ts",
       "./actions": "./src/lib/actions/index.ts"
     }
     

     核心状态库仅导入该次级入口的action（import { UserActions } from '@your-workspace/features/feature-user/actions'），不会加载特性库的其他代码，保证懒加载不受影响

内容的提问来源于stack exchange，提问作者pyskp