core-js 中的Symbol.customMatcher预定义符号Extractors 提案的 Polyfill 实现与用法解析【免费下载链接】core-jsStandard Library项目地址: https://gitcode.com/GitHub_Trending/co/core-jsSymbol.customMatcher是 core-js 为实现 TC39 Extractors提取器提案而提供的 well-known symbol预定义符号polyfill它允许用户在自定义提取器类型上声明“匹配”语义是提案模式匹配基础设施的关键一环。本文以仓库文档 symbol-custommatcher-for-extractors.md 为主体结合 core-js 的模块源码、聚合入口与单元测试完整解析该符号的类型签名、加载入口、底层实现机制与验证方式帮助读者在项目中按需引入并理解其工作原理。Extractors 提案与Symbol.customMatcher的定位Extractors 是 TC39 提出的一个 stage 2 提案对应 core-js 的 stage/2 聚合入口核心思想是允许开发者用“提取器extractor”来描述数据结构并在模式匹配pattern matching时通过自定义逻辑完成值的提取与绑定。为了让提取器能声明“自己如何被匹配”提案引入了 well-known symbolcustomMatcher即静态属性Symbol.customMatcher。从仓库的 stage 划分可以清晰看到它的演进位置stage/1.js 引入proposals/pattern-matching-v2新版本模式匹配提案stage/2.js 引入proposals/extractorsExtractors 提案本体。而新旧两代提案在符号选择上并不相同仓库中 proposals/pattern-matching.js 引入的是旧符号Symbol.matcher模块 esnext.symbol.matcher.js注释标注为4版本移除的过时实现而 proposals/pattern-matching-v2.js 与 proposals/extractors.js 引入的则是本篇文章的主角Symbol.customMatcher。也就是说Symbol.customMatcher代表的是模式匹配 v2 / Extractors 的新一代匹配语义。内置签名Built-ins signatures按照关联文档的说明该符号在内置对象上的签名如下class Symbol { static customMatcher: customMatcher; }即Symbol.customMatcher是Symbol构造函数上的一个静态属性其值为一个唯一的 well-known symbol即customMatcher。它本身不携带任何可调用逻辑作用是为引擎与用户代码提供一个约定当一个对象需要参与 extractor 模式匹配时可以通过该符号约定的键来挂载自定义匹配行为。这也是 well-known symbol 的一贯用法——与Symbol.iterator声明可迭代、Symbol.hasInstance声明 instanceof 行为类似。核心模块与底层实现机制模块文件esnext.symbol.custom-matcherSymbol.customMatcher的实现非常精简全部逻辑位于 esnext.symbol.custom-matcher.jsuse strict; var defineWellKnownSymbol require(../internals/well-known-symbol-define); // Symbol.customMatcher well-known symbol // https://github.com/tc39/proposal-pattern-matching defineWellKnownSymbol(customMatcher);模块只做一件事调用内部工具函数defineWellKnownSymbol(customMatcher)。注意注释中的链接指向的是 proposal-pattern-matching 提案这是因为该符号同时服务于 pattern matching v2 与 extractors 两套提案语境。底层well-known-symbol-define与 well-known symbol 存储defineWellKnownSymbol定义在 well-known-symbol-define.jsmodule.exports function (NAME) { var Symbol path.Symbol || (path.Symbol {}); if (!hasOwn(Symbol, NAME)) defineProperty(Symbol, NAME, { value: wrappedWellKnownSymbolModule.f(NAME) }); };其行为可以拆解为三步从内部path模块取到必要时创建全局Symbol构造函数通过hasOwn判断Symbol上是否已存在customMatcher属性存在则跳过避免重复定义与覆盖原生实现不存在时使用defineProperty以属性描述符形式写入其中value来自 well-known-symbol-wrapped.js 的f方法——它本质上委托给 well-known-symbol.js 的wellKnownSymbol(name)。well-known-symbol.js内部维护一个跨包共享的WellKnownSymbolsStore基于内部shared机制并遵循“原生优先”原则WellKnownSymbolsStore[name] NATIVE_SYMBOL hasOwn(Symbol, name) ? Symbol[name] : createWellKnownSymbol(Symbol. name);也就是说若运行环境本身已经实现了Symbol.customMatchercore-js 会直接复用原生符号否则才基于Symbol.for/Symbol/uid兜底创建一个描述为Symbol.customMatcher的新符号。这保证了 polyfill 在不同引擎下的行为一致性。入口点Entry points与按需加载关联文档给出了两类入口结合仓库实际文件可以对应如下1. Proposals 聚合入口core-js/proposals/extractors文档中列出的core-js/proposals/pattern-extractors在当前仓库中对应的实际文件为 proposals/extractors.js其内容为use strict; // https://github.com/tc39/proposal-extractors require(../modules/esnext.symbol.custom-matcher);该入口只引入customMatcher这一个模块是加载本功能的最小聚合入口。另外如果读者同时在使用模式匹配 v2 提案也可以通过 proposals/pattern-matching-v2.js 一并引入——它的内容与 extractors 入口一致同样只 requireesnext.symbol.custom-matcher。2. 单功能入口full 级别core-js(-pure)/full/symbol/custom-matcher对应文件为 full/symbol/custom-matcher.jsuse strict; require(../../modules/esnext.symbol.custom-matcher); var WrappedWellKnownSymbolModule require(../../internals/well-known-symbol-wrapped); module.exports WrappedWellKnownSymbolModule.f(customMatcher);与前文聚合入口不同full/symbol/custom-matcher.js除了执行模块加载还会以模块导出形式返回Symbol.customMatcher符号本身通过WrappedWellKnownSymbolModule.f(customMatcher)。这意味着使用core-js-pure/full/symbol/custom-matcher这类纯命名空间入口时你可以直接拿到符号引用用于自定义比较而无需触碰全局对象——这正是core-js-pure消除全局污染设计在符号场景下的体现。此外当使用full/symbol聚合入口时full/symbol/index.js 中也会自动注册esnext.symbol.custom-matcher模块与Symbol.observable等其余 esnext 符号一起暴露。3. 按阶段整包引入Symbol.customMatcher还会随下面两个 stage 入口被自动带入取决于读者需要覆盖到的提案面core-js/stage/1→ 经 proposals/pattern-matching-v2.js 引入core-js/stage/2→ 经 proposals/extractors.js 引入。使用建议如果只需要 Extractors 的匹配符号优先采用core-js/proposals/extractors这一最小入口避免引入stage/*整包带来的额外体积。测试验证从单元测试看预期行为core-js 为本功能提供了全局与纯命名空间两套单元测试它们精确刻画了该符号的契约全局版测试 unit-global/esnext.symbol.custom-matcher.js纯命名空间版测试 unit-pure/esnext.symbol.custom-matcher.js。全局版测试的核心断言如下QUnit.test(Symbol.customMatcher, assert { assert.true(customMatcher in Symbol, Symbol.customMatcher available); assert.nonEnumerable(Symbol, customMatcher); assert.true(Object(Symbol.customMatcher) instanceof Symbol, Symbol.customMatcher is symbol); if (DESCRIPTORS) { const descriptor Object.getOwnPropertyDescriptor(Symbol, customMatcher); assert.false(descriptor.enumerable, non-enumerable); assert.false(descriptor.writable, non-writable); assert.false(descriptor.configurable, non-configurable); } });从测试可以归纳出四项可验证的事实Symbol.customMatcher属性必须可用customMatcher in Symbol该属性不可枚举nonEnumerable其值必须是合法的 symbolObject(...) instanceof Symbol在支持属性描述符的环境中属性的enumerable、writable、configurable三项都必须为false——即它是一个只读、不可枚举、不可配置的静态符号属性。纯命名空间版测试则验证了core-js-pure/full/symbol导出下同样可以访问Symbol.customMatcher且符号类型正确印证了前面full/symbol/custom-matcher.js导出符号引用的行为。在实际项目中的使用方式环境自检在引入 polyfill 后可以按如下方式自检运行环境是否已就绪基于测试断言语义import core-js/proposals/extractors; console.log(customMatcher in Symbol); // true console.log(Object(Symbol.customMatcher) instanceof Symbol); // true典型使用形态示意Symbol.customMatcher属于协议类符号使用方式是在自定义提取器类型上按符号约定挂载匹配行为例如import core-js/proposals/extractors; class Range { constructor(from, to) { this.from from; this.to to; } static Symbol.customMatcher { return typeof value number value this.from value this.to ? { matched: true, value } : { matched: false }; } }说明Symbol.customMatcher的具体调用约定入参、返回结构由 Extractors 提案规范定义core-js 仅负责提供该 well-known symbol 本体上述代码用于展示“按符号协议挂载自定义匹配逻辑”的通用形态具体字段与返回结构请以提案规范的演进版本为准。按需加载组合当项目同时使用其他 esnext 符号时可以精确组合入口// 最小化仅 customMatcher import core-js/proposals/extractors; // 或经由 full 符号聚合入口 import core-js/full/symbol;若使用core-js-pure则采用纯命名空间方式引入并直接使用导出的符号import customMatcher from core-js-pure/full/symbol/custom-matcher;小结Symbol.customMatcher是 core-js 对 Extractors / Pattern Matching v2 提案的关键支撑符号其 polyfill 实现极简而严谨通过 esnext.symbol.custom-matcher.js 调用统一的 well-known symbol 定义机制在 well-known-symbol-define.js 与 well-known-symbol.js 中完成“原生优先、按需创建、幂等定义”的语义。读者既可以经由core-js/proposals/extractors、core-js/stage/1、core-js/stage/2等聚合入口一键引入也可以通过core-js(-pure)/full/symbol/custom-matcher精确按需加载并借助仓库中两套单元测试所固定的属性契约symbol 类型、不可枚举、不可写、不可配置在项目中安全使用。若需进一步了解与旧版Symbol.matcher的差异可对照阅读 esnext.symbol.matcher.js 与 proposals/pattern-matching.js 了解新旧提案符号的并存与迁移脉络。【免费下载链接】core-jsStandard Library项目地址: https://gitcode.com/GitHub_Trending/co/core-js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
core-js 中的Symbol.customMatcher预定义符号Extractors 提案的 Polyfill 实现与用法解析【免费下载链接】core-jsStandard Library项目地址: https://gitcode.com/GitHub_Trending/co/core-jsSymbol.customMatcher是 core-js 为实现 TC39 Extractors提取器提案而提供的 well-known symbol预定义符号polyfill它允许用户在自定义提取器类型上声明“匹配”语义是提案模式匹配基础设施的关键一环。本文以仓库文档 symbol-custommatcher-for-extractors.md 为主体结合 core-js 的模块源码、聚合入口与单元测试完整解析该符号的类型签名、加载入口、底层实现机制与验证方式帮助读者在项目中按需引入并理解其工作原理。Extractors 提案与Symbol.customMatcher的定位Extractors 是 TC39 提出的一个 stage 2 提案对应 core-js 的 stage/2 聚合入口核心思想是允许开发者用“提取器extractor”来描述数据结构并在模式匹配pattern matching时通过自定义逻辑完成值的提取与绑定。为了让提取器能声明“自己如何被匹配”提案引入了 well-known symbolcustomMatcher即静态属性Symbol.customMatcher。从仓库的 stage 划分可以清晰看到它的演进位置stage/1.js 引入proposals/pattern-matching-v2新版本模式匹配提案stage/2.js 引入proposals/extractorsExtractors 提案本体。而新旧两代提案在符号选择上并不相同仓库中 proposals/pattern-matching.js 引入的是旧符号Symbol.matcher模块 esnext.symbol.matcher.js注释标注为4版本移除的过时实现而 proposals/pattern-matching-v2.js 与 proposals/extractors.js 引入的则是本篇文章的主角Symbol.customMatcher。也就是说Symbol.customMatcher代表的是模式匹配 v2 / Extractors 的新一代匹配语义。内置签名Built-ins signatures按照关联文档的说明该符号在内置对象上的签名如下class Symbol { static customMatcher: customMatcher; }即Symbol.customMatcher是Symbol构造函数上的一个静态属性其值为一个唯一的 well-known symbol即customMatcher。它本身不携带任何可调用逻辑作用是为引擎与用户代码提供一个约定当一个对象需要参与 extractor 模式匹配时可以通过该符号约定的键来挂载自定义匹配行为。这也是 well-known symbol 的一贯用法——与Symbol.iterator声明可迭代、Symbol.hasInstance声明 instanceof 行为类似。核心模块与底层实现机制模块文件esnext.symbol.custom-matcherSymbol.customMatcher的实现非常精简全部逻辑位于 esnext.symbol.custom-matcher.jsuse strict; var defineWellKnownSymbol require(../internals/well-known-symbol-define); // Symbol.customMatcher well-known symbol // https://github.com/tc39/proposal-pattern-matching defineWellKnownSymbol(customMatcher);模块只做一件事调用内部工具函数defineWellKnownSymbol(customMatcher)。注意注释中的链接指向的是 proposal-pattern-matching 提案这是因为该符号同时服务于 pattern matching v2 与 extractors 两套提案语境。底层well-known-symbol-define与 well-known symbol 存储defineWellKnownSymbol定义在 well-known-symbol-define.jsmodule.exports function (NAME) { var Symbol path.Symbol || (path.Symbol {}); if (!hasOwn(Symbol, NAME)) defineProperty(Symbol, NAME, { value: wrappedWellKnownSymbolModule.f(NAME) }); };其行为可以拆解为三步从内部path模块取到必要时创建全局Symbol构造函数通过hasOwn判断Symbol上是否已存在customMatcher属性存在则跳过避免重复定义与覆盖原生实现不存在时使用defineProperty以属性描述符形式写入其中value来自 well-known-symbol-wrapped.js 的f方法——它本质上委托给 well-known-symbol.js 的wellKnownSymbol(name)。well-known-symbol.js内部维护一个跨包共享的WellKnownSymbolsStore基于内部shared机制并遵循“原生优先”原则WellKnownSymbolsStore[name] NATIVE_SYMBOL hasOwn(Symbol, name) ? Symbol[name] : createWellKnownSymbol(Symbol. name);也就是说若运行环境本身已经实现了Symbol.customMatchercore-js 会直接复用原生符号否则才基于Symbol.for/Symbol/uid兜底创建一个描述为Symbol.customMatcher的新符号。这保证了 polyfill 在不同引擎下的行为一致性。入口点Entry points与按需加载关联文档给出了两类入口结合仓库实际文件可以对应如下1. Proposals 聚合入口core-js/proposals/extractors文档中列出的core-js/proposals/pattern-extractors在当前仓库中对应的实际文件为 proposals/extractors.js其内容为use strict; // https://github.com/tc39/proposal-extractors require(../modules/esnext.symbol.custom-matcher);该入口只引入customMatcher这一个模块是加载本功能的最小聚合入口。另外如果读者同时在使用模式匹配 v2 提案也可以通过 proposals/pattern-matching-v2.js 一并引入——它的内容与 extractors 入口一致同样只 requireesnext.symbol.custom-matcher。2. 单功能入口full 级别core-js(-pure)/full/symbol/custom-matcher对应文件为 full/symbol/custom-matcher.jsuse strict; require(../../modules/esnext.symbol.custom-matcher); var WrappedWellKnownSymbolModule require(../../internals/well-known-symbol-wrapped); module.exports WrappedWellKnownSymbolModule.f(customMatcher);与前文聚合入口不同full/symbol/custom-matcher.js除了执行模块加载还会以模块导出形式返回Symbol.customMatcher符号本身通过WrappedWellKnownSymbolModule.f(customMatcher)。这意味着使用core-js-pure/full/symbol/custom-matcher这类纯命名空间入口时你可以直接拿到符号引用用于自定义比较而无需触碰全局对象——这正是core-js-pure消除全局污染设计在符号场景下的体现。此外当使用full/symbol聚合入口时full/symbol/index.js 中也会自动注册esnext.symbol.custom-matcher模块与Symbol.observable等其余 esnext 符号一起暴露。3. 按阶段整包引入Symbol.customMatcher还会随下面两个 stage 入口被自动带入取决于读者需要覆盖到的提案面core-js/stage/1→ 经 proposals/pattern-matching-v2.js 引入core-js/stage/2→ 经 proposals/extractors.js 引入。使用建议如果只需要 Extractors 的匹配符号优先采用core-js/proposals/extractors这一最小入口避免引入stage/*整包带来的额外体积。测试验证从单元测试看预期行为core-js 为本功能提供了全局与纯命名空间两套单元测试它们精确刻画了该符号的契约全局版测试 unit-global/esnext.symbol.custom-matcher.js纯命名空间版测试 unit-pure/esnext.symbol.custom-matcher.js。全局版测试的核心断言如下QUnit.test(Symbol.customMatcher, assert { assert.true(customMatcher in Symbol, Symbol.customMatcher available); assert.nonEnumerable(Symbol, customMatcher); assert.true(Object(Symbol.customMatcher) instanceof Symbol, Symbol.customMatcher is symbol); if (DESCRIPTORS) { const descriptor Object.getOwnPropertyDescriptor(Symbol, customMatcher); assert.false(descriptor.enumerable, non-enumerable); assert.false(descriptor.writable, non-writable); assert.false(descriptor.configurable, non-configurable); } });从测试可以归纳出四项可验证的事实Symbol.customMatcher属性必须可用customMatcher in Symbol该属性不可枚举nonEnumerable其值必须是合法的 symbolObject(...) instanceof Symbol在支持属性描述符的环境中属性的enumerable、writable、configurable三项都必须为false——即它是一个只读、不可枚举、不可配置的静态符号属性。纯命名空间版测试则验证了core-js-pure/full/symbol导出下同样可以访问Symbol.customMatcher且符号类型正确印证了前面full/symbol/custom-matcher.js导出符号引用的行为。在实际项目中的使用方式环境自检在引入 polyfill 后可以按如下方式自检运行环境是否已就绪基于测试断言语义import core-js/proposals/extractors; console.log(customMatcher in Symbol); // true console.log(Object(Symbol.customMatcher) instanceof Symbol); // true典型使用形态示意Symbol.customMatcher属于协议类符号使用方式是在自定义提取器类型上按符号约定挂载匹配行为例如import core-js/proposals/extractors; class Range { constructor(from, to) { this.from from; this.to to; } static Symbol.customMatcher { return typeof value number value this.from value this.to ? { matched: true, value } : { matched: false }; } }说明Symbol.customMatcher的具体调用约定入参、返回结构由 Extractors 提案规范定义core-js 仅负责提供该 well-known symbol 本体上述代码用于展示“按符号协议挂载自定义匹配逻辑”的通用形态具体字段与返回结构请以提案规范的演进版本为准。按需加载组合当项目同时使用其他 esnext 符号时可以精确组合入口// 最小化仅 customMatcher import core-js/proposals/extractors; // 或经由 full 符号聚合入口 import core-js/full/symbol;若使用core-js-pure则采用纯命名空间方式引入并直接使用导出的符号import customMatcher from core-js-pure/full/symbol/custom-matcher;小结Symbol.customMatcher是 core-js 对 Extractors / Pattern Matching v2 提案的关键支撑符号其 polyfill 实现极简而严谨通过 esnext.symbol.custom-matcher.js 调用统一的 well-known symbol 定义机制在 well-known-symbol-define.js 与 well-known-symbol.js 中完成“原生优先、按需创建、幂等定义”的语义。读者既可以经由core-js/proposals/extractors、core-js/stage/1、core-js/stage/2等聚合入口一键引入也可以通过core-js(-pure)/full/symbol/custom-matcher精确按需加载并借助仓库中两套单元测试所固定的属性契约symbol 类型、不可枚举、不可写、不可配置在项目中安全使用。若需进一步了解与旧版Symbol.matcher的差异可对照阅读 esnext.symbol.matcher.js 与 proposals/pattern-matching.js 了解新旧提案符号的并存与迁移脉络。【免费下载链接】core-jsStandard Library项目地址: https://gitcode.com/GitHub_Trending/co/core-js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
)
