【第七十二期】2023-02-27

[Geekhyt]

美味值：🌟🌟🌟🌟🌟

口味：草莓番茄

本期摘要

• Signals 是前端框架的未来
• Chrome Headless 进化成完全体
• Next.js 13.2
• Deno 1.31
• Bun 新文档上线
• ts-reset
• TypeScript Brand type with Zod
• 字节跳动 DevOps 交付流程演进之路
• magic-regexp

大家好，我是童欧巴。欢迎来到前端食堂技术周刊，我们先来看下上周的技术资讯。

技术资讯

1. Signals 是前端框架的未来

Builder.io 的 CTO、Angular、Qwik 的作者 Miško Hevery 近日发文表示 Signals 是前端框架的未来。

尤大也在 Vue 官网上添加了 Connection to Signals 部分。将目前实现 Signals 的框架：Solid、Angular、Preact、Qwik 与 Vue 进行了一波对比。

其中 Preact 和 Qwik 的 API 设计与 Vue 的 shallowRef 类似。Solid 的 createSignal() API 设计强调了读、写隔离，暴露 getter、setter。Angular 放弃了脏检查，引入了自己的响应式实现

与 Vue 的 refs 相比，Solid 和 Angular 基于 getter 的 API 风格提供了一些有趣的权衡：

• () 虽然比 .value 写起来更省事儿，但是更新值的时候比较啰嗦。
• 没有 ref-unwrapping(解包)，访问值总是需要 ()，这使得值在任何地方访问都是一致的。这也意味着你可以将原始的 signals 作为组件的 props 传递下去。

用 Vue 的 shallowRef 和 triggerRef 也可以实现类似 Solid 和 Angular 的 API。

2. Chrome Headless 进化成完全体

Chrome Headless 无头模式进化成完全体，支持浏览器插件等浏览器级别的功能，利好自动化测试。

3. Next.js 13.2

• 内置 SEO 支持：Metadata API
• 自定义 Route Handlers
• 服务器组件支持 MDX
• Rust 实现的 MDX Parser
• Error Overlay 改进
• Link 类型安全 (Beta)
• 改进 Turbopack 与 Webpack loader 的兼容性 (Alpha)
• Next.js Cache (Beta)

4. Deno 1.31

• 支持 package.json
• Node-API 稳定
• 对 Node 的兼容层已经嵌入到运行时，性能得到提升，减少维护成本
• 远程模块支持 npm specifiers，无须传入 --unstable 标志

5. Bun 新文档上线

下面我们来看技术资料。

技术资料

1. ts-reset

TypeScript 的 “CSS reset”，用于完善常见的 JS API 的类型。

2. TypeScript Brand type with Zod

Brand Type + 类型守卫 = 更安全的类型

Brand Type 说白了就是模拟名义子类型结构，保证代码调用的类型安全，再通过类型谓词 is 实现类型守卫做数据验证的逻辑，双重安全。(数据验证推荐使用 Zod)

3. 字节跳动 DevOps 交付流程演进之路

交付流程源于一系列现实的复杂性，如：业务、团队、技术，大公司的业务和团队会更加多元，技术也会更加复杂。

看字节如何破局：通过开放共建的流水线体系为底座，打造业务可自定义的自动化和协同流程。

• 开放共建：集中兵力优化通用工具和关键链路，业务可以自己定制工具，减少依赖，快速达成业务目标
• 三套交付流程：自动化为特点的单服务流水线、协同视图为特点的需求交付模式和版本火车模式
• 平台层：标准的对接体系、流水线的标准化、原子服务的标准化、变量参数的标准化，对接各种基建能力
• 自动化：提升单点自动化效率，建设自动化工具链串联起单点，优化人工和自动化的协作流程
• 流水线：API 和 Hook 能力、原子服务市场、模版市场、变量系统、决策节点
• 以价值流为主线的协同模式：全流程模式(自测流程、简化流程、标准流程、紧急流程)、火车模式
• 落地策略：抓住有利时机、定义足够业务收益、团结利益相关人

4. magic-regexp

符合人体工程学的正则替代品，类型安全，爽。

周刊赞助

整理周刊要花费大量的精力和时间，你可以通过以下方式支持我：

• 将食堂分享给你的朋友；
• 订阅食堂的竹白付费专栏(食堂为你准备了专属的会员通讯，以及前端食堂数字花园知识库的访问权限)。

订阅地址：https://hungryturbo.zhubai.love/

知识星球

好了，以上就是本期的食堂周刊，观众老爷们如果觉得还不错，一键三连是对食堂老板最大的支持。

你的前端食堂，吃好每一顿饭，我们下期见。

[AndyBoat]

在调研Zod时,发现存在一个困难点是, 我要使用zod的语法, 努力重写一遍我在service中已经实现过的ts类型声明;
一方面, 有重复工作的问题(虽然运行时校验和静态校验是两回事,但是意图上一一致的);
另一方面, zod对泛型等一些ts类型体操相关能力的支持好像存在问题,不能像ts类型定义那么灵活.

试图google过 直接从ts type生成zod定义的工具, 也许可以解决第一个问题, 但是第二个问题还是无法解决

[skimhugo]

在调研Zod时,发现存在一个困难点是, 我要使用zod的语法, 努力重写一遍我在service中已经实现过的ts类型声明; 一方面, 有重复工作的问题(虽然运行时校验和静态校验是两回事,但是意图上一一致的); 另一方面, zod对泛型等一些ts类型体操相关能力的支持好像存在问题,不能像ts类型定义那么灵活.

试图google过 直接从ts type生成zod定义的工具, 也许可以解决第一个问题, 但是第二个问题还是无法解决

个人认为，zod 最主要还是在与 json 衔接的地方（通常是后端与前端的交界处，用户输入到前端接口的交界处）提供运行时的类型检查，其目标要比 TS 的类型简单一些。所以并不见得要灵活成 TS 那样。其关注点就是当前的 json 的形状，外加一些业务规则限制。

[AndyBoat]

在调研Zod时,发现存在一个困难点是, 我要使用zod的语法, 努力重写一遍我在service中已经实现过的ts类型声明; 一方面, 有重复工作的问题(虽然运行时校验和静态校验是两回事,但是意图上一一致的); 另一方面, zod对泛型等一些ts类型体操相关能力的支持好像存在问题,不能像ts类型定义那么灵活.
试图google过 直接从ts type生成zod定义的工具, 也许可以解决第一个问题, 但是第二个问题还是无法解决

个人认为，zod 最主要还是在与 json 衔接的地方（通常是后端与前端的交界处，用户输入到前端接口的交界处）提供运行时的类型检查，其目标要比 TS 的类型简单一些。所以并不见得要灵活成 TS 那样。其关注点就是当前的 json 的形状，外加一些业务规则限制。

同意, 我也认同, zod 对api 的校验应该朴素一些.
但是在trpc的场景里, 试图在一个全栈的工程里以方法的方式去调用API , 他好像就是依赖zod的类型推断,给到API的参数类型, 这就使得如果基于zod的朴素类型, 就无法复用后端业务逻辑中已经声明的灵活的类型推断和提示.

最终我们选择了模仿trpc, 干脆自己diy一个proxy实现, 但是也可能是我没有找到在trpc里手动声明input参数类型的地方, 如果有朋友知道的话也可以教教我

[skimhugo]

在调研Zod时,发现存在一个困难点是, 我要使用zod的语法, 努力重写一遍我在service中已经实现过的ts类型声明; 一方面, 有重复工作的问题(虽然运行时校验和静态校验是两回事,但是意图上一一致的); 另一方面, zod对泛型等一些ts类型体操相关能力的支持好像存在问题,不能像ts类型定义那么灵活.
试图google过 直接从ts type生成zod定义的工具, 也许可以解决第一个问题, 但是第二个问题还是无法解决

个人认为，zod 最主要还是在与 json 衔接的地方（通常是后端与前端的交界处，用户输入到前端接口的交界处）提供运行时的类型检查，其目标要比 TS 的类型简单一些。所以并不见得要灵活成 TS 那样。其关注点就是当前的 json 的形状，外加一些业务规则限制。

同意, 我也认同, zod 对api 的校验应该朴素一些. 但是在trpc的场景里, 试图在一个全栈的工程里以方法的方式去调用API , 他好像就是依赖zod的类型推断,给到API的参数类型, 这就使得如果基于zod的朴素类型, 就无法复用后端业务逻辑中已经声明的灵活的类型推断和提示.

最终我们选择了模仿trpc, 干脆自己diy一个proxy实现, 但是也可能是我没有找到在trpc里手动声明input参数类型的地方, 如果有朋友知道的话也可以教教我

我用的 fastify，不了解 trpc。在 fastify 中如果要用 zod，需要用类似 https://github.com/elierotenberg/fastify-zod 这样的插件，单独声明出口 API 的声明和类型。出口 API 主要衔接 controller 和 service 层下的交界，再往下的类型主要依赖 prisma 生成的了。

而且我目前前端因为目前用的 veevalid，还需要用 yup 再声明一遍。zod 生成的类型只是用于前台 fetch 到的数据的形状了。一直想把这一块统一为 zod，但是一直没搞。

感觉理想状态下，zod 定义一遍能把前台用户输入的形状限制住，同时限制后台的输入的形状。同一份代码前后端的校验都用了。

[AndyBoat]

在调研Zod时,发现存在一个困难点是, 我要使用zod的语法, 努力重写一遍我在service中已经实现过的ts类型声明; 一方面, 有重复工作的问题(虽然运行时校验和静态校验是两回事,但是意图上一一致的); 另一方面, zod对泛型等一些ts类型体操相关能力的支持好像存在问题,不能像ts类型定义那么灵活.
试图google过 直接从ts type生成zod定义的工具, 也许可以解决第一个问题, 但是第二个问题还是无法解决

个人认为，zod 最主要还是在与 json 衔接的地方（通常是后端与前端的交界处，用户输入到前端接口的交界处）提供运行时的类型检查，其目标要比 TS 的类型简单一些。所以并不见得要灵活成 TS 那样。其关注点就是当前的 json 的形状，外加一些业务规则限制。

同意, 我也认同, zod 对api 的校验应该朴素一些. 但是在trpc的场景里, 试图在一个全栈的工程里以方法的方式去调用API , 他好像就是依赖zod的类型推断,给到API的参数类型, 这就使得如果基于zod的朴素类型, 就无法复用后端业务逻辑中已经声明的灵活的类型推断和提示.
最终我们选择了模仿trpc, 干脆自己diy一个proxy实现, 但是也可能是我没有找到在trpc里手动声明input参数类型的地方, 如果有朋友知道的话也可以教教我

我用的 fastify，不了解 trpc。在 fastify 中如果要用 zod，需要用类似 https://github.com/elierotenberg/fastify-zod 这样的插件，单独声明出口 API 的声明和类型。出口 API 主要衔接 controller 和 service 层下的交界，再往下的类型主要依赖 prisma 生成的了。

而且我目前前端因为目前用的 veevalid，还需要用 yup 再声明一遍。zod 生成的类型只是用于前台 fetch 到的数据的形状了。一直想把这一块统一为 zod，但是一直没搞。

感觉理想状态下，zod 定义一遍能把前台用户输入的形状限制住，同时限制后台的输入的形状。同一份代码前后端的校验都用了。

同意, 我觉得理想状态还可以进一步: 如果是纯全栈场景(即Node HTTP Rest API 接口仅由同一个工程内的前端调用), 那么如zod这种库的运行时校验和数据parse的意义不大, 因为 JSON 本身就是自解释的, 很多时候只需要ts的静态校验就足够满足类型安全和开发者体验.
以上也仅限于小型的纯全栈场景而言哈

[skimhugo]

在调研Zod时,发现存在一个困难点是, 我要使用zod的语法, 努力重写一遍我在service中已经实现过的ts类型声明; 一方面, 有重复工作的问题(虽然运行时校验和静态校验是两回事,但是意图上一一致的); 另一方面, zod对泛型等一些ts类型体操相关能力的支持好像存在问题,不能像ts类型定义那么灵活.
试图google过 直接从ts type生成zod定义的工具, 也许可以解决第一个问题, 但是第二个问题还是无法解决

个人认为，zod 最主要还是在与 json 衔接的地方（通常是后端与前端的交界处，用户输入到前端接口的交界处）提供运行时的类型检查，其目标要比 TS 的类型简单一些。所以并不见得要灵活成 TS 那样。其关注点就是当前的 json 的形状，外加一些业务规则限制。

同意, 我也认同, zod 对api 的校验应该朴素一些. 但是在trpc的场景里, 试图在一个全栈的工程里以方法的方式去调用API , 他好像就是依赖zod的类型推断,给到API的参数类型, 这就使得如果基于zod的朴素类型, 就无法复用后端业务逻辑中已经声明的灵活的类型推断和提示.
最终我们选择了模仿trpc, 干脆自己diy一个proxy实现, 但是也可能是我没有找到在trpc里手动声明input参数类型的地方, 如果有朋友知道的话也可以教教我

我用的 fastify，不了解 trpc。在 fastify 中如果要用 zod，需要用类似 https://github.com/elierotenberg/fastify-zod 这样的插件，单独声明出口 API 的声明和类型。出口 API 主要衔接 controller 和 service 层下的交界，再往下的类型主要依赖 prisma 生成的了。
而且我目前前端因为目前用的 veevalid，还需要用 yup 再声明一遍。zod 生成的类型只是用于前台 fetch 到的数据的形状了。一直想把这一块统一为 zod，但是一直没搞。
感觉理想状态下，zod 定义一遍能把前台用户输入的形状限制住，同时限制后台的输入的形状。同一份代码前后端的校验都用了。

同意, 我觉得理想状态还可以进一步: 如果是纯全栈场景(即Node HTTP Rest API 接口仅由同一个工程内的前端调用), 那么如zod这种库的运行时校验和数据parse的意义不大, 因为 JSON 本身就是自解释的, 很多时候只需要ts的静态校验就足够满足类型安全和开发者体验. 以上也仅限于小型的纯全栈场景而言哈

zod 除了提供 “正确”，还能提供一些其他价值，比如有一定防攻击的能力，因为前台代码虽然是你写的，但是别人也可以来探测你的接口。zod 可以把输入在运行时限制一道。应该还能找到其他场景，zod 还是有很大价值的。限制运行时输入，测试也简单了。TypeScript 相当于实现了部分编译态测试。另外 zod 相当于让 TypeScript 获得了 sound 的能力（在某一部分）。

zod 让 TS 的这些框架获得了其他比如 c#、java、rust 后端框架现在也在提供的流行的能力。价值还是比较高的。