文档技术博客教程【免费下载链接】weekly前端精读周刊。帮你理解最前沿、实用的技术。项目地址https://gitcode.com/GitHub_Trending/we/weekly点击查看免费下载本文是前端精读周刊对 TC39class-static-block提案2021 年 9 月进入 Stage 4随 ES2022 正式落地的深度解读。文章以 Class 静态变量批量初始化的真实痛点切入完整覆盖static {}块状作用域的语法特征、与书写顺序一致的执行时机、父类优先的继承语义以及“在块内同时访问私有变量与全局变量”这一特权能力并结合本仓库 精读《Typescript 4.4》、精读《TC39 与 ECMAScript 提案》 等姊妹篇帮助你彻底理解这个新语法「能做什么、为什么需要、以及该不该用」。提案背景从 Stage 4 到 ES2022class static block是一个基于 Class 的增强提案于2021 年 9 月 1 日进入 TC39 流程的 Stage 4finished 阶段。按照 TC39 的标准流程详见本仓库 精读《TC39 与 ECMAScript 提案》进入 Stage 4 意味着该特性已准备就绪会出现在下个版本的 ECMAScript 规范中需要通过至少 2 个独立实现并跑通验收测试以获取使用过程中的重要实践经验。因此它随ES2022一起成为 JavaScript 的标准语法今天主流的现代浏览器与 Node.js 均已原生支持不需要任何 polyfill 即可直接运行。为什么需要它静态变量批量初始化的痛点class static block 诞生的直接动机是对Class 静态变量的灵活赋值需求。看下面这个例子我们想在一个Translator类内部把静态字典translations拆成英文词表与德文词表两个静态数组由于 Class 内部“不能写普通代码块”就只能写一个无用的_静态变量用来挂载初始化的逻辑class Translator { static translations { yes: ja, no: nein, maybe: vielleicht, }; static englishWords []; static germanWords []; static _ initializeTranslator( // (A) this.translations, this.englishWords, this.germanWords); } function initializeTranslator(translations, englishWords, germanWords) { for (const [english, german] of Object.entries(translations)) { englishWords.push(english); germanWords.push(german); } }这段代码暴露了 Class 语法的一个结构性缺陷Class 内部不能写代码块只能声明字段与函数。于是初始化逻辑被迫外置成独立函数initializeTranslator但外部函数又无法访问 Class 内部属性只能通过参数把成员变量一个一个传进去。为了自定义一段静态变量初始化逻辑我们不得不做出两个妥协在外部定义一个函数并接受大量 Class 成员变量传参在 Class 内部定义一个无意义的变量_用来启动这个函数逻辑。这不仅让代码看起来杂乱还引入了“_是什么”的阅读困惑。而 class static block 正是为了把这段初始化逻辑搬回 Class 内部而生class Translator { static translations { yes: ja, no: nein, maybe: vielleicht, }; static englishWords []; static germanWords []; static { // (A) for (const [english, german] of Object.entries(this.translations)) { this.englishWords.push(english); this.germanWords.push(german); } } }对比两段代码可以清晰看到语法特征static关键字后面不再跟变量名而是直接跟一个代码块。在这个代码块内部可以通过this访问 Class 的所有静态成员变量如this.translations、this.englishWords可以访问 Class 的#私有变量可以执行任意逻辑语句不再受“只能写字段”的限制。于是initializeTranslator外部函数消失了传参消失了多余的_变量也消失了全部逻辑收敛在static {}内部可读性与内聚性都得到了提升。执行顺序书写顺序一致父类优先class static block 虽然好用但执行时机必须精确理解否则容易踩坑。规则可以概括为一句话所有static字段或 static block 都严格按书写顺序执行且父类总是先于子类执行。class SuperClass { static superField1 console.log(superField1); static { assert.equal(this, SuperClass); console.log(static block 1 SuperClass); } static superField2 console.log(superField2); static { console.log(static block 2 SuperClass); } } class SubClass extends SuperClass { static subField1 console.log(subField1); static { assert.equal(this, SubClass); console.log(static block 1 SubClass); } static subField2 console.log(subField2); static { console.log(static block 2 SubClass); } } // Output: // superField1 // static block 1 SuperClass // superField2 // static block 2 SuperClass // subField1 // static block 1 SubClass // subField2 // static block 2 SubClass从输出可以归纳出三个关键点一个 Class 内可以存在多个 static block它们与静态字段一起按书写顺序依次执行静态字段与代码块相互穿插也完全合法父类与子类可以各自拥有 static block执行时父类整体先于子类这符合面向对象里“父类先初始化”的直觉this指向当前正在初始化的类本身代码里assert.equal(this, SuperClass)与assert.equal(this, SubClass)正是对这一语义的验证。值得注意的是既然执行顺序与书写顺序一致那么调整书写顺序就会改变执行结果这个选择权被完全交给了使用者。因此建议在书写 static block 时把对某个静态字段的依赖放在该字段声明之后保持“先声明、后使用”的自上而下阅读习惯。精读一个特殊的私有变量访问机制class static block 除了解决静态变量批量初始化提案还有一个更隐蔽的动机为“从外部读取私有变量”提供一条合法的通道。JavaScript 的#私有字段设计得非常严格可参考本仓库 精读《Whats new in javascript》 中对 private class fields 的介绍试图在 Class 外部访问#成员会直接抛出异常理论上外部无论如何都无法拿到私有变量的值。但 static block 打破了这种“绝对隔离”let getX; export class C { #x constructor(x) { this.#x { data: x }; } static { // getX has privileged access to #x getX (obj) obj.#x; } } export function readXData(obj) { return getX(obj).data; }这段代码里static {}块内把读取obj.#x的闭包赋值给了模块级变量getX而readXData通过调用getX就能拿到任意C实例的私有字段值。整个过程不抛任何运行时错误原因在于static block 可以同时访问私有变量与全局变量天然具备“里应外合”的条件闭包(obj) obj.#x是在 Class 内部static block 作用域内被创建并定义的对#x的访问在语法层面完全合法之后即使把这个闭包“递”到 Class 外部调用访问权限依旧保留——因为私有字段的访问权是绑定在词法定义位置上的而不是调用位置。不过作者对这个特性持保留态度这更像一个 BUG 而不是一个好点子。因为“任何对规定的突破都会为可维护性埋下隐患”。JavaScript 之所以引入#私有字段就是要保证字段不被外部读取/修改而 static block 提供的这条逃生通道等于在封装边界上开了一个口子。作者给出的可接受边界是除非这个特性用在稳定的工具、框架层用来做一些便利性工作最终提升了应用编码的体验这种用法是可以接受的。也就是说框架作者可以在内部用“static block 捕获私有读取函数”的方式对外提供更友好的 API普通业务代码则不建议滥用这条通道否则私有字段的语义保护就形同虚设。本质语法完善而非新增能力最后需要清醒地认识到class static block 本质上并没有增加任何新功能。上面所有写法我们完全可以用普通静态变量 外部函数代替只是写起来很不自然、代码更散。所以这个特性可以理解为对 Class「不能写代码块」这一缺陷的补充或者说是一次语法完善让“静态初始化”这件事的表达更贴近直觉。从工程落地角度看TypeScript 在4.4 版本就已经完整支持了 class static blocks并且明确说明“在代码块作用域内可以访问私有变量”详见本仓库 精读《Typescript 4.4》。因此今天无论是写原生 JS 还是 TS都可以放心使用该语法无需额外的类型体操或编译配置。总结class static block 在 Class 内部创建了一个块状作用域这个作用域有三个核心特征特权访问内部可以访问 Class 的静态成员与#私有变量还可以读写块外的全局/模块级变量单次执行该块状作用域仅在引擎进行类初始化时执行一次不会随实例创建而重复执行顺序确定多个 static block 与静态字段按书写顺序执行父类先于子类行为可预期、可控制。它是一个比较方便的语法糖解决静态变量批量初始化的“无代码块”困境为框架层提供了一条受控的私有数据访问通道同时保持了与书写顺序一致的可预测执行模型。当然社区也不乏反对声音有人说这是对 JS 的复杂化也有人调侃“JS 越来越像 Java”。不过作者更赞同提案者的观点——JS 中 Class 并不是全部现在越来越多代码使用函数式语法即便使用了 Class 的场景也存在大量函数声明所以 class static block 对开发者的感知实际上并不大。它更像是在已有 Class 体系中补上的一块拼图知道它存在在恰好需要批量初始化静态状态时信手拈来就足够了。赞分享文档技术博客教程【免费下载链接】weekly前端精读周刊。帮你理解最前沿、实用的技术。项目地址https://gitcode.com/GitHub_Trending/we/weekly点击查看免费下载相关推荐Yaegi变量初始化顺序包级变量与init函数执行Yaegi变量初始化顺序包级变量与init函数执行 在Go语言开发中变量初始化和 init 函数的执行顺序常常让开发者困惑。特别是当项目中存在多个包级变量和编程语言解释器语言运行时前端模块化设计原则打造高内聚低耦合的现代前端架构前端模块化设计原则打造高内聚低耦合的现代前端架构 前端模块化设计是构建可维护、可扩展Web应用的核心原则。随着前端项目规模不断扩大模块化已从可选优化变为必备文档技术博客教程别再手动点了青龙面板 API 批量运维全流程别再手动点了青龙面板 API 批量运维全流程 凌晨两点一批定时任务要在整点前停掉你只能打开青龙面板的网页一个个点想改脚本里的账号配置又要翻到环境变量页任务调度后端前端上一篇albert安全机制解析保护你的隐私与数据安全下一篇YCSB工作负载配置终极指南6种标准负载的完整使用教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考