前端状态管理【免费下载链接】platformReactive State for Angular项目地址https://gitcode.com/gh_mirrors/pl/platform点击查看免费下载no-multiple-global-stores是 NgRx ESLint 插件ngrx/eslint-plugin中面向ngrx/store的一条代码规范建议类规则。它基于一个核心事实——整个 Angular 应用中只有一个全局Store单例——因此强制要求每个类组件、服务等只能注入一次全局 Store。读完本文你将掌握该规则的完整语义、违规与合规示例、如何通过扁平配置flat config启用它以及从源码层面理解它如何定位 Store 注入点、分组检测并给出可一键应用的移除建议suggestion。规则速览该规则在文档中给出的元信息如下Type、Fixable等字段由插件自动生成便于编辑器与工具链识别属性值含义Typesuggestion属于代码规范建议类规则FixableNo不提供自动修复fix编辑器不会在保存时自动改写SuggestionYes提供手动可应用的建议修复suggestRequires type checkingNo仅依赖 AST 语法分析无需类型信息运行开销低ConfigurableNoschema为空不接受任何选项开/关即全部行为规则的单一能力概括为一句话一个类中只能注入一个全局 Store。为什么只能有一个全局 Store在 NgRx 的ngrx/store架构中应用状态集中存放在一个由provideStore()或基于模块的StoreModule.forRoot()提供的全局单例 Store 中所有组件与服务通过依赖注入共享这同一个 Store 实例。相关实现位于 provide_store.ts 与 store_module.ts。这意味着在构造函数中同时注入多个Store本质上拿到的是同一个全局实例只是用不同的类型参数generic和变量名去声明它。这种写法不会带来任何隔离或数据范围上的收益反而会让读者误以为存在多个相互独立的 Store造成架构误解与no-typed-global-store规则所指出的问题相伴出现后者禁止给全局 Store 添加泛型类型参数如StoreCustomers增加无意义的参数数量降低构造函数可读性。从源码看no-multiple-global-stores.ts 定义了两种消息noMultipleGlobalStoresGlobal store should be injected only once.注入时报告noMultipleGlobalStoresSuggestRemove this reference.建议文案。违规代码示例以下写法是不正确的同一构造参数列表中注入了两个全局 Store并且分别赋予了泛型类型参数export class Component { constructor( private readonly customersStore: StoreCustomers, private readonly catalogStore: StoreCatalog ) {} }每个多余的Store注入参数都会各自触发一次报告。规则会逐个标记违反的注入点并给出移除该引用的建议。合规代码示例由于全局 Store 是单例每个类只需要注入一次export class Component { constructor(private readonly store: Store) {} }同一作用域下仅保留一个Store注入即视为合规。下面这些写法也都是合规的// 同一个类中不注入任何 Store class Ok { constructor() {} } // 一个 Store 其他服务 class Ok4 { constructor(private store: Store, data: Service) {} } // 不同类各自注入自己的 Store class Ok5 { constructor(private store: Store) {} } class Ok6 { constructor(private readonly store: Store) {} } // 使用 public 访问修饰符的 Store 属性注入同样合规 class Ok8 { constructor(public store$: Store) {} }规则底层是如何工作的理解实现有助于判断规则在各种边界场景下的行为。规则核心实现在 no-multiple-global-stores.ts工作链路如下定位注入点调用getNgRxStores(context)定义于 utils.ts它会遍历文件中从ngrx/store导入的Store标识符的所有引用。该导入路径来自常量NGRX_MODULE_PATHS.store见 ngrx-modules.ts。识别两种注入形态getInjectedParametersWithSourceCode既能识别构造参数的类型注解形态constructor(private store: Store)也能识别inject(Store)调用的属性初始化形态——后者通过检查angular/core的inject导入、CallExpression以及PropertyDefinition的 key 来确认见 utils.ts。按所属类分组groupBy把收集到的所有 Store 标识符按它们共同的父节点构造函数的参数列表所属类分组。Program()监听器在文件级运行只要某一组内的 Store 标识符数量大于 1 就会逐个报告。选择报告节点getNodeToReport会检查标识符的父节点是否为TSParameterProperty即带public/private/readonly修饰符的参数属性若是则报告整个参数属性节点保证编辑器高亮范围覆盖修饰符与类型注解。生成移除建议每个违反点都附带一条suggest修复内部调用getNodeToCommaRemoveFix见 utils.ts移除目标节点并顺带删除紧随其后的逗号 token从而保证移除后参数列表语法仍然完整。从源码结构可以推断由于规则监听的是Program级别并在整份文件内做分组因此同一文件中的多个类各自注入一个 Store 不会互相干扰只有同一个类的作用域内出现多个 Store 才会被标记。建议修复的实际效果Suggest: Yes意味着 IDE 会展示可点击的修复建议。以测试用例no-multiple-global-stores.spec.ts中的例子来说明修复行为。对如下代码两个 Store 参数都会被标记import { Store } from ngrx/store class NotOk { constructor(store: Store, store2: Store) {} }IDE 会为每个违规点各提供一条Remove this reference建议。移除第一个参数后尾随逗号会被一并清理class NotOk { constructor( store2: Store) {} }移除第二个参数后同样干净利落class NotOk { constructor(store: Store, ) {} }建议修复对注释、其他服务参数以及带修饰符的混合写法也能正确处理。例如class NotOk1 { constructor(store: Store /* first store */, private readonly actions$: Actions, private store2: Store, b: B) {} }移除第二个store2: Store后b: B之前的逗号会被删除actions$与b的声明保持完好class NotOk1 { constructor(store: Store /* first store */, private readonly actions$: Actions, b: B) {} }如何启用该规则该规则不需要任何配置选项Configurable: No最简单的使用方式是按需单独开启。ngrx/eslint-plugin提供的两个预设配置中该规则默认即被启用为error在store预设中与ngrx/no-typed-global-store、ngrx/use-consistent-global-store-name、ngrx/no-store-subscription等 store 类规则一起生效见 store.ts在all全量预设中同样以error级别启用见 all.ts。在eslint.config.mjs中单独开启的写法export default [ { files: [**/*.ts], rules: { ngrx/no-multiple-global-stores: error, }, }, ];由于该规则不依赖类型检查配合typescript-eslint/parser即可在静态语法层面完成全部检测无需额外的 typed linting 项目配置。与其他 Store 规则的协同该规则并非孤立存在。从 store 预设配置 可见它与以下规则共同守护全局 Store 的使用规范no-typed-global-store禁止给全局 Store 附加泛型类型参数。文档明确指出违反本规则多个全局 Store通常同时违反该规则二者常被一并修复use-consistent-global-store-name要求全局 Store 的注入变量名保持一致no-store-subscription禁止直接订阅全局 Store。实践中当你发现类中出现多个带不同泛型的Store注入时正确的做法是仅保留一个Store注入移除泛型参数改用 Feature Selector 从全局状态中选取所需切片——这也正是 NgRx 官方推荐的状态访问方式。验证与测试规则的完整行为由 no-multiple-global-stores.spec.ts 通过ruleTester覆盖测试用例清晰地划定了边界合规集合无 Store、单个Store含private/public/readonly修饰符组合、单 Store 其他服务参数、多个类各自注入一个 Store违规集合同一构造函数出现 2 个甚至 3 个 Store 注入每个注入点都被单独报告并逐点给出移除建议建议修复断言验证移除后输出的代码与预期完全一致包括逗号清理、注释保留、多参数混合场景。测试还覆盖了报告中不破坏后续文件内其他类报告的场景ShouldNotBreakLaterReports用例印证了规则按类分组、逐点报告的稳定性设计。如果你希望在贡献插件时修改该规则运行对应测试即可快速回归验证。赞分享前端状态管理【免费下载链接】platformReactive State for Angular项目地址https://gitcode.com/gh_mirrors/pl/platform点击查看免费下载相关推荐Omi 开源AI穿戴设备完整指南一个记得住所有对话的第二大脑Omi 开源AI穿戴设备完整指南一个记得住所有对话的第二大脑 Omi 是一款完全开源的 AI 穿戴设备它挂在你胸前或架在你的鼻梁上替你实时记录对话、把语音人工智能AI 应用语音移动开发后端桌面应用智能硬件MCP 服务eslint-plugin-unicorn 的 no-global-object-property-assignment 规则禁止在全局对象上赋值属性eslint plugin unicorn 的 no global object property assignment 规则禁止在全局对象上赋值属性 导读Lint代码质量5分钟llmfit新手指南一条命令找到你电脑能流畅跑的大模型5分钟llmfit新手指南一条命令找到你电脑能流畅跑的大模型 llmfit 是一个把大语言模型自动匹配到你硬件的开源终端工具。一条命令检测 CPU、内存和 G人工智能大模型本地部署模型评测CLI开发工具上一篇MiGPT 完整避坑指南4 层配置让小爱音箱接入大模型变身 AI 语音助手下一篇新手必看5分钟上手mlx-community/gemma-4-31B-it-OptiQ-4bit本地运行31B参数模型不再卡顿创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考