金数据技术博客

跨 site 加载 JS 的代价 —— Chrome 139+ 的一个默认行为，和我们为它付的两次学费

2026-08-21T01:58:24Z

TL;DR

我们的系统内页面首次打开会白屏 2~3 秒，LCP 高达 4 秒多
Root cause 是 Chrome 139 起默认开启的 LowPriorityAsyncScriptExecution：它会延迟执行跨 site 的 async script，最长可达 1 秒
我们的网站在 jinshuju.net，JS chunk 在 jsjform.com 的 CDN 上，正好命中
被延迟的 chunk 让 React hydration 的调度器轮次从几十次暴涨到十万次，主线程被脚本占满，scripting 长达 2 秒多
修复：给 Next.js 的 JS chunk 都标记 fetchpriority="high"，即可绕过延迟执行

修复后对比（home 页面）：

	Scripting 时长	LCP 时长
修复前	大于 2000ms	~4s
禁用该特性启动 Chrome	~700ms	~1.6 ~ 2s
修复后（同一账号、同网络）	~700ms	~2s

背景

金数据是一款在线表单工具的 SaaS 产品。我们刻意把系统内（表单编辑、数据管理，跑在 jinshuju.net）和对外表单（填写者访问的公开页面）隔离在不同的域名上，而整个 Next.js 应用的 JS chunk 统一从 jsjform.com 的 CDN 加载。

这个「网站域名 ≠ 静态资源域名」的组合，让我们在同一个坑里交了两次学费。

1. 我们自己埋的坑

其实这个坑之前就踩到过一次。

之前对外表单冷加载时会有 1 秒白屏，当时初步定位到是 cross-site JS 执行有性能问题，于是把 JS chunk 的域名改成了和对外表单一致的 jsjform.com——对外表单变成了同 site 加载，问题解决。

当时也记录了副作用：系统内的域名从此和 chunk 域名不一致了（jinshuju.net vs jsjform.com）。但当时的判断是：系统内用户只有一次冷启动，之后都是热缓存，影响不大。

这个判断后来被证明是错的——热缓存同样受影响。

2. 系统内太慢了

随着功能增加，系统内的代码量越来越大。我们发现访问 home 页面，特别是冷启动时，会白屏 2~3 秒，体验极差。

做了一轮 chunk 瘦身后，Chrome 调试仍然显示 scripting 耗时长达 2 秒多。

此时想起了之前踩过的坑。

3. 用 agent 协助定位

第一次踩坑时并没有定位到真正的 root cause，这次我们在 Claude 的协助下重新排查。

Agent 用线上页面和 CDN，通过 CDP 做了控制变量测试——同一份 chunk，只改变加载它的网站域名：

网站域名	与 chunk 的关系	ScriptDuration 冷	ScriptDuration 热	调度器轮次冷	调度器轮次热
`im.jsjform.com`	同 site	241 ms	51 ms	5,527	36
`zz.jsjform.com`	同 site	260 ms	48 ms	6,710	23
`im.jinshuju.net`	跨 site	2,997 ms	2,807 ms	109,876	98,487
`im.jsjform-x.net`	跨 site（不存在的域名）	2,858 ms	2,802 ms	180,964	98,373

不论冷热，跨 site 都是同 site 的 12~55 倍。

注意：纯 JS script 不会有这个问题。它只在 React 协作式调度下被放大——被延迟的 chunk 让 hydration/Suspense 反复重试，调度轮次爆炸，才吃满了主线程。

4. 和上次不同的测试结果

这个问题不只影响冷启动：有热缓存时，差距倍数反而更大。

所以对系统内用户来说，这是必须修复的问题。

5. Root Cause

网络搜索没有找到任何相关的 issue 或文章。

Claude 先排查了 8 个方向：进程隔离、V8 code cache、时钟精度与 performance.now() 开销、MessageChannel RTT、裸 CPU 吞吐、H2 连接复用、字节数与压缩、资源域名白名单逻辑——都没有问题。

然后通过对 Chrome 版本做二分，定位到问题从 Chrome 139 开始出现。再通过源码分析，找到了 root cause：

Chrome 139 起默认开启 Blink feature kLowPriorityAsyncScriptExecution（third_party/blink/common/features.cc）。这个特性会让 async script 延迟执行，最长可达 1 秒。

它有几个关键参数：

参数	默认值	含义
`cross_site_only`	`true`	只对跨 site 的 script 生效
`main_frame_only`	`true`	只对主 frame 生效（iframe 不生效）
`exclude_non_parser_inserted`	`false`	动态插入的脚本，也同样延迟执行
`opt_out_high_fetch_priority_hint`	`true`	`fetchpriority=high` 可以 opt out（不延迟）

6. 方案一：换成同一个域名？

第一个解决方案，是让网站和 JS chunk 使用同一个域名。

但这对我们很难：系统内和对外表单是刻意隔离在不同域名上的，而 Next.js 一个代码库只能配置一个 assetPrefix。非要走这条路，就得把系统内和对外隔离成独立部署，或者用代理重写 HTML 返回值。

代价太高，放弃。

7. 方案二：让 chunk 带上 `fetchpriority=high`

从 Chrome 源码看，fetchpriority=high 可以让 script 完全绕过这个延迟机制。

但 Next.js 的 chunk script 是框架内部生成的，没有暴露配置接口。所以这个方案需要给 Next.js 打 patch。

我们最终采取了这个方案。

8. 打 patch

需要一个 patch 加一段运行时代码。

第一，patch Next.js 的 runtime：在 pushScriptImpl 向页面写入 script 时，判断是否是 chunk，自动添加 fetchPriority：

t.src && t.src.includes("/_next/static/chunks/") && null == t.fetchPriority
  && (t = {...t, fetchPriority: "high"}),

第二，客户端侧，Turbopack 运行时 append script 时同样自动添加：

export function prioritizeNextChunkScript<T extends Node>(node: T): T {
  if (node instanceof HTMLScriptElement && node.src) {
    try {
      if (new URL(node.src, location.href).pathname.includes(NEXT_CHUNK_PATH)) node.fetchPriority = 'high'
    } catch {
      // `src` reflects the raw attribute when it is not a parsable URL
    }
  }
  return node
}

上线后 view-source 可以看到 chunk script 都带上了 fetchPriority="high"：

修复后的效果（同一账号、同网络）：LCP 从 4 秒多降到约 2 秒，scripting 从 2 秒多降到约 500ms：

已知缺口：React 的 bootstrapScript（id="_R_" 的那个）无法标记 fetchPriority，但对结果影响不大。

9. 后续

Patch 只是缓解，不是根治。我们在考虑给 Next.js 提 PR，让 chunk script 的属性可以配置。
继续给 chunk 瘦身——脚本执行总量降下来，对延迟调度的敏感度也会降低。
未来升级 Next.js 时需要同步维护这个 patch。

写在最后

两次学费的教训：

「网站域名 ≠ 静态资源域名」不再只是一个 DNS/缓存层面的决定——浏览器开始基于 site 边界调整脚本执行优先级，这个组合会直接影响运行时性能
性能问题的归因要做到 root cause 为止。第一次我们停在了「cross-site JS 执行慢」的现象层，选了一个恰好绕过问题的方案，于是在另一个域名组合上把坑重新踩了一遍

一个 Button，440 KB —— Server Component 里 import antd 的代价

2026-08-20T08:14:06Z

English Version

TL;DR

在 Next.js 的 Server Component 里直接 import { X } from 'antd'，会把整个 antd（全部 76 个组件目录）打进这个路由的 JS bundle
即便配置了 experimental.optimizePackageImports 也无效
修复方式：把 import { X } from 'antd' 挪进 Client Component

背景

金数据的新版前端是一个体量不小的 Next.js 应用，系统内页面的 UI 组件库用的是 antd。最近在做 bundle size 优化时我们发现：有些路由明明只用了一两个 antd 组件，产物里却出现了完整的 antd。

排查下来，源头是一行看起来毫无问题的代码——在 Server Component 里 import 了 antd。

最小复现

创建两个 Next.js 项目（antd 6.2.0 / Next.js 16.2.6 / React 19.2.1），只渲染一个 Button 按钮。

A. Server Import

// app/page.tsx（Server Component）

import { Button } from 'antd'

export default function Page() {
  return <Button type="primary">hello</Button>
}

B. Client Import

// app/page.tsx（Server Component）

import ClientButton from './ClientButton'

export default function Page() {
  return <ClientButton />
}

// app/ClientButton.tsx

'use client'

import { Button } from 'antd'

export default function ClientButton() {
  return <Button type="primary">hello</Button>
}

两个页面实际渲染出的 HTML 一字不差：

<button type="button" class="ant-btn css-var-root ant-btn-primary ant-btn-color-primary ant-btn-variant-solid"><span>hello</span></button>

但 JS bundle size 差别巨大：

	A. Server Import	B. Client Import
JS Bundle (RAW)	1458 KB	176 KB
JS Bundle (gzip)	440 KB	56 KB
打进产物的 antd 组件目录	76 个	12 个

开发环境的对比

Server Import：54 个请求，5486 KB，steps、table、transfer、upload…… 页面里根本不存在的组件全都被加载了。

Client Import：23 个请求，4446 KB（开发模式未压缩），没有多余的组件。

Production Bundle 分析对比

Server Import：All Route Modules 3.54 MB（压缩前），1545 个模块，包含所有 antd 组件。

Client Import：All Route Modules 1.05 MB（压缩前），365 个模块，仅包含 Button 和必须的 antd 依赖。

为什么会这样

antd/es/index.js 的第一行是：

"use client";

所以 antd 的桶文件（Barrel）本身就是一个 client module。

Server Component 一旦 import 它，Next.js 就会在 antd/es/index.js 这个模块上建立 RSC client reference——整个 index.js 被当作一个 client 入口包裹进去，它 re-export 的 76 个组件全部成为可达代码。

optimizePackageImports 的原理是把桶文件 import 改写成对具体子路径的 import，但在这里改写无法生效，整个 barrel 都进了产物。

这个问题不只属于 antd：任何桶文件顶部带 "use client" 的组件库，在 Server Component 里整包 import 都会踩中同一个坑。

怎么修

把 antd 的使用挪进一个 Client Component，页面 / layout 保持 Server Component。渲染结果完全一致，bundle 里只剩下真正用到的组件。

在金数据的代码库里，我们把这条规则写进了架构约束：app/ 路由层禁止 import antd，antd 的配置（Provider、message / notification 等）统一放在 views 层的 client 组件里。

其他方式

直接 deep import 也可以绕过桶文件：

import Button from 'antd/es/button'

但我们不推荐这个方式：antd/es/button 不是公开 API，且不是所有组件都有对应的路径。

解决 GraphQL 类型膨胀问题，显著提升 Turbopack 构建速度

2025-12-22T02:29:05Z

English Version

背景

金数据是一款在线表单工具的 SaaS 产品。我们的后端基于 Ruby on Rails，通过 GraphQL 对外提供接口；前端则是一个体量不小的 Next.js 应用。

产品已经运行了十年，业务模型非常复杂。这也是我们选择 GraphQL 的核心原因之一：类型系统。

GraphQL 强制要求接口定义类型，配合前端的 TypeScript，仅靠类型检查，我们就能提前规避掉大量潜在问题。保守估计，仅在类型层面就减少了 90% 的低级 bug。

另一个现实原因是：我们需要用同一套接口同时服务多个前端形态——

legacy 旧版前端
新版 Next.js 前端
移动端 App
Mobile Web

GraphQL 在这方面非常友好。

当然，代价也很明显：
我们的主前端仓库已经相当复杂，路由数量、代码规模都不小。

Turbopack 带来的新问题

随着项目不断增长，Webpack 在本地开发时已经明显吃力了：

修改一个文件，等待几十秒才能看到结果
production build 经常需要 5～10 分钟

这对开发效率的打击非常直接。
开发体验的核心，其实就是反馈速度。

好消息是：
我们最近升级到了 Next.js 16，并正式切换到了 Turbopack。

整个切换过程出乎意料地顺利，而且效果非常明显：

production build：1 分钟左右
本地开发：修改后几秒内即可看到反馈

效率提升非常显著 👍

但紧接着，一个严重的问题出现了。

“第一次请求要 70 秒？”

在本地开发时，当你第一次启动服务，然后访问第一个页面，事情开始变得不对劲。

非常慢。
慢到离谱。

$ pnpm dev

 ▲ Next.js 16.0.10 (Turbopack)

 ✓ Starting...
 ✓ Ready in 2.7s
 ○ Compiling /home ...
 GET /home 200 in 79s (compile: 78s, proxy.ts: 336ms, render: 1055ms)
 ○ Compiling /favorites ...
 GET /favorites 200 in 5.4s (compile: 5.4s, proxy.ts: 9ms, render: 17ms)
 GET /home 200 in 49ms (compile: 18ms, proxy.ts: 15ms, render: 17ms)

解释一下这段日志：

服务启动只用了 2.7 秒
第一次访问 /home：编译耗时 78 秒
第二个页面 /favorites：5.4 秒
再次访问 /home：49 毫秒

也就是说：

只有第一次请求，慢得像卡死了一样。

70 多秒。

我一度不知道这段时间该干嘛：
去冲杯咖啡？
还是和同事对视沉默几秒？

第一次尝试：循环依赖

直觉告诉我，问题可能出在循环依赖上。

我们并没有启用非常严格的 lint 规则，项目历史又很久，出现一些循环依赖并不奇怪。而在构建阶段，循环依赖对 compiler 来说，怎么看都不像一件好事。

于是我用 madge 扫了一下：

$ npx madge --circular --extensions ts,tsx src/

Processed 3722 files (27.8s) (1544 warnings)

✖ Found 302 circular dependencies!

……
三百多个。

这个结果说实话有点震撼。

循环依赖本身就会让代码：

可读性变差
职责边界模糊
维护成本上升

从工程角度讲，它们本来也该被清理。

我们确实做了一轮拆分和重构，把 shared 代码抽离出来，重新梳理依赖方向。

但结果是：对这个问题完全没有帮助。

第一次 compile 的耗时，没有任何变化。

看起来，Turbopack 对循环依赖已经有了比较成熟的处理机制。
循环依赖值得解决，但它不是这次性能问题的根源。

第二次尝试：Turbopack Tracing

既然靠猜不行，那就上工具。

Next.js 为 Turbopack 提供了官方的 tracing 能力：

https://nextjs.org/docs/app/guides/local-development#turbopack-tracing

在本地启动时，加上一个环境变量即可：

$ NEXT_TURBOPACK_TRACING=1 pnpm dev

再次访问 /home，问题依旧——70 多秒。

但这一次，Turbopack 会在本地生成一个 tracing 文件：.next/dev/trace-turbopack

这是一个二进制文件，不能直接查看。Next.js 提供了一个内部工具：

$ npx next internal trace .next/dev/trace-turbopack

然后，通过浏览器访问：

https://trace.nextjs.org/

（这个“本地起服务 + 在线 UI 查看本地 trace”的设计，老实说有点神奇 😂）

火焰图告诉了我们真相

在 tracing 页面中，把视图切换到 Span in Order，你就能看到完整的编译火焰图。

问题立刻变得非常清晰：

编译 /(shell)/(system)/(withHeader)/(dashboard)/home/page
耗时 70.36 秒

继续点进去看详情：

峰值内存使用：20+ GB
持久化占用：约 5 GB

进一步展开调用栈后，真正的“元凶”出现了。

在最底部、最耗时的两个分支里：

ReduxProvider 在加载 domain.ts

其中：

parse domain.ts
单次耗时 26 秒
执行了两次

光解析这个文件，就吃掉了 52 秒。

domain.ts 到底是什么？

简单来说：
domain.ts 是我们通过 GraphQL Codegen 自动生成的类型文件。

我们希望前端能完整地使用 GraphQL 类型系统，让 TypeScript 的类型推导发挥最大价值，于是把 所有生成的类型 都集中在了这个文件里。

结构大概是这样：

export type Form = {
  id: string
  title: string
  createdAt: Date
  ...
}

export type User = {
  id: string
  name: string
  email: string
  ...
}

乍一看没什么问题。

直到我看了一眼文件大小：

$ ls -la src/typings/domain.ts
14M Dec 16 10:33 src/typings/domain.ts

14MB。

TypeScript 解析一个 14MB 的类型文件，耗时 26 秒，
其实非常合理。

为什么它会膨胀到这么大？

我们使用的 codegen 配置是这样的：

schema: http://localhost:3000/graphql
documents:
  - 'src/lib/api/graphql/**/*.graphql'
generates:
  src/typings/domain.ts:
    plugins:
      - 'typescript'
      - 'typescript-operations'

简单解释一下这两个插件的区别：

typescript
- 根据 GraphQL schema
- 生成完整的类型定义
typescript-operations
- 根据前端实际使用的 query / mutation
- 生成精确到字段级别的返回类型

理论上，这是一个很合理、也很常见的组合。

举个例子，假如你定义了一个 Form 类型

Form {
  id
  title
  createdAt
}

然后你的前端，有一个 query，仅仅获取 Form 的基本信息：

query GetForm {
  form {
    id
    title
  }
}

这种情况下，typescript 会根据 schema 来生成一个 Form 类型，包含所有 schema 的定义：

export type Form {
  id: string
  title: string
  createdAt: Date
}

同时 typescript-operations 会根据前端的 query，生成一个这个 query 实际用到的字段，对应的类型：

export type GetFormQuery {
  id: string
  title: string
}

这样子的好处是提供了更准确的类型定义，因为你如果调用 GetForm，实际上返回的类型，并不是整个 Form，而是你在 query中显式获取的字段。

我最初怀疑：
是不是这两个插件一起用，导致了大量类型重复？

于是我尝试只保留 typescript-operations。

结果呢？

$ ls -la src/typings/domain.ts
13M Dec 16 11:14 src/typings/domain.ts

只小了一点点。
显然，问题不在这里。

真正的问题：Fragment 被“无限展开”了

直到我重新仔细看了一眼生成的 domain.ts，才发现一个被忽略已久的细节：

Fragment 的类型被完全 inline 展开了。

在业务中，我们大量使用 Fragment 来复用字段，比如：

fragment FormBasic on Form {
  id
  title
  createdAt
}

我们有 GetForm 这个 query，以及 CreateForm、UpdateForm 两个 mutation，他们都最终请求了 FormBasic 类型。

query GetForm($formToken: ID) {
  form(id: $formToken) {
    ...FormBasic
    ...
  }
}

mutation CreateForm($input: CreateFormInput!) {
  createForm(input: $input) {
    form {
      ...FormBasic
      ...
    }
  }
}

mutation UpdateForm($input: UpdateFormInput!) {
  updateForm(input: $input) {
    form {
      ...FormBasic
      ...
    }
  }
}

但在生成的类型里，它们变成了这样：

export type GetFormQuery {
  form: {
    id: string
    title: string
    createdAt: Date
  }
}

export type CreateFormMutation {
  form: {
    id: string
    title: string
    createdAt: Date
  }
}

export type UpdateFormMutation {
  form: {
    id: string
    title: string
    createdAt: Date
  }
}

每一个使用 Fragment 的地方，类型都被重新平铺了一遍。

在一个业务复杂、字段很多、Fragment 被大量复用的系统里——
这几乎注定会导致类型文件“爆炸”。

解决方案：inlineFragmentTypes = combine

GraphQL Codegen 其实早就考虑到了这个问题。

在文档里，我找到了这个配置项：

https://the-guild.dev/graphql/codegen/plugins/typescript/typescript-operations#inlinefragmenttypes

inlineFragmentTypes: 'combine'

含义很直观：

inline（默认）：Fragment 类型直接展开
combine：复用 Fragment 类型引用
mask：用于 Fragment Masking（这里不展开）

我们把配置改成这样：

schema: http://localhost:3000/graphql
documents:
  - 'src/lib/api/graphql/**/*.graphql'
generates:
  src/typings/domain.ts:
    plugins:
      - 'typescript-operations'
    config:
      inlineFragmentTypes: 'combine'

重新生成类型文件。

效果立竿见影

类型变成了我们真正想要的样子：

export type FormBasicFragment {
  id: string
  title: string
  createdAt: Date
}

export type GetFormQuery {
  form: FormBasicFragment
}

export type CreateFormMutation {
  form: FormBasicFragment
}

export type UpdateFormMutation {
  form: FormBasicFragment
}

再看文件大小：

$ ls -la src/typings/domain.ts
1.4M Dec 16 11:39 src/typings/domain.ts

14MB → 1.4MB

十分之一。

再次启动本地服务：

GET /home 200 in 17.1s (compile: 15.8s)

从 70 多秒，直接降到 17 秒。

是的，17 秒依然不完美。
但对于这样规模的项目来说，这已经是一个值得庆祝的进步 🎉

而且在新的 Turbopack tracing 中，parse domain.ts 已经不再是瓶颈。

后续与思考

这次优化：

只改了一行配置
不影响任何运行时代码
不影响业务逻辑

我们完整跑了一遍：

lint
type-check
自动化测试

全部通过。

值得一提的是，Codegen 文档里也明确说明：

大多数情况下，inline 是默认且更安全的选择。

combine 在极深嵌套、复杂 list 类型下，可能会暴露出一些类型问题。
我们会在后续继续观察、验证，并单独总结。

但至少在当前的业务形态下，它解决了一个非常真实的问题：

类型文件的无节制膨胀，正在拖慢构建系统。

总结

复杂 GraphQL Schema + 默认 codegen 行为
→ 生成了巨大的类型文件
巨型 domain.ts
→ 成为 Turbopack 编译的性能瓶颈
通过调整 inlineFragmentTypes
→ 类型文件体积下降 90%
→ 本地首次编译时间显著缩短

这是一行配置，换来整个团队的开发体验提升。

如果你的项目也遇到了类似的 Turbopack “第一次请求特别慢”的问题，
不妨从这里检查一下。

Debug issues with legacy browser on macOS

2024-01-21T14:54:28Z

最近，我们在忙着打造全新的产品，金数据 5.0，将会给表单工具、业务系统搭建工具领域带来全新的行业标准。我们会陆陆续续分享在这个过程中的一些经验和故事。

今天分享下我们是怎么在 macOS 上调试 iOS 11 Safari 的问题的。

问题

非常不幸的是：

XCode 15（macOS 14）是无法安装 iOS 11 的模拟器的
我们运行着 iOS 11 的 iPhone 7 连接电脑后，无法调出 Safari 的开发者工具

除了使用 frpc + browserstack 这种方式外，我们还有什么办法可以调试 iOS 11 Safari 的问题呢？

解决方案

通过一番搜索，我们找到了一个解决方案：Inspect，他可以利用内置的 Chrome Devtool，来调试 iOS 11 Safari 的问题。相较于 ios-webkit-debug-proxy，Inspect 更加简单稳定。

你的解决方案是什么？

你是怎么解决这类问题的呢？期待你的分享。

The guardian of Server Component in Next.js

2023-12-23T07:41:48Z

在服务端开发中，鉴权、认证、校验等业务规则检查是不可或缺的，但当这些代码与 Server Component 结合时，我们应该如何更优雅地处理呢？🤔

通常最简单的处理方式就是通过增加 IF/ELSE 控制流来完成业务规则检查。

const DashboardPage = async () => {
  const isUserLoggedIn = await fetchUser()
  
  if (!isUserLoggedIn) {
    redirect('/login')
  }
  
  const canUseDashboard = await queryFeatureFlag('dashboard')
  
  if (!canUseDashboard) {
    redirect('/access-denied')
  }
  
  return <Dashboard />
}

但当业务规则检查越来越多的时候，更恰当的方式是使用 Container Pattern ，通过分离关注点的方式，增强代码的可维护性。

const UserLoggedGuard = async ({ children }) => {
  const isUserLoggedIn = await fetchUser()
  
  if (!isUserLoggedIn) {
    redirect('/login')
  }
  
  return children
}

const CanUserDashbordGuard = async ({ children }) => {
  const canUseDashboard = await queryFeatureFlag('dashboard')
  
  if (!canUseDashboard) {
    redirect('/access-denied')
  }
  
  return children
}


const DashboardPage = async () => {
  return (
    <UserLoggedGuard>
      <CanUserDashbordGuard>
        <Dashboard />
      </CanUserDashbordGuard>
    </UserLoggedGuard>
  )
}

但带来的另一个问题就是，一旦 Guard 组件过多，对业务组件 JSX 的侵入就变得很严重。

const DashboardPage = () => {
  return (
    <UserLoggedGuard>
      <CanUserDashbordGuard>
        <ParamsSafeGuard>
          <ForbiddenAccessGuard>
            <Dashboard />
          </ForbiddenAccessGuard>
        <ParamsSafeGuard>
      </CanUserDashbordGuard>
    </UserLoggedGuard>
  )
}

看到上面的代码，你脑海里是否又响起了熟悉的“Hadoken!” 🫨

此时为了避免 Guard 组件对业务组件的侵入，在设计上可以考虑根据 Server Component 的特性把这些 Guard 抽离出来，变成这样：

const DashboardPage = () => {
  return (
    <Dashboard />
  )
}

export default composeGuard(
  UserLoggedGuard, 
  CanUserDashbordGuard, 
  ParamsSafeGuard,
  ForbiddenAccessGuard,
  DashboardPage,
)

现在看起来 Dashboard 的业务代码是不是更干净了？Guard 组件也更集中，方便统一查看检查规则。

那 composeGuard 要如何实现呢？在 Server Component 体系下，每个 Guard 都是一个独立的 Server Component，也是一个个的异步函数。想要实现这个逻辑也非常简单，就是把一堆异步函数放在一起，按顺序执行。我们可以按照这样的思路来实现：

首先在 TS 中定义出来我们需要的类型：

import type React from 'react'
import type { ParsedUrlQuery } from 'node:querystring'

export type NextPageProps = {
  params: NodeJS.Dict<string>
  searchParams: ParsedUrlQuery
  children: React.ReactNode
}

export type NextPage<T extends NextPageProps> = (props: T) => Promise<React.JSX.Element | null>

之后再来实现 compose 函数：

const composeGuard = (...guards: NextPage[]): NextPage => {
  return async (props: NextPageProps) => {
     for (const guard of guards) {
         return await guard(props)
    }
  }
}

💂 composeGuard 现在的逻辑非常简单，就是生成一个新的 ServerComponent，然后在这个新生成的 Server Component 中逐个运行给定的 guard。

但是 Bug 🐛 也非常明显，因为我们直接 return 了第一个 guard，导致现在 composeGuard 的结果只会渲染出第一个 Component 💩。但我们期望的是 guard 在业务规则检查通过之后就运行后面的 Guard，直到所有的 guard 都运行完为止。这里我们可以参考 Next.js 中 notFound 和 redirect 的 API 设计，通过抛异常来明确程序行为。

这里我们先定义出 NextGuardError

class NextGuardError extends Error {}

export function nextGuard(): never {
  throw new NextGuardError('go to next guard')
}

export function isNextGuardError(error: any): error is NextGuardError {
  return error instanceof NextGuardError
}

之后再补全 composeGuard 的代码逻辑：

type ExtractNextPageProps<T extends NextPage<any>[]> = T extends Array<NextPage<infer U>> ? U : never

function composeGuard<T extends NextPage<any>[]>(...guards: T) {
  return async function ComposeGuardWrapper(props: ExtractNextPageProps<T>) {
    for (const guard of guards) {
      try {
        return await guard(props)
      } catch (error) {
        if (isNextGuardError(error)) {
          continue
        }
        throw error
      }
    }
    return null
  }
}

至此，我们的 composeGuard 基本就已经写完了，使用起来也很简单。以CanUserDashbordGuard 为例：

const CanUserDashbordGuard = async ({ children }) => {
  const canUseDashboard = await queryFeatureFlag('dashboard')
  
  if (!canUseDashboard) {
    redirect('/access-denied')
  }
  
  nextGuard() // 逻辑检查通过之后，执行后续 guard
}

在业务逻辑检查中，如果不符合条件可以直接渲染 UI 告知用户，也可以使用 notFound 或者 redirect 跳转到其他的页面中。但逻辑检查通过之后，可以使用 nextGuard 继续执行后续的 guard。

回过头来再看一下之前的代码示例：

const DashboardPage = () => {
  return (
    <Dashboard />
  )
}

export default composeGuard(
  UserLoggedGuard, 
  CanUserDashbordGuard, 
  ParamsSafeGuard,
  ForbiddenAccessGuard,
  DashboardPage,
)

现在用户打开 Dashboard 页面时，会顺序经过 UserLoggedGuard、CanUserDashbordGuard、ParamsSafeGuard 和 ForbiddenAccessGuard。但这些 guard 全部运行结束之后就会进入到 DashboardPage 执行核心的业务逻辑。这样，通过 Server Component 守卫，我们能够更清晰、更优雅地组织和处理业务逻辑，使代码更易读、易维护。

技术人怎么有效地做沟通？

2023-01-19T10:01:04Z

作为一个与实现打交道的技术人，很容易在沟通中陷入细节，带来的结果就是有观点无法表述出来，丢失了沟通的目的，当然也增加了沟通的时间。

分享我一直在实践的 tips，帮助大家更有效地做沟通。

方法

先说结论；如果是一个问题，那么先问问题。比如针对这个问题，我们有这么 2 个方案，需要大家来做决策。
分层地做解释，注意，每层不超过 3 个观点，不超过 3 层。不然超过 3 个信息，人脑就很难记住了。
层层递进

这些的理论基础其实就是结构化思维，当然这个理论适用的人群，覆盖的使用范围更广。更多内容推荐阅读『金字塔原理』这本书。

当然，沟通前的准备，以及做沟通的心态同样不可忽视。准备就不说了，那更像是个 checklist，作为技术人一看就懂。

心态

心态上，就是同理心，尤其是面向 PM，UX，甚至是用户时，摘掉我们工程师的帽子，想想他的知识领域是什么，想想他平时经常说什么。

最后，回到最基础的 - Open Mind。

react-native 从 v0.61.4 升级到 v0.70.6 踩坑指南

2022-12-13T03:49:04Z

需求背景

目前，Cyborg项目中的react-native 已经很久都没有更新，还停留在v0.61.4版本，而现在最新版本已经升级到v0.70.6了；
为了解决项目工程化配置（bundle、build）阶段，遇到的各种未知报错，和优化繁琐且复杂的启动流程；
跟上时代步伐，与时俱进；享受react-native更新之后，带来的性能提升和用户体验；

例如，在之前的react-native v0.61.4（历史版本）中，当我们需要快速修复一个bug，总是很苦恼在应用bundle或者build阶段，遇到有各种奇怪的问题，例如一个典型的 sharp :

当我们在构建发布版本时，遇到的这种类似的问题，其实和我们项目中用到的关系并不大，也就是我们所说的，其实并不关心这些，作为开发者，我们只需要关注业务/功能代码本身逻辑，其他的交给 RN 就好了，它会帮我们做android和ios平台兼容处理。可事实上？并不是这样。。。

又或者在项目clone下来之后，yarn install 安装失败就已经让你劝退了，这又是什么原因？？？也许你会发现是node版本太高了，需要你降级到node 14及以下版本，才能安装成功，是的，这又是sharp模块安装，需要低版本的node才能安装成功。

然而这些，只是暴露的部分已知的小问题，大多数都在版本迭代中修复了，这也是我们这次升级的目标之一，其次，由于开发者们所使用的机型、mac系统，Android Studio、Xcode 版本都不一致。导致问题出现的原因千奇百怪，这也是我们接下来需要探索和解决的问题。

当然，最直接的原因就是换了mac M1之后，项目跑不起来了，果断升级！🤔🤔🤔

寻找解决方案

在我们一波分析之后，首先做的事情就是先升级 react-native，这里有一份帮助开发者升级的官方食用指南

它能帮助我们，在升级过程中清晰的知道，中间每个版本发生大的变化和更新。

在第一次尝试升级失败之后，再次发起挑战，升级之前在stackoverflow、 github查阅相关资料，把前面各种尝试失败的经验记录下来。（千里之行，始于足下）

先升级react-native、react版本，接着升级babel、eslint 和jest相关插件。按照helper文档一步步走，好了之后。先在android studio build一次，看有哪些问题（后面有记录）

过程中遇到的问题

一句话总结下来就是，第三方依赖包的更新和 gradle升级以及修改第三方包升级之后语法不兼容的问题。

值得一提的是，在react-native升级之后，由原来的JavaScriptCore更换成新的Hermes引擎，这次更换，用官方语言来总结一下：

Hermes is an open-source JavaScript engine optimized for React Native. For many apps, using Hermes will result in improved start-up time, decreased memory usage, and smaller app size when compared to JavaScriptCore. Hermes is used by default by React Native and no additional configuration is required to enable it.

简而言之，就是速度更快，体积更小。

其他依赖包主要的更新包括：

jcore-react-native 处理RN升级之后，ts和lint语法报错问题
react-native-screens 处理RN升级之后，ts和lint语法报错问题
react-native-qrcode-svg 处理RN升级之后，ts和lint语法报错问题
react-native-reanimated，解决应用启动之后的warning警告, 链接。

在 android studio build 成功之后，应用启动起来，算是长舒了一口气，可后面的问题，又在打包apk时，问题发生了，花了半天时间排查。最后定位到问题原因是缺少一个bundle文件（由于一开始忽略了一个细节性错误，导致没找到问题所在，属实我的锅。）

👮👮👮 ：测试过程中发现，某些android设备打开应用会出现闪退，例如 vivo、oppo机型。最后真机debug发现， @sentry/react-native 包版本比较低，在android新版本机型上会出现语法不兼容的问题（参考）。截图如下：

解决方案：升级sentry版本` "@sentry/react-native": "^4.9.0"`，最后build成功，测试一切正常。

问题记录：

总结

问题大多数是在build阶段遇到的，虽然说这次升级已经完成了，但后面还有一些第三方依赖还没来得及升级，如果感兴趣的同学，也可以顺便尝试一下，另外我们有些的库版本比较老了，现在有些已经不维护了，我们得找一些比较好的库替代，这也算是一个挑战。（路漫漫其修远兮，吾将上下而求索……）

参考资料

Draw tech diagrams clearly

2022-09-14T13:40:24Z

沟通永远都是件困难的事情，尤其是在技术问题上。即使是技术人员之间的表达，也会因为其复杂且抽象的特性，而变地异常的艰难。

因此，我们大多数时候会选择将内容画出来，来辅助沟通的各方更容易地理解。

而如何清晰地、准确地可视化表达，也需要一定的技巧和原则：

整洁性

清晰地书写

尤其是手写的时候，往往因为着急或不自信，写下的文字难以辨认，这反而增加了对方理解的难度。

不要害怕慢，一笔一划地书写。

线条不要有交叉

否则当内容越来越多时，满屏的线条会像毛线球一样混乱。

一致性

颜色、图形

和代码一样，需要从始至终贯穿一样的风格。相同的模块使用相同的图形、颜色，有助于降低理解的复杂度。

箭头指向

这点尤为重要。在表达从属关系、数据流向时，箭头有助于我们表达方向。但我们也经常会因为不注意而前后表达不一致。

解释性

图例

我发现，这点更大的作用是时候再回看时，能够起到提醒的作用。不然我们很可能要重来一遍才能回忆起想要表达的信息。

当然最重要的是，不要嫌麻烦，不要害怕。大胆地表达才是最重要的。

JavaScript 中与数字相关的奇怪问题

2022-08-02T06:25:18Z

First of All

可以看下下面的几个问题然后给出自己的答案

console.log(0.1 + 0.2)

答案

0.30000000000000004

console.log(parseInt(0.0000005))

答案

setTimeout(() => {
  console.log("setTimeout First")
}, 2147483647)

setTimeout(() => {
  console.log("setTimeout Next")
}, 2147483648)

答案

setTimeout Next

如果你学习过前端八股文那么对 0.1 + 0.2 这个问题应该都已经有了条件反射, 至少也能说个 IEEE-754, 但是后面这两个问题如果没有遇到过就只能挠头了.

Why

我们一个问题一个问题来看

0.1 + 0.2
这个问题应该是出现频率比较高的了, 结论就是 0.1 与 0.2 用的二进制不能完美的表达出来, 只能根据精度舍入得到近似数, 而这两个近似数得到的也是一个近似数.
需要说明的是这个问题并不是 JavaScript 独有, Floating Point Math 展示了其他语言中 0.1 + 0.2 的结果.
这个部分如果想深入理解可以参考为什么 0.1 + 0.2 = 0.300000004 ？
setTimeout(callback, 2147483647)
这个问题其实能遇到的机率比较小, 因为在业务开发的时候很少会指定这么大的 timeout, 不过出于好奇可以了解这个边界在哪里.
setTimeout 这个 API 使用一个 32 位的整数来存储其延迟值，所以任何高于这个值的东西都会引起问题
PS: 32 位的证书中有 1 位表示符号, so 这个数为 Math.pow(2, 32-1) - 1
parseInt(0.0000005)
这个问题, 如果注意 parseInt 这个 API 参数的类型就能很好的避免了.
parseInt 这个 API 接收的第一个参数的类型是 string. 如果传入的参数不是一个字符串，则将其转换为字符串 (使用 ToString抽象操作).
在 number to string 的这个过程中, 如果出现以下两种情况则会用科学记数法表示
1. 小于 1 且小数点后面带有 6 个 0 以上的浮点数值
2. 整数位数字多于 21 位
那么当你 parseInt(0.0000005) 其实就是在 parseInt('5e-7'), 而 parseInt('5e-7') 会忽略掉 'e-7'
所以 parseInt(0.0000005) 的结果为 5

So

在日常的 Coding 中如果碰到和数字相关的内容需要提高警惕

小数
🌰：0.1、0.2
特别大的数
🌰：2147483648（2 的 32 次方减 1）
数字的加减乘除
🌰：0.1 + 0.2、1111.11 + 1111.11 + 1111.11 + 1111.11 + 1111.11
调用某些 API 的时候需要注意参数的类型 , 避免隐式类型的转换
🌰：parseInt(0.0000005)

And

本 Issue 会持续搜集 JavaScript 中与数字相关的奇怪问题 ~

CKEditor5食用指南

2022-07-05T02:23:15Z

CKEditor5简介

CKEditor 5 可以提供任何WYSIWYG（所见即所得）类型的编辑器。从类似于 Google Docs 和 Medium 的在线编辑器，到类似于 Slack 或 Twitter 的应用程序，CKEditor 5 编辑框架为每个用户提供了定制的和开箱即用的解决方案。这个具有 MVC 架构、自定义数据模型和虚拟 DOM 的现代 JavaScript 富文本编辑器是在 ES6 中重新开始编写的，具有出色的 webpack 支持。

编辑器类型

引入方式

官方

优势：创建方便，能及时使用官方最新更新。
缺陷：第一种的定制化程度不高，第二种配置复杂，且插件ck5相关的插件代码会耦合到应用项目里。

我们项目的引入方式

我们项目中使用，包括数据模型、插件交互、细节样式等都需要极高的定制化，且需要良好的代码隔离，理想方向是构建出来的ck5插件能用于我们的多个项目中且保持统一。
上述两种方式都不能很好的满足我们的需求，于是我们进行了：

fork代码到私有代码库
在此仓库中进行各种定制化改造、自定义插件扩展、官方代码合并升级、打包发布等操作。
发布到私有依赖库
在项目中通过依赖安装，将构建打包后的ck5引入项目之中进行使用。

CKEditor5框架介绍

由核心编辑器框架、编辑引擎、UI库组成

核心编辑器框架 Core editor architecture

@ckeditor/ckeditor5-core ，由以下几个部分组成。

编辑器类 Editor Classes

该类Editor代表编辑器的基础。它是应用程序的入口点，粘合所有其他组件。它提供了一些您需要了解的属性：

config– 配置对象。
plugins和commands– 加载的插件和命令的集合。
model –编辑器数据模型的入口点。
data– 数据控制器。它控制如何从文档中检索数据并在其中设置数据。
editing– 编辑控制器。它控制如何将模型呈现给用户进行编辑。
keystrokes– 击键处理程序。它允许将击键绑定到动作。

除此之外，编辑器还公开了一些方法：

create()– 静态create()方法。编辑器构造函数受到保护，您应该使用此静态方法创建编辑器。它允许初始化过程是异步的。
destroy()– 销毁编辑器。
execute()– 执行给定的命令。
setData()–getData()一种从编辑器中检索数据并在编辑器中设置数据的方法。数据格式由数据控制器的数据处理器控制，它不需要是字符串（如果您实现这样的数据处理器，它可以是例如 JSON ）。例如，请参阅如何生成 Markdown 输出。

插件 Plugins

每个功能都由插件实现或至少启用。
插件是高度精细的。
插件对编辑器了如指掌。
插件应该尽可能少地了解其他插件。

命令 Commands

命令是动作（回调）和状态（一组属性）的组合。
所有命令都需要从Command类继承。需要将命令添加到编辑器的命令集合中，以便使用该Editor#execute()方法执行它们。
示例：

class MyCommand extends Command {
    execute( message ) {
        console.log( message );
    }
}

class MyPlugin extends Plugin {
    init() {
        const editor = this.editor;

        editor.commands.add( 'myCommand', new MyCommand( editor ) );
    }
}

调用editor.execute( 'myCommand', 'Foo!' )将打印Foo!到控制台。

事件系统和可观察对象 Event system and observables

CKEditor 5 具有基于事件的架构，因此您可以在任何地方查找EmitterMixin和ObservableMixin混合。这两种机制都允许解耦代码并使其可扩展。

大多数已经提到的类要么是发射器，要么是可观察的（可观察的也是发射器）。发射器可以发出（触发）事件并监听它们。

class MyPlugin extends Plugin {
    init() {
        // Make MyPlugin listen to someCommand#execute.
        this.listenTo( someCommand, 'execute', () => {
            console.log( 'someCommand was executed' );
        } );

        // Make MyPlugin listen to someOtherCommand#execute and block it.
        // You listen with a high priority to block the event before
        // someOtherCommand's execute() method is called.
        this.listenTo( someOtherCommand, 'execute', evt => {
            evt.stop();
        }, { priority: 'high' } );
    }

    // Inherited from Plugin:
    destroy() {
        // Removes all listeners added with this.listenTo();
        this.stopListening();
    }
}

第二个监听器'execute'展示了 CKEditor 5 代码中非常常见的做法之一。

除了用事件装饰方法外，可观察对象还允许观察它们选择的属性。例如，Command该类通过调用使其成为#value可#isEnabled观察的set()：

class Command {
    constructor() {
        this.set( 'value', undefined );
        this.set( 'isEnabled', undefined );
    }
}

mix( Command, ObservableMixin );

const command = new Command();

command.on( 'change:value', ( evt, propertyName, newValue, oldValue ) => {
    console.log(
        `${ propertyName } has changed from ${ oldValue } to ${ newValue }`
    );
} )

command.value = true; // -> 'value has changed from undefined to true'

Observables 还有一个被编辑器广泛使用的特性（尤其是在 UI 库中）——将一个对象的属性值绑定到其他一些属性的值或（一个或多个对象的）属性值的能力。当然，这也可以通过回调来处理。

假设target和source是可观察的并且使用的属性是可观察的：

target.bind( 'foo' ).to( source );

source.foo = 1;
target.foo; // -> 1

// Or:
target.bind( 'foo' ).to( source, 'bar' );

source.bar = 1;
target.foo; // -> 1

编辑引擎 Editing engine

@ckeditor/ckeditor5-engine

MVC架构

三层：模型、控制器和视图。有一个模型文档被转换为单独的视图——编辑视图 Editing view和数据视图 Data view。这两个视图分别代表用户正在编辑的内容（您在浏览器中看到的 DOM 结构）和编辑器输入和输出数据（以插入的数据处理器可以理解的格式）。两个视图都具有虚拟 DOM 结构（自定义的类似 DOM 的结构），转换器和功能在其上工作，然后渲染到 DOM。

绿色块是编辑器功能（插件）引入的代码。这些功能控制对模型进行哪些更改，如何将它们转换为视图以及如何根据触发的事件（视图和模型的事件）更改模型。
由于此部分内容太多，接下来的内容只用部分实现代码来描述这三层，详细文档请参阅Editing engine

模型 Model

定义一个模型：

const schema = this.editor.model.schema;
schema.register( 'stock', {
	allowWhere: '$text',
	isInline: true,
	isObject: true,
	allowAttributes: [ 'code', 'type' ]
} );

在编辑器的model.schema中注册该模型，包含了基础属性和接受的属性，详细的属性含义参见schema文档

视图 View

分为编辑视图Editing view 和数据视图Data view。
简单来说，编辑视图是编辑富文本时用户看到并可以编辑的 DOM。数据视图editor.getData()调用或editor.setData()得到或使用的富文本内容。

editor.editing;                 // The editing pipeline (EditingController).
editor.editing.view;            // The editing view's controller.
editor.editing.view.document;   // The editing view's document.
editor.data;                    // The data pipeline (DataController).

转换 Conversion

连接模型和视图。

数据向上转换

将数据加载到编辑器。

// Data View -> Model
conversion.for( 'upcast' )
	.elementToElement( {
		view: {
			name: 'img',
			attributes: {
				'data-img-role': 'stock'
			}
		},
		model: ( viewElement, { writer } ) => {
			const code = viewElement.getAttribute( 'data-stock-code' );
			const type = viewElement.getAttribute( 'data-stock-type' );
			return writer.createElement( 'stock', {
				code, type
			} );
		}
		// converterPriority: 'high'
	} );

数据向下转换

从编辑器中检索数据。

// Model -> Data view
conversion.for( 'dataDowncast' )
	.elementToElement( {
		model: 'stock',
		view: createStockView
	} );

// Create view for data
function createStockView( modelItem, { writer } ) {
	const code = modelItem.getAttribute( 'code' );
	const type = modelItem.getAttribute( 'type' ) || 'min';
	const stockView = writer.createContainerElement( 'img', {
		'data-img-role': 'stock',
		'data-stock-type': type,
		'data-stock-code': code,
		src: judgeSrc( code, type )
	} );

	return stockView;
}

编辑向上转换

将编辑器内容呈现给用户进行编辑。

// Model -> Editing View (element)
conversion.for( 'editingDowncast' )
	.elementToElement( {
		model: 'stock',
		view: ( modelItem, { writer } ) => {
			const widgetElement = createStockEditingView( modelItem, writer );
			return toWidget( widgetElement, writer, 'span' );
		}
	} );

// Create view for editor
function createStockEditingView( modelItem, writer ) {
	const stockCode = modelItem.getAttribute( 'code' );
	const type = modelItem.getAttribute( 'type' ) || 'min';
	const stockView = writer.createContainerElement( 'img', {
		src: judgeSrc( stockCode, type )
	} );

	return stockView;
}

以上代码就简单实现了我们 data view -> model -> editing view -> data view 的转换，更多的conversion内容请参阅conversion 文档

UI 库

CKEditor 5 的标准 UI 库是@ckeditor/ckeditor5-ui. 它提供了允许构建与生态系统的其他组件无缝集成的模块化 UI 的基类和助手。详细的UI创建和通用UI组件请参阅UI library，这里只讲述几个通用组件的基础用法。
使用 LabeledInputView 创建一个input：

this.stockInputView = this._createStockInput()
_createStockInput() {
		const t = this.locale.t;

		// Create equation input
		const stockInput = new LabeledInputView( this.locale, InputTextView );
		const inputView = stockInput.inputView;
		stockInput.infoText = t( '请输入股票代码' ); // 提示信息

		const onInput = () => {
			if ( inputView.element != null ) {
				const stockInput = inputView.element.value.trim();

				this.saveButtonView.isEnabled = !!stockInput;
			}
		};

		inputView.on( 'render', onInput );
		inputView.on( 'input', onInput );

		return stockInput;
	}

获取input的值

get code(){
        return this.stockInputView.inputView.element.value
}

校验值、清空报错信息

validate(){
        const maxLength = 8;
        if( this.code.length > maxLength ) {
                this.stockInputView.errorText = '代码长度不正确';
        }
}

resetFormStatus() {
        this.stockInputView.errorText = null;
}

CKEditor5提供很好的UI规范，很多组件都可以直接拿来使用，如果要自定义组件，请尽量遵循CKEditor5的设计规范，尽量使用CSS变量。

我们如何开发一个CKEditor5插件

运行本地开发服务器

git clone git@matrix.jinshuju.co:engineering/jinshuju/editorx.git
cd editorx 
yarn
cd packages/ckeditors-build-classic
yarn start

tips: 在根目录安装依赖，避免插件版本冲突。

文件结构

ckeditor5-xxx //xxx为插件名
│   README.md
│
└───docs //文档
│ 
│   
└───lang //多语言文件
│ 
│  
└───src
│   │ 
│   │   xxxediting.js //定义model 及转换
│   │   xxxcommand.js //定义command
│   │   xxxui.js //关联ui
│   │
│   └───view //视图文件
│     
│      
└───theme //样式文件、icons

代码示例

点击查看项目代码或者官方示例

总结

CKEditor5 本身拥有良好且完善的规范，在这套规范的基础上我们能很快的上手开发和维护插件，由于其良好的通用性，我们可以开发更多有趣的或者实用的插件共享到开源社区。

Google IO for web platform

2022-05-15T12:43:29Z

一、 What's new for the web platform

直接上视频地址 What's new for the web platform，然后我简单的根据视频的内容总结了一下 HTML 、CSS 和 JavaScript 的新特性。

二、HTML 和 CSS 新特性

accent-color

这个属性可以修改例如原生的单选、多选、范围等组件的颜色。accent-color MDN

接下来我们来实际体验一下，代码如下：在线预览

import React, { useState } from 'react';
import './style.css';

export default function App() {
  const [color, setColor] = useState('#50E3C2');

  return (
    <div className="container">
      <div className="left">
        <div>
          <input type="radio" style={{ accentColor: color }} />
          <input type="radio" checked style={{ accentColor: color }} />
        </div>
        <div>
          <input type="checkbox" style={{ accentColor: color }} />
          <input type="checkbox" checked style={{ accentColor: color }} />
        </div>
        <div>
          <input
            className="range"
            type="range"
            style={{ accentColor: color }}
          />
        </div>
      </div>
      <div className="right">
        <input
          className="color"
          type="color"
          value={color}
          onChange={(event) => setColor(event.target.value)}
        />
      </div>
    </div>
  );
}

我们可以通过颜色选择器选择任意的颜色来修改原生组件的颜色了。如下图所示：

dialog

新版的 dialog 内置了一些可访问性和可用性的功能。dialog MDN

我们来实际体验一下，代码如下：在线预览

<html>
  <head>
    <meta charset="UTF-8" />
  </head>
  <body>
    <dialog id="dialog">
      <form method="dialog">
        <div>
          <label
            >name:
            <input type="text" name="name" />
          </label>
        </div>
        <div>
          <label
            >email:
            <input type="email" name="name" />
          </label>
        </div>
        <div>
          <button value="cancel">Cancel</button>
          <button id="confirm" value="default">Confirm</button>
        </div>
      </form>
    </dialog>
    <button id="open">Open dialog</button>
    <output />
    <script>
      const open = document.querySelector('#open');
      const dialog = document.querySelector('#dialog');
      const output = document.querySelector('output');
      open.addEventListener('click', () => {
        dialog.showModal();
      });

      dialog.addEventListener('close', function onClose() {
        output.value = dialog.returnValue + ' button clicked';
      });
    </script>
  </body>
</html>

新的 dialog 可以使用 Esc 来关闭弹窗，还可以通过 dialog 的返回值来感觉我们点击了什么按钮。

datetime-local

datetime-local 这个 API 存在很久了，这一次进行了补全和完善。datetime-local MDN

我们来实际体验一下，代码如下：在线预览

<form>
    <label for="party">输入日期和时间：</label>
    <input id="party" type="datetime-local" name="partydate">
</form>

我们可以直接输入或者通过点击呼出弹窗来修改日期。

除了这些基本功能我们还可以添加最大和最小值等功能，由于篇幅原因这里挖一个坑，以后会有一篇来介绍这个 API。

image lazy loading

记得在我刚入行那时还在使用 jquery image loading，现在已经得到浏览器的支持。iamge lazy loading MDN

那就来看看浏览器的体验如何，代码如下：在线预览

<html>
  <head>
    <meta charset="UTF-8" />
  </head>
  <body>
    <div>
      <img
        src="https://picsum.photos/id/1/300/800"
        alt="pic"
        loading="lazy"
        width="300"
        height="800"
      />
    </div>
   ...............
    <div>
      <img
        src="https://picsum.photos/id/20/300/800"
        alt="pic"
        loading="lazy"
        width="300"
        height="800"
      />
    </div>
  </body>
</html>

这里我加载了 20 张图片，但是 chrome 开始只会加载 2 张图片，随着我们滚动的变化，图片就会继续加载。如图：

这里也只是简单介绍一下，后面会专门开一个坑来详细介绍。

aspect-ratio

如果是经常开发移动网站的同学应该多少会接触这个属性，aspect-ratio 属性可以设置容器的横纵比。aspect-ratio MDN

实际应用一下这个属性，代码如下：在线预览

<html>
  <head>
    <meta charset="UTF-8" />
    <style>
      .bg {
        padding: 20px;
        color: #fff;
        aspect-ratio: 16/9;
        background: red;
      }
    </style>
  </head>
  <body>
    <div class="bg">div width aspect-ratio: 16 / 9</div>
  </body>
</html>

使用 aspect-ratio 属性就能创建一个纵横比的容器，在移动端有背景自适应的项目很实用，如图所示：

三、JavaScript 新特性

Structured cloning

这个 API 是给我留下印象最深刻的 API - 深拷贝 structuredClone MDN

直接上手体验一下，代码如下：

const original = { name: 'jsj' };
const clone = structuredClone(original);
console.log(clone === original); // false

更多详细内容可以查看官方文档，这里不做过多介绍。

createImageBitmap

看了这次大会才知道还有这么一个 API（个人水平有待提高 😭），如果是经常处理图片的同学应该不会陌生，他会生成一个 ImageBitmap 格式的数据。createImageBitmap。

这个 API 具体能干嘛呢，以前我们预览图片会使用 URL.createObjectURL，现在也可以使用 createImageBitmap 来实现。

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>图片本地预览示例</title>
</head>
<body>
<input type="file" accept="image/*" onchange="loadFile(event)"/>
<canvas id="image"/>
<script>
  const loadFile = async function async(event) {
    const canvas = document.querySelector('#pic');
    ctx = canvas.getContext('2d');
    const blobToImage = await createImageBitmap(event.target.files[0])
    image.drawImage(blobToImage, 0, 0);
  }
</script>
</body>
</html>

相比使用 URL.createObjectURL 会方便许多。

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>图片本地预览示例</title>
</head>
<body>
<input type="file" accept="image/*" onchange="loadFile(event)"/>
<img id="preview"/>
<script>
    const loadFile = function (event) {
        const image = document.querySelector('#preview')
        const url = URL.createObjectURL(event.target.files[0])
        image.src = url
        image.onload = function () {
            URL.revokeObjectURL(url)
        }
    }
</script>
</body>
</html>

这里我把 2 种 API 的实现方法都放在这里。

at

数组新增了一个 at 方法，接收一个整数值并返回该索引的项目，允许正数和负数。Array.prototype.at()

现在就可以很方便的返回最后一项，代码如下：

const cart = ['apple', 'banana', 'pear'];

cart.at(-1)

// const last = cart[cart.length - 1]
// const last = cart.slice(-1)[0]

相比数组和 slice 方法更加快捷方便。

四、其他

以上只是简单的介绍一个 HMTL、CSS 和 Javascript 的一些新的特性，还有其他新的特性和功能由于篇幅的限制这里就不展开说明，简单列举一些~~挖个坑以后填~~ 😄

最后视频地址 - What's new for the web platform

学习 React-hook-form

2021-12-05T14:23:23Z

一、React 中的表单

首选我们来看 React 官方如何实践表单处理。直接打开官方文档

官方给出了两种不同的表单方案，基于受控组件以及基于非受控组件的表单实现，当然前者会比较常见一些。所有的第三方表单都可以认为是这两种方案的延伸及封装。例如：

1. 受控组件

在 HTML 中，表单元素（如 <input>、 <textarea> 和 <select>）通常自己维护 state，并根据用户输入进行更新。而在 React 中，可变状态（mutable state）通常保存在组件的 state 属性中，并且只能通过使用 setState() 来更新。

我们可以把两者结合起来，使 React 的 state 成为“唯一数据源”。渲染表单的 React 组件还控制着用户输入过程中表单发生的操作。被 React 以这种方式控制取值的表单输入元素就叫做“受控组件”。

简单来说就是指由父组件完全控制该组件的状态及回调函数，子组件的状态变更需要通过回调函数通知到父组件，由父组件完成状态变更后再将新值传回子组件。

表现在代码上就是形如之类的表单组件同时接收 value 以及 onChange 这两个 props 来实现受控。来看一个官方的实例：

class NameForm extends React.Component {
  constructor(props) {
    super(props);
    this.state = {value: ''};

    this.handleChange = this.handleChange.bind(this);
    this.handleSubmit = this.handleSubmit.bind(this);
  }

  handleChange(event) {
    this.setState({value: event.target.value});
  }

  handleSubmit(event) {
    alert('提交的名字: ' + this.state.value);
    event.preventDefault();
  }

  render() {
    return (
      <form onSubmit={this.handleSubmit}>
        <label>
          名字:
          <input type="text" value={this.state.value} onChange={this.handleChange} />
        </label>
        <input type="submit" value="提交" />
      </form>
    );
  }
}

2. 非受控组件

刚说到受控组件所有的状态都由外界接管，非受控组件则恰恰相反，它将状态存储在自身内部，我们可以借用 React 中的 ref 来访问它。同样还是来看一个官方的实例：

class NameForm extends React.Component {
  constructor(props) {
    super(props);
    this.handleSubmit = this.handleSubmit.bind(this);
    this.input = React.createRef();
  }

  handleSubmit(event) {
    alert('A name was submitted: ' + this.input.current.value);
    event.preventDefault();
  }

  render() {
    return (
      <form onSubmit={this.handleSubmit}>
        <label>
          Name:
          <input type="text" ref={this.input} />
        </label>
        <input type="submit" value="Submit" />
      </form>
    );
  }
}

3. 如何选择

关于受控 vs 非受控的选择这个问题 🤔 ，我们就交给 google 帮助我们回答 controlled vs uncontrolled in react 😜

查阅了许多文档，大部分文档认为应该优先考虑受控模式，主要举例说明受控之于非受控更灵活，更符合 react 单向数据流。这里还有一张对比图：

图中列举的一些非受控组件无法覆盖的场景，实际上 ref 配合组件 onChange 是可以做到的，例如字段的实时校验，我们完全可以在字段上挂上监听函数，在其值发生改变的时候进行字段校验，然后通过 ref 控制组件的内部状态。

说了这么多内容，其实问题的关键在于 React 理念，也就是我们常说的单向数据流 ViewModel 🧐 。所以理所应当我们开发的程序也应该是如此。

受控和非受控是站在组件状态(值)的存储位置来看的，本质上受控与非受控的表达能力是相同的，从某种层面上看可以互相实现。

二、React-hook-form

React-hook-form 是一个基于非受控组件实现的表单库。

非受控表单就不是使用 state 单向数据流来控制表单，它是通过 ref 来直接拿到表单组件，从而可以直接拿到表单的值，不需要对表单的值进行状态维护，这就使得非受控表单可以减少很多不必要的渲染。

非受控表单也存在着它的问题，在动态校验、动态修改（联动）方面不是很方便，于是诞生了一个以非受控思想为基础的表单库 react-hook-form，它可以帮助我们解决这些问题。还有一点好处就是基于非受控的组件，完全拥抱原生 HTML 标准。

使用 React 和 React-hook-form 的简单示例：

import React from "react";
import { useForm } from "react-hook-form";

export default function App() {
  const { register, handleSubmit, watch, formState: { errors } } = useForm();
  const onSubmit = data => console.log(data);

  console.log(watch("example")); // watch input value by passing the name of it

  return (
    /* "handleSubmit" will validate your inputs before invoking "onSubmit" */
    <form onSubmit={handleSubmit(onSubmit)}>
      {/* register your input into the hook by invoking the "register" function */}
      <input defaultValue="test" {...register("example")} />
      
      {/* include validation with required or other standard HTML validation rules */}
      <input {...register("exampleRequired", { required: true })} />
      {/* errors will return when field validation fails  */}
      {errors.exampleRequired && <span>This field is required</span>}
      
      <input type="submit" />
    </form>
  );
}

1. 核心原理

表单初始化

我们看到 react-hook-form 在使用时必须先调用 useForm 方法，该方法返回了一系列表单相关的 API。

useForm 方法内部都干了什么 🤔 ？

定义表单状态，例如 isDirty、isValidating、dirtyFields 等。源码位置

const [formState, updateFormState] = React.useState<FormState<TFieldValues>>({
  isDirty: false,
  isValidating: false,
  dirtyFields: {} as FieldNamesMarkedBoolean<TFieldValues>,
  isSubmitted: false,
  submitCount: 0,
  touchedFields: {} as FieldNamesMarkedBoolean<TFieldValues>,
  isSubmitting: false,
  isSubmitSuccessful: false,
  isValid: false,
  errors: {} as FieldErrors<TFieldValues>,
});

创建表单控制器属性及方法。源码位置

if (_formControl.current) {
  _formControl.current.control._options = props;
} else {
  _formControl.current = {
    ...createFormControl(props),
    formState,
  };
}

这里的 createFormControl 方法是 react-hook-form 的核心，表单整体的状态以及表单提供对外的 API，如handleSubmit、setValue、getValues 校验等，以及字段的注册、订阅方法等等都会这里预先处理。

createFormControl 方法定义的内如下，这里只是一部分。

这部分中有一个很重要的内容就是 _subjects 这内部属性，它会创建一个发布订阅的实例，表单字段可以通过该实例进行字段间的通信，达到字段关联的目的。源码位置

let _formState: FormState<TFieldValues> = {
  isDirty: false,
  isValidating: false,
  dirtyFields: {} as FieldNamesMarkedBoolean<TFieldValues>,
  isSubmitted: false,
  submitCount: 0,
  touchedFields: {} as FieldNamesMarkedBoolean<TFieldValues>,
  isSubmitting: false,
  isSubmitSuccessful: false,
  isValid: false,
  errors: {} as FieldErrors<TFieldValues>,
};
let _fields = {};
let _defaultValues = _options.defaultValues || {};
let _formValues = _options.shouldUnregister
  ? {}
  : cloneObject(_defaultValues);
let _stateFlags = {
  action: false,
  mount: false,
  watch: false,
};
let _names: Names = {
  mount: new Set(),
  unMount: new Set(),
  array: new Set(),
  watch: new Set(),
} as Names;
let delayErrorCallback: DelayCallback;
let timer = 0;
let validateFields: Record<InternalFieldName, number> = {};
const _proxyFormState = {
  isDirty: false,
  dirtyFields: false,
  touchedFields: false,
  isValidating: false,
  isValid: false,
  errors: false,
};
const _subjects: Subjects<TFieldValues> = {
  watch: createSubject(),
  array: createSubject(),
  state: createSubject(),
};

createFormControl 方法返回的属性及其方法（_标识的属性和方法属于 react-hook-form 内部方法不对外暴露），就是 useForm 对用户暴露的 API。

return {
  control: {
    register,
    unregister,
    _executeSchema,
    _getWatch,
    _getDirty,
    _updateValid,
    _removeUnmounted,
    _updateFieldArray,
    _getFieldArray,
    _subjects,
    _proxyFormState,
    get _fields() {
      return _fields;
    },
    set _fields(value) {
      _fields = value;
    },
    get _formValues() {
      return _formValues;
    },
    set _formValues(value) {
      _formValues = value;
    },
    get _stateFlags() {
      return _stateFlags;
    },
    set _stateFlags(value) {
      _stateFlags = value;
    },
    get _defaultValues() {
      return _defaultValues;
    },
    set _defaultValues(value) {
      _defaultValues = value;
    },
    get _names() {
      return _names;
    },
    set _names(value) {
      _names = value;
    },
    get _formState() {
      return _formState;
    },
    set _formState(value) {
      _formState = value;
    },
    get _options() {
      return _options;
    },
    set _options(value) {
      _options = {
        ..._options,
        ...value,
      };
    },
  },
  trigger,
  register,
  handleSubmit,
  watch,
  setValue,
  getValues,
  reset,
  resetField,
  clearErrors,
  unregister,
  setError,
  setFocus,
};

观察表单整体的状态变化

接着我们继续回到 useForm 方法，react-hook-form 还会观察表单的变化，来更新表单的状态（例如：校验，是否修改等）。

useSubscribe({
  subject: control._subjects.state,
  callback: (value) => {
    if (shouldRenderFormState(value, control._proxyFormState, true)) {
      control._formState = {
        ...control._formState,
        ...value,
      };

      updateFormState({ ...control._formState });
    }
  },
});

注册字段

注册字段目前 react-hook-form 提供 3 中 API。

register

register 方法提供对外非受控控件 ref 属性及其更改方法。源码位置

const register: UseFormRegister<TFieldValues> = (name, options = {}) => {
    let field = get(_fields, name);

    //...

    return {
      name,
      onChange,
      onBlur: onChange,
      ref: (ref: HTMLInputElement | null): void => {
        field = get(_fields, name, {});

          if (field._f) {
            field._f.mount = false;
          }

          (_options.shouldUnregister || options.shouldUnregister) &&
            !(isNameInFieldArray(_names.array, name) && _stateFlags.action) &&
            _names.unMount.add(name);
      },
    };
  };

Controller 和 useController

Controller 是以 React 组件的形式进行注册，其核心使用的是 useController。源码位置

const Controller = <
  TFieldValues extends FieldValues = FieldValues,
  TName extends FieldPath<TFieldValues> = FieldPath<TFieldValues>,
>(
  props: ControllerProps<TFieldValues, TName>,
) => props.render(useController<TFieldValues, TName>(props));

export { Controller };

这里重点介绍 useController 这个钩子方法。** 在实际项目中会更倾向采用 useController 方式注册字段 **

useController 内部实现很有意思 🤪 。

字段值得获取。

useController 直接使用订阅的方式获取字段的值。源码位置

const value = useWatch({
  control,
  name,
  defaultValue: get(
    control._formValues,
    name,
    get(control._defaultValues, name, props.defaultValue),
  ),
  exact: !isArrayField,
}) as UnpackNestedValue<FieldPathValue<TFieldValues, TName>>;

字段通过 register 注册。

useController 内部还是使用 register 来注册字段，这就是为什么 createFormControl 会返回一个 control 属性并且其中包含了 register 方法。源码位置

useController hook 是为了字段的分布式注册。而不局限于 useForm 的 register。

const registerProps = control.register(name, {
    ...props.rules,
    value,
});

表单提交

react-hook-form 表单的提交相对简单，在内部通过 _formValues 来收集分布式注册的字段的值，然后进行提交。源码位置

const handleSubmit: UseFormHandleSubmit<TFieldValues> =
(onValid, onInvalid) => async (e) => {
  let fieldValues: any = _options.shouldUnregister
    ? cloneObject(_formValues)
    : { ..._formValues };

  _subjects.state.next({
    isSubmitting: true,
  });

  // ....
};

2. 表单交互

当我们进行表单交互 react-hook-form 中又做了什么呢？ 🤔

createFormControl 中的 onChange 方法就是来相应表单交互的变化。源码位置

const onChange: ChangeHandler = async (event) => {
  const target = event.target;
  let name = target.name;
  const field: Field = get(_fields, name);

  if (field) {
    let error;
    let isValid;
    const fieldValue = target.type
      ? getFieldValue(field._f)
      : getEventValue(event);
    
    set(_formValues, name, fieldValue);
	
    //...
    
    const fieldState = updateTouchAndDirty(
      name,
      fieldValue,
      isBlurEvent,
      false,
    );

    const shouldRender = !isEmptyObject(fieldState) || watched;
    
    validateFields[name] = validateFields[name] ? +1 : 1;
    
    field._f.deps && trigger(field._f.deps as FieldPath<TFieldValues>[]);

    shouldRenderByError(false, name, isValid, error, fieldState);
  }
};

这里首先会获取当前值变化的字段信息，然后还会判断该字段是否被 watch ，还有对字段进行 validateFields 操作。

这里总结一下 react-hook-form 基本流程：

表单初始化

表单交互

react-hook-form 都是基于字段级别的渲染：

字段分布式注册，每一个字段的状态由组件自己负责，并不需要数据回流。
表单的内部状态(isDirty、touched、isSubmitting 等)统一用过 Proxy 包装，在初次渲染的时候利用 Proxy 记录用户对于各个状态的订阅情况，不订阅的话变化将被忽略，不引发重新渲染。
对错误进行浅层比较，例如上一轮渲染已经展示了错误信息，如果这一轮渲染错误信息不变的话，则不重新渲染.
虽然 watch 默认会触发全局渲染，不过 useWatch 可以做到不触发全局渲染的情况下通知某个字段的更新，本质上是发布订阅机制。

3. 动态校验以及联动

为了支持动态校验，react-hook-form 在进行表单注册的时候还会将 onChange、onBlur 等事件挂载到表单组件上，保证对与用户输入、修改行为的监听，从而可以对表单校验、表单值监听等进行触发。

非受控表单除了动态校验的问题，还存在联动实现的问题。由于 react-hook-form 不会将表单的值维护在 React 的 state 中，用户输入不会触发其他组件的更新，因此 react-hook-form 提供了 watch 和性能更好的 useWatch。

watch 官方示例：

import React from "react";
import { useForm } from "react-hook-form";

function App() {
  const { register, watch, formState: { errors }, handleSubmit } = useForm();
  const watchShowAge = watch("showAge", false); // you can supply default value as second argument
  const watchAllFields = watch(); // when pass nothing as argument, you are watching everything
  const watchFields = watch(["showAge", "number"]); // you can also target specific fields by their names

  // Callback version of watch.  It's your responsibility to unsubscribe when done.
  React.useEffect(() => {
    const subscription = watch((value, { name, type }) => console.log(value, name, type));
    return () => subscription.unsubscribe();
  }, [watch]);

  const onSubmit = data => console.log(data);

  return (
    <>
      <form onSubmit={handleSubmit(onSubmit)}>
        <input type="checkbox" {...register("showAge")} />
        
        {/* based on yes selection to display Age Input*/}
        {watchShowAge && <input type="number" {...register("age", { min: 50 })} />}
        
        <input type="submit" />
      </form>
    </>
  );
}

useWatch 官方示例：

import React from "react";
import { useForm, useWatch } from "react-hook-form";

function FirstNameWatched({ control }) {
  const firstName = useWatch({
    control,
    name: "firstName", // without supply name will watch the entire form, or ['firstName', 'lastName'] to watch both
    defaultValue: "default" // default value before the render
  });

  return <div>Watch: {firstName}</div>; // only re-render at the component level, when firstName changes
}

function App() {
  const { register, control, handleSubmit } = useForm();
  
  const onSubmit = (data) => {
    console.log(data)
  };

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <input {...register("firstName")} />
      <input {...register("lastName")} />
      <input type="submit" />

      <FirstNameWatched control={control} />
    </form>
  );
}

两者是存在新能差异的，useWatch 可以认为是把更新移到了更局部的位置，所以性能上会更有优势。下图：

三、动态数组字段

在复杂的表单应用中，还需要动态增减数组字段。react-hook-form 提供了一个 useFieldArray 的API，来帮助我们实现。

我们来看一个官方示例：代码地址

import React from "react";
import { useForm, useFieldArray } from "react-hook-form";

function App() {
  const { register, control, handleSubmit, reset, trigger, setError } = useForm({
    // defaultValues: {}; you can populate the fields by this attribute 
  });
  const { fields, append } = useFieldArray({
    control,
    name: "test"
  });
  
  return (
    <form onSubmit={handleSubmit(data => console.log(data))}>
      <ul>
        {fields.map((item, index) => (
          <li key={item.id}>
            <input {...register(`test.${index}.firstName`)} />
            <Controller
              render={({ field }) => <input {...field} />}
              name={`test.${index}.lastName`}
              control={control}
            />
            <button type="button" onClick={() => remove(index)}>Delete</button>
          </li>
        ))}
      </ul>
      <button
        type="button"
        onClick={() => append({ firstName: "bill", lastName: "luo" })}
      >
        append
      </button>
      <input type="submit" />
    </form>
  );
}

useFieldArray 使用也很简单，该返回一个 fields 和若干操作数组的方法例如（append、insert）。

需要注意的是 useFieldArray 返回的 fields 是一个不受控制的字段这点很重要。这意味着它不会存储在全局的 _formValues 中，所以在使用 useFieldArray 遍历动态字段的时候，还需要我们自己对需要操作的数据进行一次注册操作。

在 useFieldArray 中注册动态字段：

 <Controller
	render={({ field }) => <input {...field} />}
	name={`test.${index}.lastName`}
	control={control}
/>

但是这样就会有一个问题，动态注册的字段，数据变化并不会反应到 fields 中。这是为什么呢？ 🤔

我们直接阅读源码：源码位置

const methods = useFormContext();
const {
  control = methods.control,
  name,
  keyName = 'id' as TKeyName,
  shouldUnregister,
} = props;
const [fields, setFields] = React.useState<
  Partial<FieldArrayWithId<TFieldValues, TFieldArrayName, TKeyName>>[]
>(mapIds(control._getFieldArray(name), keyName));
const _fieldIds = React.useRef(fields);
const _name = React.useRef(name);
const _actioned = React.useRef(false);

_name.current = name;
_fieldIds.current = fields;
control._names.array.add(name);

useSubscribe({
  callback: ({ values, name: fieldArrayName }) => {
    if (fieldArrayName === _name.current || !fieldArrayName) {
      setFields(mapIds(get(values, _name.current), keyName));
    }
  },
  subject: control._subjects.array,
});

我们发现 fields 是 useFieldArray 自己内部维护的一个状态。同时 useFieldArray 内部也订阅了一个 control._subjects.array，可以在全局监听变化或修改。

接着我们继续往下看，append 方法，append 方法会帮我们动态添加字段。并且我们发现它还会调用 control._updateFieldArray 也就是会更新全局的表单数据。prepend、remove 等 API 也是如此。

const append = (
    value:
      | Partial<FieldArray<TFieldValues, TFieldArrayName>>
      | Partial<FieldArray<TFieldValues, TFieldArrayName>>[],
    options?: FieldArrayMethodProps,
  ) => {
    const appendValue = convertToArrayPayload(value);
    const updatedFieldArrayValuesWithKey = appendAt(
      mapCurrentIds(control._getFieldArray(name), _fieldIds, keyName),
      mapIds(appendValue, keyName),
    );
    setFields(updatedFieldArrayValuesWithKey);
    control._updateFieldArray(
      name,
      appendAt,
      {
        argA: fillEmptyArray(value),
      },
      updateValues(updatedFieldArrayValuesWithKey),
    );

    control._names.focus = getFocusFieldName(
      name,
      updatedFieldArrayValuesWithKey.length - appendValue.length,
      options,
    );
  };

这里我们可以得出结论就是，想要更新 fields 就需要调用 useFieldArray 提供的 API 方法或者通过全局 setValue 方式修改，通过动态注册字段的方式无法修改 fields 中的数据内容。至于为什么是这样的一种实现，官方的解释是 ** 提供更好的用户体验和表单性能。**

useFieldArray 的使用还有诸多使用细节，建议大家查看官方文档，这里简单编写一个示例：

function App() {
  const { register, control, handleSubmit, reset, watch } = useForm({
    defaultValues: {
      test: [{ firstName: "Bill", lastName: "Luo" }]
    }
  });
  const {
    fields,
    append,
    prepend,
    remove,
    swap,
    move,
    insert,
    replace
  } = useFieldArray({
    control,
    name: "test"
  });

  const onSubmit = (data) => console.log("data", data);

  const formValues = useWatch({ name: "test", control });

  renderCount++;

  return (
    <>
      <form onSubmit={handleSubmit(onSubmit)}>
        <h1>Field Array </h1>
        <p>The following demo allow you to delete, append, prepend items</p>
        <span className="counter">Render Count: {renderCount}</span>
        <ul>
          {fields.map((item, index) => {
            return (
              <li key={item.id}>
                <input {...register(`test.${index}.firstName`)} />

                <Controller
                  render={({ field }) => <input {...field} />}
                  name={`test.${index}.lastName`}
                  control={control}
                />
                <button type="button" onClick={() => remove(index)}>
                  Delete
                </button>
              </li>
            );
          })}
        </ul>
        <section>
          <button
            type="button"
            onClick={() => {
              append({ firstName: "appendBill", lastName: "appendLuo" });
            }}
          >
            append
          </button>
        </section>
      </form>
    </>
  );
}

表单初始化数据 useFieldArray 中的 fields 和 form 中的数据一致。

接着我们对数据进行操作就发现二者是有区别的，也就是我们之前所说的。通过动态注册字段的方式无法修改 fields 中的数据内容。

接着我们通过 useFieldArray 提供的 API 就可以修改 fields 以及 form 中的数据。但是会造成组件 Array 级别的渲染，性能下降。

使用建议：

如果数据需要用户操作，那么建议使用 control 的方式注册字段，并且使用 useWatch 来监听字段变化，而不是从 fields 中获得。
如果数据只是用作纯粹的展示使用，那么建议使用 fields 中的数据即可。
如果在 useFieldArray 的 API 更新数据的时候遇到问题，建议使用 setValue 来操作。（😕 需要具体分析）
添加数据时需要确保数据结构的完整性，不然会造成数据初始化错乱。（例如：删除一条数据，然后追加一条数据）

到此我们就简单的了解了一下 React-hook-form。

React 应用状态管理

2021-09-18T02:34:07Z

🔗 原文链接：

Application State Management with React

状态管理在任何应用中都是最难的部分。这也是为什么如此多的状态管理库层出不穷的原因。虽然状态管理本身是一个复杂的问题，但我认为让状态管理如此复杂的另一个原因就是我们经常 过度设计(over-engineer) 我们的解决方案。

在我使用React的过程中，有一个状态管理方案是我个人一直试图实现的，随着 React Hooks 的发布（以及 React Context 的大规模改进），这种状态管理方法已经被大幅简化。

我们经常说 React 组件是构建应用的乐高积木，但有多少人会认为在积木中包含了状态管理呢？我个人解决状态管理问题的 "秘密 "是，考虑应用程序的状态在应用程序的树状结构中如何映射。

Redux 如此成功的原因之一是 react-redux 解决了 prop drilling 问题。你可以通过将组件传递到 connect 函数中，从而在组件树中的不同位置共享数据。这一功能非常好，它对 reducer/action creators/等等的使用也很好，但我相信 Redux 的普遍性是因为它解决了开发者的 prop drilling 痛点。

但这也是我很少使用 Redux 的原因：我不断的看到开发者将应用程序中的所有状态都砸到 Redux 中（不仅仅是全局状态，局部状态也是这样）。这导致了非常多的问题，其中最重要的一点是当你在维护任何状态的交互时，都涉及到 reducers、 action creatores/types、和 dispatch 的调用。这最终导致你不得不打开许多文件，在你的脑海中追踪代码，以弄清楚正在发生什么，以及它对代码库的其他部分有什么影响。

如果 Redux 管理的是 真正的全局状态，这倒没有什么影响。但是对于简单状态的管理（如弹窗的打开/关闭状态或者简单表单输入框的状态）就会变成一个大问题。更糟糕的是 Redux 的可扩展性不是很好，这就导致了如果你的应用变得越来越大，这个问题就会越来越难解决。你当然可以通过拆分 reducers 管理应用的不同部分，从而降低维护状态的复杂度，但是间接执行所有的 reducers 和 action creators 的方案也不是最优解。

即使不使用 Redux，将应用的所有状态放在单个对象中也可能导致其他问题。当一个 React 的 <Context.Provider> 中的值更新时，所有消费这个 Context 中数据的组件都会被更新并且都需要重新渲染，即使消费数据的组件是一个只关心一小部分数据的函数式组件。这可能会导致潜在的性能问题。（React-Redux v6 也试图使用此方法，直到他们意识这种方法不能兼容 Hooks 的运行逻辑，这迫使他们使用不同的方法在 v7 中来解决这些问题。）但我的观点是，如果你的状态在逻辑上更加分离，并且将状态置于更关心它的且离它更近的 React Tree Node 上，你就不会有这个问题。

如果你正在用 React 来构建应用，那么在你的应用中本身就已经存在了一个状态管理库，你根本不需要执行 npm install （或者 yarn add）任何东西。你的用户不需要消耗额外的流量，它在NPM 上已经集成到所有的 React packages 中，并且 React team 已经为它提供了非常好的文档，它就是 React 本身。

React 本身就是一个状态管理库

当你在构建一个 React 应用时，你其实是在用一堆组件构建一颗组件树，这个组件树的根是 <App />，这棵树的最末端是一些原生的 <input> 、 <div> 和 <button> 等元素。这种UI的渲染方式并不是像原生 HTML 那样 — 将所有的元素都放在一个文件中来渲染UI，相反我们是用一个个独立的组件来管理组成UI的元素，这最终成为了构建UI的一个非常有效的方法。同理这种方式也可以用于状态管理，而且目前你很可能会这样做：

function Counter() {
  const [count, setCount] = React.useState(0)
  const increment = () => setCount(c => c + 1)
  return <button onClick={increment}>{count}</button>
}

function App() {
  return <Counter />
}

注意我说的这些也可以用于 class components, Hooks 只是让事情变得更容易了一些（特别是我们马上要介绍的 Context）

class Counter extends React.Component {
  state = {count: 0}
  increment = () => this.setState(({count}) => ({count: count + 1}))
  render() {
    return <button onClick={this.increment}>{this.state.count}</button>
  }
}

“ 好的 Kent, 在独立的组件中维护单个状态确实比较简单，但如果遇到跨组件状态共享时应该怎么处理呢？比如，如果我想这样做：”

function CountDisplay() {
  // where does `count` come from?
  return <div>The current counter count is {count}</div>
}

function App() {
  return (
    <div>
      <CountDisplay />
      <Counter />
    </div>
  )
}

“ count 在 <Counter> 组件中，我需要一个状态管理工具能在 <CountDisplay> 中访问到 count ，并且能在 <Counter> 中更新它! ”

这个问题的答案在 React 刚发布时就已经存在了（或许更早？），并且我记得它一直在React的文档中：状态提升

“状态提升”无疑是用来解答这个问题的最合理最正确的答案。你可以这样使用：

function Counter({count, onIncrementClick}) {
  return <button onClick={onIncrementClick}>{count}</button>
}

function CountDisplay({count}) {
  return <div>The current counter count is {count}</div>
}

function App() {
  const [count, setCount] = React.useState(0)
  const increment = () => setCount(c => c + 1)
  return (
    <div>
      <CountDisplay count={count} />
      <Counter count={count} onIncrementClick={increment} />
    </div>
  )
}

我们刚刚将 <Counter> 管理 count 的职责提升到了 <App> 中，这真的很简单。而且我们还可以一直提升状态到应用程序的顶部。

"好的， Kent, 但是怎么处理 prop drilling 的问题呢？“

Great question. 第一步就是重新思考组件组织的方式，好好利用一下组件组合。看看这个例子：

function App() {
  const [someState, setSomeState] = React.useState('some state')
  return (
    <>
      <Header someState={someState} onStateChange={setSomeState} />
      <LeftNav someState={someState} onStateChange={setSomeState} />
      <MainContent someState={someState} onStateChange={setSomeState} />
    </>
  )
}

你可以这样使用组件组合的方式，重新组织组件树：

function App() {
  const [someState, setSomeState] = React.useState('some state')
  return (
    <>
      <Header
        logo={<Logo someState={someState} />}
        settings={<Settings onStateChange={setSomeState} />}
      />
      <LeftNav>
        <SomeLink someState={someState} />
        <SomeOtherLink someState={someState} />
        <Etc someState={someState} />
      </LeftNav>
      <MainContent>
        <SomeSensibleComponent someState={someState} />
        <AndSoOn someState={someState} />
      </MainContent>
    </>
  )
}

如果你不是很清楚我在说什么的话，你可以看看 Michael Jackson 的视频可以帮助你理解我想表达的意思。

但即使使用 component composition 也不能完全解决 props drilling 的问题。所以下一步就是使用 React 的 Context API。这实际上已经是一个 "解决方案 "了，但在很长一段时间里，这个解决方案是 "非官方的"。所以许多人都选择了 react-redux ，因为它用我说的机制解决了这个问题，也不用担心 React 文档中的警告。但是现在 Context API 已经被官方支持，我们可以直接使用，没有任何问题。

// src/count/count-context.js
import * as React from 'react'

const CountContext = React.createContext()

function useCount() {
  const context = React.useContext(CountContext)
  if (!context) {
    throw new Error(`useCount must be used within a CountProvider`)
  }
  return context
}

function CountProvider(props) {
  const [count, setCount] = React.useState(0)
  const value = React.useMemo(() => [count, setCount], [count])
  return <CountContext.Provider value={value} {...props} />
}

export {CountProvider, useCount}

// src/count/page.js
import * as React from 'react'
import {CountProvider, useCount} from './count-context'

function Counter() {
  const [count, setCount] = useCount()
  const increment = () => setCount(c => c + 1)
  return <button onClick={increment}>{count}</button>
}

function CountDisplay() {
  const [count] = useCount()
  return <div>The current counter count is {count}</div>
}

function CountPage() {
  return (
    <div>
      <CountProvider>
        <CountDisplay />
        <Counter />
      </CountProvider>
    </div>
  )
}

该代码示例是精心策划的，我不建议你使用 Context 来解决此问题。请阅读 Prop Drilling，以便更好地了解为什么 Prop Drilling 不一定是问题，而且通常是可取的。不要把 Context 作为第一优先级的解决方案！

这种方法的有趣之处在于我们可以把所有操作状态的公共逻辑抽取在 useCount Hook 内：

function useCount() {
  const context = React.useContext(CountContext)
  if (!context) {
    throw new Error(`useCount must be used within a CountProvider`)
  }
  
  const [count, setCount] = context
  const increment = () => setCount(c => c + 1)
  
  return {
    count,
    setCount,
    increment,
  }
}

你也可以很容易地把 useState 替换为 useReducer

function countReducer(state, action) {
  switch (action.type) {
    case 'INCREMENT': {
      return {count: state.count + 1}
    }
    default: {
      throw new Error(`Unsupported action type: ${action.type}`)
    }
  }
}

function CountProvider(props) {
  const [state, dispatch] = React.useReducer(countReducer, {count: 0})
  const value = React.useMemo(() => [state, dispatch], [state])
  return <CountContext.Provider value={value} {...props} />
}

function useCount() {
  const context = React.useContext(CountContext)
  if (!context) {
    throw new Error(`useCount must be used within a CountProvider`)
  }

  const [state, dispatch] = context
  const increment = () => dispatch({type: 'INCREMENT'})

  return {
    state,
    dispatch,
    increment,
  }
}

这提供了巨大的灵活性，并将复杂程度降低了几个数量级。在这样做的时候，有几件重要的事情要记住:

在你的应用程序中，并非所有的东西都需要在一个单一的状态对象中，保持逻辑上的分离（用户设置不一定要和通知在同一个上下文中）。使用这种方法，你会有多个 Context。
不是所有的上下文都需要在全局范围内访问! 尽可能地将状态保持在需要的地方。

更多关注在第二点上。你的应用程序树可能看起来像这样

function App() {
  return (
    <ThemeProvider>
      <AuthenticationProvider>
        <Router>
          <Home path="/" />
          <About path="/about" />
          <UserPage path="/:userId" />
          <UserSettings path="/settings" />
          <Notifications path="/notifications" />
        </Router>
      </AuthenticationProvider>
    </ThemeProvider>
  )
}

function Notifications() {
  return (
    <NotificationsProvider>
      <NotificationsTab />
      <NotificationsTypeList />
      <NotificationsList />
    </NotificationsProvider>
  )
}

function UserPage({username}) {
  return (
    <UserProvider username={username}>
      <UserInfo />
      <UserNav />
      <UserActivity />
    </UserProvider>
  )
}

function UserSettings() {
  // this would be the associated hook for the AuthenticationProvider
  const {user} = useAuthenticatedUser()
}

请注意，每个页面都可以有自己的 Provider，每个 Provider 拥有它下面的组件所必需的数据。Code Splitting 对这个东西也是 "有效的"。数据如何进入每个 Provider，取决于这些 Provider 使用的Hook，以及你如何在应用程序中使用数据，但你知道从哪里开始查找数据流（在 Provider 中）。

想了解更多更多关于这种方案的优点，请查阅 "State Colocation will make your React app faster" 和 "Colocation"。如果想了解更多关于 context，阅读 “How to use React Context effectively”。

Server Cache 和 UI State

最后再补充一件事，state 有各种类型，但每一种类型的 state 都可以归入两个大类中。

Server Cache - 状态实际上存储在服务端，我们将其存储在客户端中便于快速访问（像用户信息）。
UI State - 只用在 UI 层，用来控制应用的交互（如弹窗的 isOpen 状态）。

当我们把这两者关联起来的时候，我们就犯了一个错误。 Server Cache 在本质上与 UI State 有着不同的问题，因此需要以不同的方式进行管理。如果你认可这个观点：你所拥有的实际上根本不是状态，而是状态的缓存，那么你就可以开始正确地思考它，从而正确地管理它。

你肯定可以用你自己的 useState 或 useReducer，在恰当的位置用正确的 useContext 来管理这个问题。但请允许我帮助你提个醒，缓存是一个非常难的问题（有人说这是计算机科学中最难的问题之一），在这个问题上，站在巨人的肩膀上是明智的。

这就是为什么我使用并推荐 react-query 来处理这种状态。我知道，我告诉过你，你不需要一个状态管理库，但我并不认为 react-query 是一个状态管理库。我认为它是一个缓存。而且它是一个非常好的缓存。看看它吧， Tanner Linsley 是个聪明人。

性能如何？What about performance?

当你遵循上述建议时，性能基本上不会是一个问题。特别是当你遵循有关 colocation 的建议时。然而，在一些使用案例中，性能肯定会出现问题。当你遇到与状态有关的性能问题时，首先要检查的是有多少组件由于状态变化而被重新渲染，并确定这些组件是否真的需要由于该状态变化而被重新渲染。如果是这样，那么问题就不在于你的状态管理机制，而在于你的渲染速度，在这种情况下你需要加快渲染速度。

然而，如果你注意到有很多组件在渲染时没有DOM更新或只是需要副作用，那么这些组件就在进行不必要的渲染。这种情况在React中经常发生，而且它本身通常不是一个问题（你应该首先专注于快速不必要的重新渲染），但如果它真的是瓶颈，那么这里有一些方法可以解决React上下文中状态的性能问题。

把你的状态分成不同的逻辑部分，而不是在一个大的 Store 中，所以对状态的任何部分的单一更新都不会触发对你的应用程序中的每个组件的更新。
优化 Context provider
引入 jotai

又来了，又是对一个库的推荐。的确，有一些场景并不适合用 React 内置的状态管理抽象。在所有可用的抽象中，jotai 对于这些场景是最有希望解决的。如果你想知道这些场景是什么，jotai 能很好地解决的什么样的问题，查看： Recoil 现代 React 的状态管理 - Dave McCabe aka @mcc_abe 在 @ReactEurope 2020 。Recoil 和 jotai 非常相似（并且解决相同类型的问题）。但根据我对它们的（有限的）经验，我更喜欢jotai。

在任何情况下，大多数应用程序都不需要像 recoil 或 jotai 这样的原子状态管理工具。

总结

同样也你可以用 Class Component 做相同的事情, 但 Hooks 使它更容易管理。你完全可以用 React 15 实现这一理念，没有任何问题。但注意尽可能地保持状态在需要它的地方，只有在 Prop Drilling 真正成为一个问题的时候再考虑使用 Context, 这样做会让你更容易管理状态。

React Hooks 中使用 setInterval

2021-08-02T15:51:16Z

一、困惑

在 React Hooks 中我们使用 setInterval 有时会偏离自己想要的效果，给我们来带一些困惑。

然而我们发现这并不是 React Hooks 的问题，而是 React 编程模式和 setInterval 不匹配造成的。React Hooks 函数式的方式更贴近 React 编程模型，而 setInterval 更符合命令式编程。

那么我们就来深入分析一下如何在 React Hooks 中使用 setInterval。

二、尝试

首先我们从一个只渲染初始状态的简单例子开始，代码如下：

function Counter() {
  const [count, setCount] = useState(0);
  return <p>{count}</p>;
}

接下我们添加一个每秒增加的 interval，它是一个需要清理副作用的，所以我将用到 useEffect() 并返回清理函数，代码如下：

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    let id = setInterval(() => {
      setCount(count + 1);
    }, 1000);
    return () => clearInterval(id);
  });

  return <p>{count}</p>;
}

代码地址

这样工作看起来很简单对吧，似乎也没什么问题。

默认情况下，React 会在每次渲染后重执行 effects，这是有目的的，这有助于避免 React class 组件的某种 bugs。

这通常是好的，因为需要许多订阅 API 可以随时顺手移除老的监听者和加个新的。但是，setInterval 和它们不一样。当我们执行 clearInterval 和 setInterval 时，它们会进入时间队列里，如果我们频繁重渲染和重执行 effects，interval 有可能没有机会被执行！

例如我们可以通过以更短间隔重渲染我们的组件，来发现这个 bug，代码如下：

export default function App() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    let id = setInterval(() => {
      setCount(count + 1);
    }, 100);
    return () => clearInterval(id);
  });

  return (
    <div className="App">
      {count}
      <h1>Hello CodeSandbox</h1>
      <Counter />
    </div>
  );
}

代码地址

三、继续尝试

我们都知道 useEffect() 允许我们选择性地进行重执行 effects，我们可以设定一个依赖数组作为第二个参数，React 只会在数组里的某个发生变化时重运行。

我们的问题是重运行 effects 时使得 timer 过早被清除，我们可以尝试不重运行去修复它们：

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    let id = setInterval(() => {
      setCount(count + 1);
    }, 1000);
    return () => clearInterval(id);
  }, []);

  return <p>{count}</p>;
}

但是，我们发现计时器更新到 1 就不动了。（代码地址）

这中间发生了什么❓ 🤔

这个问题在于，useEffect 在第一次渲染时获取值为 0 的 count，我们不再重执行 effect，所以 setInterval 一直引用第一次渲染时的闭包 count，以至于 count + 1 一直是 1。

修复它的方式就是使用函数式更新，就像 setCount(c => c + 1) 这样替换 setCount(count + 1)，这样可以读到新 state 变量。但这个无法帮助你获取到新的 props。

四、React Hooks 和 setInterval 的差异

我们总想是在 React 编程模式和命令式 setInterval 之间寻找平衡点，想让它们融合在一起工作。但其实它们存在一些模式不匹配。

一个 React 组件可能在 mounted 之前流经许多不同的 state，但它的渲染结果将一次性全部描述出来。

// 描述每次渲染
return <p>{count}</p>

Hooks 使我们把相同的声明方法用在 effects 上：

useEffect(() => {
  let id = setInterval(() => {
    setCount(count + 1);
  }, 100);
  return () => clearInterval(id);
});

相反，setInterval 没有及时地描述过程，一旦设定了 interval，除了清除它，你无法对它做任何改变。

这就是 React 编程模式和 setInterval 之间的不匹配。

差异的体现

React 组件中的 props 和 state 是可以改变的， React 会重渲染它们且丢弃任何关于上一次渲染的结果，它们之间不再有相关性。

useEffect() Hook 也丢弃上一次渲染结果，它会清除上一次 effect 再建立下一个 effect，下一个 effect 产生新的 props 和 state。

但 setInterval 不会丢弃。它会一直引用老的 props 和 state 直到你把它换掉。（不重置时间你是无法做到的）

五、Refs 方案

首先我们先总结一下问题：

我们在第一次渲染时执行带 callback1 的 setInterval(callback1, delay)。
我们在下一次渲染时得到携带新的 props 和 state 的 callback2。
我们无法在不重置时间的情况下替换掉已经存在的 interval。

那么如果我们根本不替换 interval，而是引入一个指向新 interval 回调的可变 savedCallback 会怎么样？现在我们来看看这个方案：

我们调用 setInterval(fn, delay)，其中 fn 调用 savedCallback。
第一次渲染后将 savedCallback 设为 callback1。
下一次渲染后将 savedCallback 设为 callback2。
重复上面的步骤，完成。

那么这个可变的 savedCallback 需要在重新渲染时可持续，所以不可以是一个常规变量，我们想要一个类似对象的变量。

这时我们会想到使用 useRef() 这个 Hooks。

 const savedCallback = useRef();

useRef 返回一个可变的 ref 普通对象在 render 间共享。我们可以保存新的 interval 回掉给它：

function callback() {
   // 可以读到新 props，state等。
   setCount(count + 1);
}

// 每次渲染后，保存新的回调到我们的 ref 里。
useEffect(() => {
   savedCallback.current = callback;
});

之后我们便可以从我们的 interval 中读取和调用它：

useEffect(() => {
    function tick() {
        savedCallback.current();
    }

    let id = setInterval(tick, 1000);
    return () => clearInterval(id);
}, []);

这里 []，不重执行我们的 effect，interval 就不会被重置。同时 savedCallback ref，让我们可以一直在新渲染之后读取到回调，并在 interval tick 里调用它。

完整的代码如下：代码地址

function Counter() {
  const [count, setCount] = useState(0);
  const savedCallback = useRef();

  function callback() {
    setCount(count + 1);
  }

  useEffect(() => {
    savedCallback.current = callback;
  });

  useEffect(() => {
    function tick() {
      savedCallback.current();
    }

    let id = setInterval(tick, 1000);
    return () => clearInterval(id);
  }, []);

  return <p>{count}</p>;
}

到这里我们就让 React Hooks 和 setInterval 完美的运行在了一起。

六、自定义 useInterval

上述代码如果直接使用会比较麻烦，于是我们就提取一个 custom Hook，例如 useInterval，代码如下：

function useInterval(callback, delay) {
  const savedCallback = useRef();

  useEffect(() => {
    savedCallback.current = callback;
  });

  useEffect(() => {
    function tick() {
      savedCallback.current();
    }

    let id = setInterval(tick, delay);
    return () => clearInterval(id);
  }, [delay]);
}

我们还可以添加一个 delay 参数，来调整时间间隔，当 delay 改变时，我们重新生成一个 timer。

我们只需要在组件中这样使用即可：代码地址

function App() {
  const [count, setCount] = useState(0);

  useInterval(() => {
    setCount(count + 1);
  }, 1000);

  return (
    <div className="App">
      <p>{count}</p>
    </div>
  );
}

添加暂停功能

假设我们希望能够通过传递 null 作为 delay 来暂停我们的 interval，如下：

const [delay, setDelay] = useState(1000);
const [isRunning, setIsRunning] = useState(true);

useInterval(
  () => {
    setCount(count + 1);
  },
  isRunning ? delay : null
);

然后我们修改一下 useInterval 的代码，如下：

useEffect(() => {
  function tick() {
    savedCallback.current();
  }

  if (delay !== null) {
    let id = setInterval(tick, delay);
    return () => clearInterval(id);
  }
}, [delay]);

到此我们的 custom Hook 也编写完成。代码地址

原文链接：Making setInterval Declarative with React Hooks

polyfill in create-react-app

2021-07-13T16:18:05Z

一、create-react-app 中的 polyfill

上一篇我们已经了解了如何使用 Babel 进行 polyfill。现在我们基于 React 工程来实践。

1. 创建工程

这里使用官方的脚手架工具初始化项目，如下：

yarn create react-app react-polyfill

我们需要修改 Babel 配置，还需要运行如下命令：

yarn eject

2. 查看 Babel 配置

在 webpack.config.js 文件中，找到对应解析 js 的 loader 配置如下：

// ... code
presets: [
    [
        require.resolve('babel-preset-react-app'),
        {
            runtime: hasJsxRuntime ? 'automatic' : 'classic',
        },
    ],
]
// ... code

观察源码发现，官方提供的 presets 是 babel-preset-react-app 而不是我们所熟悉的 @babel/preset-env。

babel-preset-react-app 其实是 React 官方封装的一个库。

查看 babel-preset-react-app 找到对应的 preset 设置，对应源码中 create.js 文件，如下：

(isEnvProduction || isEnvDevelopment) && [
  // Latest stable ECMAScript features
  require('@babel/preset-env').default,
  {
    // Allow importing core-js in entrypoint and use browserlist to select polyfills
    useBuiltIns: 'entry',
    // Set the corejs version we are using to avoid warnings in console
    corejs: 3,
    // Exclude transforms that make all code slower
    exclude: ['transform-typeof-symbol'],
  },
],

看到这里就一目了然了，根据上一篇我们了解到的知识。@babel/preset-env 参数是 useBuiltIns: 'entry' 和 corejs: 3，那么就需要我们手动导入对应的 polyfill 文件。这里对应的源码注释也说得非常详细。

3. 进行 polyfill

首先安装 corejs3 和 regenerator-runtime 依赖，如下：

yarn add core-js@3 regenerator-runtime

然后在 src 目录下，创建一个 polyfill/index.js，在文件中导入我们需要 polyfill 的 API，如下：

import 'core-js/es/array/flat'
import 'core-js/es/array/flat-map'
import 'core-js/es/array/includes'
import 'regenerator-runtime/runtime'

我们有 2 种方式引入 polyfill：

直接在入口文件引入 index.js：

import './polyfill/index.js'

在 webpack.config.js 中的 entry 参数中添加：

entry:[
    // ... code
    paths.appPolyFillJs,
    paths.appIndexJs,
    // ... code
]

然后我们启动工程，找到编译后的文件如下：

通过上述的配置方法就实现了 polyfill，这也算是官方推荐的一个方案。

二、按需加载

如果我们想要实现按需加载怎么办？

那么我们就从 Github 上 fork 一份 babel-preset-react-app 源码。

其他步骤和之前介绍过的一样，只需要修改 create.js 的 preset 即可，如下：

{
  target: {
    chrome: 61,
    firefox: 52,
    safari: 8,
    ie: 11
  },
  useBuiltIns: 'usage',
  corejs: 3,
  exclude: ['transform-typeof-symbol'],
}

然后发布到 npm 仓库，修改 webpack.config.js 文件中 loader 替换成自己的。如下：

// code ...
presets: [
  [
    require.resolve('xxxx/babel-preset-react-app'),
  ]
]
// code ...

以上就是通过 create-react-app 创建工程的 polyfill 方法。如果自己使用 webpack 搭建就直接修改 preset 就好。

一次 polyfill 对 babel 的思考🤔

2021-07-11T13:45:26Z

一、起因

正在写 bug🐛 的我，突然被叫去看一个问题，页面突然白屏了。于是本能的反应是快速打开控制台，发现 js 有报错，报错信息是 .flat() is not a function，原来是浏览器版本不支持 flat API，做一下 polyfill 就好了。那么我们如何 polyfill 呢？🤔 接下来就来详细分析一下 polyfill 的过程。

二、Babel 的作用

首先在进行 polyfill 之前，我们复习一下 Babel 这个编译器。官方文档

Babel 主要用于将采用 ECMAScript 2015+ 语法编写的代码转换为向后兼容的 JavaScript 语法，以便能够运行在当前和旧版本的浏览器或其他环境中。 作用如下：

语法转换
通过 Polyfill 方式在目标环境中添加缺失的特性（通过第三方 polyfill 模块，例如 core-js，实现）
源码转换 (codemods)

换而言之就是 Babel 能让我们现在就使用新的语法，无需等待浏览器的支持。

看上去很美好，但还是有一些原生 API 方法， Babel 并没用做转换处理，例如：flat、flatMap、includes 等。这时我们就需要为 Babel 编译器做一些配置，也就是 polyfill。

三、@babel/polyfill

正常我们使用 Babel 是不需要安装 @babel/polyfill，但是如果我们需要兼容版本较低的浏览器，就可以使用该库。

@babel/polyfill 它会模拟完整的 ES2015+ 环境用于我们的程序，这样我们使用的 Promise 或 WeakMap 这样的新内置函数，Array.from 或 Object.assign 这样的静态方法，Array.prototype.includes 这样的实例方法等，会被 polyfill 添加到全局范围。

使用方法也相对简单，只需要安装 @babel/polyfill：

yarn add @babel/polyfill

然后在我们的入口文件引入：

import "@babel/polyfill"

来看一个示例：

我们编写一个 index.js 文件如下：

import '@babel/polyfill'

const a = [1, 2, 3, 4].flat()
const b = [1, 2, 3, 4].flatMap()
const c = [1, 2, 3, 4].includes(1)

然后使用 webpack 工具编译，输出后的结果如下：

截图中红色区域就是我们引入的 @babel/polyfill。

@babel/polyfill 的入口文件，实质上是把 ES2015+ 的 polyfill 和一个 runtime 转译生成器函数引入。

这样无疑增加了我们打包的体积，我只使用了 flat、flatMap、includes，却引入了整个 polyfill。

在新的 Babel 版本（7.4.0）中 @babel/polyfill 已经被废弃，不在推荐使用。这里简单了解一下即可。

源码地址

四、被遗忘的 core-js

这是什么鬼 👻 ，日常我们更多的可能是使用 react 等库进行前端开发，很少会关注底层的一些依赖，了解它对于我们 polyfill 很重要。

core-js 是一个 JavaScript 的模块化标准库。包括 ECMAScript 到 2021 年的 polyfill。 官方文档

core-js 的几个核心概念：

它尽可能的进行模块化，让你能选择你需要的功能
它可以不污染全局空间
它和 babel 高度集成，可以对 core-js 的引入进行最大程度的优化

core-js 目前有 2 个版本，2 和 3 ，由于 3 版本进行了一些破坏性变更导致无法兼容 2 版本，现在 2 版本被废弃使用。

core-js@3 的重要改变：

对于 ECMAScript 中已经稳定的功能，core-js 已经几乎完全支持，并在 core-js@3 中引入了一些新的功能
对于一些已经加入到 ES2016-ES2019 中的提案，现在已经被标记为稳定功能
增加了 proposals 配置项，对处在提案阶段的 api 提供支持，但是因为提案阶段并不稳定，在正式加入标准之前，可能会有大的改动，需要谨慎使用；对于一些改变巨大的提案，也进行了对应的更新
增加了对一些 web 标准的支持，比如 URL 和 URLSearchParams
删除了一些过时的特性

由于 core-js@2 版本包的体积太大(~2M)，并且有很多重复的文件被引用。core-js@3 对包进行拆分，三个核心的包分别是：

core-js：定义全局的 polyfill（~500k, 40k minified and gzipped）
core-js-pure：提供不污染全局环境的 polyfill，等价于 core-js@2/library（~440k）
core-js-compat：包含了 core-js 模块和 API 必要的数据，通过 browserslist 来生成所需要的 core-js 模块的列表

对于 core-js@3 的入口文件，我们可以这样使用：

// polyfill all `core-js` features:
import "core-js";
// polyfill only stable `core-js` features - ES and web standards:
import "core-js/stable";
// polyfill only stable ES features:
import "core-js/es";

// if you want to polyfill `Set`:
// all `Set`-related features, with ES proposals:
import "core-js/features/set";
// stable required for `Set` ES features and features from web standards
// (DOM collections iterator in this case):
import "core-js/stable/set";
// only stable ES features required for `Set`:
import "core-js/es/set";
// the same without global namespace pollution:
import Set from "core-js-pure/features/set";
import Set from "core-js-pure/stable/set";
import Set from "core-js-pure/es/set";

// if you want to polyfill just required methods:
import "core-js/features/set/intersection";
import "core-js/stable/queue-microtask";
import "core-js/es/array/from";

我们还可以使用 core-js-compat 用来提供不用目标引擎所需要的core-js的模块信息：

const {
  list,              // array of required modules
  targets,           // object with targets for each module
} = require('core-js-compat')({
  targets: '> 2.5%', // browserslist query
  filter: 'es.',     // optional filter - string-prefix, regexp or list of modules
});

console.log(targets);

五、了解 browserslist

我们使用 React 开发，在 package.json 中有这么一段配置：

"browserslist": {
  "production": [
    ">0.2%",
    "not dead",
    "not op_mini all"
  ],
  "development": [
    "last 1 chrome version",
    "last 1 firefox version",
    "last 1 safari version"
  ]
}

或在根目录存在一个 .browserslistrc 的配置文件。

那么这个 browserslist 有什么用呢？

browserslist 能在不同前端工具之间共享目标浏览器和 Node.js 版本的配置。

browserslist 使用 caniuse-lite 和 caniuse 进行查询。

那么我们如何知道这个配置都兼容是什么，官方也提供了查询。

例如我们有如下配置：

"browserslist": [
  ">0.2%",
  "not dead",
  "not op_mini all"
]

然后运行：

npx browserslist

输出：

这个配置的大概意思：

>0.2%：拥有至少 0.2% 全球市场份额的所有浏览器
not dead：排除过去 24 个月内没有官方支持的浏览器
not op_mini all 排除 Opera Mini 浏览器

这里不做过多的展开，有兴趣的可以查看。官网文档

六、了解 @babel/preset-env

前面花了这么多篇幅介绍相关的工具和库，都是为了介绍 @babel/preset-env 做铺垫，@babel/preset-env 可以说是我们做 polyfill 的核心包。

@babel/preset-env 是什么呢？

官网文档

首先，介绍历史背景，对了解和学习 @babel/preset-env 有帮助。

最初，为了让开发者能够尽早用上新的 ES 特性，babel 团队开发了 babel-preset-latest。这个 preset 比较特殊，它是多个 preset 的集合(es2015+)，并且随着 ECMA 规范的更新更增加它的内容。

比如(2018.06.02)，它包含的 preset 包括：es2017、es1016、es2015。

到了明年，可能它包含的 preset 就包括：es2020、es2019、es2018、es2017、es2016、es2015。

随着时间的推移，babel-preset-latest 包含的插件越来越多，这带来了如下问题：

加载的插件越来越多，编译速度会越来越慢；
随着用户浏览器的升级，ECMA 规范的支持逐步完善，编译至低版本规范的必要性在减少（比如ES6 -> ES5），多余的转换不单降低执行效率，还浪费带宽。

因为上述问题的存在，babel 官方推出了 @babel/preset-env 插件。它可以根据开发者的配置，按需加载插件。配置项大致包括：

需要支持的平台：比如node、浏览器等。
需要支持的平台的版本：比如支持 node@6.1等。

一句话解释：

@babel/preset-env 可以根据配置的目标浏览器或者运行环境来自动将 ES2015+ 的代码转换为 es5。

其实它和 Babel 做的事情有部分是重叠，由于 Babel 还有编译等核心功能，所有对于 ECMA 规范的预设就交给了 @babel/preset-env 专门处理。

@babel/preset-env 与 core-js 和 browserslist 搭配，共同完成 ECMA 语法规范的预设。

接下来到我们的实践环节。

在开始我们的实践之前，先声明在 babel7.4.0 的版本中已经支持 core-js@3 的版本。core-js@3 的出现，也迫使我们放弃 @babel/polyfill (只支持 core-js2)。

polyfill 的第一种方式

先准备环境，安装 babel 核心库和 @babel/preset-env：

yarn add @babel/core @babel/cli @babel/preset-env --save-dev

由于我们废弃了 @babel/polyfill，需安装 core-js@3 和 regenerator-runtime

yarn add core-js@3 regenerator-runtime

添加 babel.config.json 配置文件：

{
  "presets": [
    [
      "@babel/reset-env",
      {
        "useBuiltIns": "entry",
        "corejs": 3
      }
    ]
  ]
}

在 package.json 中添加 browserslist 配置：

"browserslist": [
    "> 0.02%",
    "not dead"
  ]

添加我们的测试代码：

// a.js
export function flatFn(array) {
    return array.flat()
}

export function flatMap(array) {
    return array.flatMap(x => [x * 2])
}

// b.js
function wait(delay) {
    return new Promise(resolve => setTimeout(resolve, delay))
}

export default wait

// index.js
import 'core-js/stable'
import 'regenerator-runtime/runtime'
import {flatFn, flatMap} from './a'
import wait from './b'

const array = [1, 2, 3, 4, 5]

flatFn(array)
flatMap(array)
wait().then(r => r)

这里需要注意我们在入口 index.js 中，引入了 core-js/stable 和 regenerator-runtime/runtime，因为我们废弃了 @babel/polyfill。

然后运行脚本：

yarn build

编译之后它把所有的 polyfill 注入到我们的入口文件中，截取部分代码如图所示：

接下来，重点讲一下 babel 配置文件中的 useBuiltIns 这个参数：

"usage" | "entry" | false, defaults to false.

entry：将 import 'core-js' 和 import 'regenerator-runtime' ，替换（或打散）为适配目标环境的各个引用。

// app.js
import 'core-js/stable';
import 'regenerator-runtime/runtime'

// babel-loader options
{
  "presets": [
    [
      "@babel/env",
      {
        "useBuiltIns": "entry",
        "corejs": 3,
        "targets": {
          "browsers": [
            "last 2 versions",
            "not ie <= 10"
          ]
        }
      }
    ]
  ]
}

usage：每个文件中使用 polyfill 时，为它们添加导入。也就是按需加载。

注意！使用 usage 时，不需要手动导入 corejs | regenerator-runtime，否则会提示错误

修改一下我们之前的 babel 配置文件，如下：

{
  "presets": [
    [
      "@babel/env",
      {
        "useBuiltIns": "usage",
        "corejs": 3
      }
    ]
  ]
}

他会为我们每一个文件添加 polyfill。

修改我们的 webpack 配置：

rules: [
    {
        test: /\.js$/,
         // useBuiltIns: 'usage' 时设置
         // 这里排除了 core-js,webpack/buildin ，否则会报错，因为babel默认会将corejs自身也进行编译
         // https://github.com/zloirock/core-js/issues/743
        exclude: [
            /\bcore-js\b/,
            /\bwebpack\/buildin\b/
        ],
        use: {
            loader: 'babel-loader'
        }
    },
],

然后我们编译一下，现在按需加载，体积减少很多。截取部分代码如图所示：

false: 不会像 usage 为每个文件添加 polyfill；也不会像 entry，将 import 'core-js' import 'regenerator-runtime' 替换为适配目标环境的各个引用。对在入口文件引入的 polyfill 不做任何处理。

修改一下我们 babel 配置文件，如下：

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "useBuiltIns": false
      }
    ]
  ]
}

编译结果如下：

false 还是进行了一个全量的引入。

源码地址

polyfill 的第二种方式

引入了 corejs、regenerator-runtime 这样的 polyfill 会有一定的副作用，比如：

引入了新的全局对象：比如 Promise、WeakMap 等。
修改现有的全局对象：比如修改了 Array、String 的原型链等。(如第一种方式的截图中)

在应用开发中，上述行为问题不大，基本可控。但如果在库、工具的开发中引入 polyfill，则会带来潜在的问题。

举个例子，我在项目中定义了跟规范不一致的 Array.from() 函数，同时引入了一个库（注入了 polyfill），此时，这个库可能覆盖了自定义的 Array.from() 函数，导致出错。

那么接下来就是 @babel/plugin-transform-runtime 的出场机会了。它将开发者依赖的全局内置对象等，抽取成单独的模块，并通过模块导入的方式引入，避免了对全局作用域的修改（污染）。官方文档。

runtime 这里简单介绍一下

babel 的 runtime，包含两个部分。 @babel/runtime、@babel/plugin-transform-runtime。

@babel/runtime：它其实是一个 babel 内部的库，使用在生产环境的 dependency，在 transform-runtime 作用的过程中，都会使用 @babel/runtime 内部的模块，来代替重复的 helper 函数、对全局空间有污染的 core-js 和 regenerator-runtime 相关变量。

@babel/plugin-transform-runtime：这个插件主要有两个方面的用途。

babel 在转码过程中，会加入很多 babe l自己的 helper 函数，这些 helper 函数，在每个文件里可能都会重复存在，transform-runtime 插件可以把这些重复的 helper 函数，转换成公共的、单独的依赖引入，从而节省转码后的文件大小。
transform-runtime 可以帮助这种项目创建一个沙盒环境，即使在代码里用到了新的 ES 特性，它能将这些特性对应的全局变量，转换为对 core-js 和 regenerator-runtime 非全局变量版本的引用。这其实也应该看作是一种给代码提供 polyfill 的方式。

接下来进入我们熟悉的实践环节。

安装开发环境：

yarn add @babel/runtime @babel/runtime-corejs3
yarn add @babel/plugin-transform-runtime --save-dev

注意 @babel/runtime 要做为项目的 dependencies

然后修改我们的 babel 配置文件：

{
  "presets": [
    [
      "@babel/preset-env"
    ]
  ],
  "plugins": [
    [
      "@babel/plugin-transform-runtime",
      {
        "corejs": {
          "version": 3,
          "proposals": true
        }
      }
    ]
  ]
}

编译运行：

与第一种方式的 polyfill 对比可以发现，runtime 将新的 API 进行了重命名，它是不会重写覆盖原生方法的。

需要注意 @babel/plugin-transform-runtime 的默认配置中，是不会注入对提案的 polyfill 代码。如果想要支持提案中的 API，只需要增加和 @babel/preset-env 类似的配置项。

"corejs": {
    "version": 3,
    "proposals": true
}

源码地址

七、小结

这里可能有人好奇，如果我们 @babel/plugin-transform-runtime 开启 corejs 并且 @babel/preset-env 也开启 useBuiltIns 会怎么样。
结论是：被使用到的 API polyfill 将会采用 runtime 的不污染全局方案（注意：@babel/preset-env targets 设置将会失效），而不被使用到的将会采用污染全局的。

对于 @babel/preset-env 我们可以设置 debug 参数，来查看那些 API 被 polyfill，配置如下：

{
  "presets": [
    [
      "@babel/env",
      {
      	"debug": true,
        "useBuiltIns": "usage",
        "corejs": 3
      }
    ]
  ]
}

效果如下：

对于 polyfill 的使用场景：

如果是业务项目开：@babel/plugin-transform-runtime ，建议关闭 corejs，polyfill 的引入由 @babel/preset-env 完成，即开启 useBuiltIns（如需其他配置，自行根据诉求配置）。

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": {
          "chrome": 58
        },
        "useBuiltIns": "usage",
        "corejs": {
          "version": 3,
          "proposals": true
        }
      }
    ]
  ],
  "plugins": [
    [
      "@babel/plugin-transform-runtime"
    ]
  ]
}

如果是 Library 开发：@babel/plugin-transform-runtime ，建议开启 corejs，polyfill 由 @babel/plugin-transform-runtime 引入。 @babel/preset-env 关闭 useBuiltIns。

{
  "presets": [
    [
      "@babel/preset-env",
    ]
  ],
  "plugins": [
    [
      "@babel/plugin-transform-runtime",
      {
        "corejs": {
          "version": 3,
          "proposals": true
        }
      }
    ]
  ]
}

可能这里又有新的困惑：

为什么 @babel/preset-env 不能使用不污染全局的 polyfill。（不污染全局的 polyfill 必须由 @babel/plugin-transform-runtime 引入）

为什么要使用不污染全局的 polyfill 就必须要使用 @babel/plugin-transform-runtime，而与此同时我必须妥协掉 @babel/preset-env targets 带来的体积优势。

没有解决方案？

抱歉在现有的 babel 体系下还真的没有好办法来解决这个问题，当然 babel 也意识到了这个问题，于是有了 babel-polyfills（不是 @babel/polyfills）这里不在详细展开，有兴趣的可以自行查看。

对没错，我们还遗漏了 react 工程中如何 polyfill。🙂

金数据技术博客

跨 site 加载 JS 的代价 —— Chrome 139+ 的一个默认行为，和我们为它付的两次学费

TL;DR

背景

1. 我们自己埋的坑

2. 系统内太慢了

3. 用 agent 协助定位

4. 和上次不同的测试结果

5. Root Cause

6. 方案一：换成同一个域名？

7. 方案二：让 chunk 带上 fetchpriority=high

8. 打 patch

9. 后续

写在最后

一个 Button，440 KB —— Server Component 里 import antd 的代价

TL;DR

背景

最小复现

A. Server Import

B. Client Import

开发环境的对比

Production Bundle 分析对比

为什么会这样

怎么修

其他方式

解决 GraphQL 类型膨胀问题，显著提升 Turbopack 构建速度

背景

Turbopack 带来的新问题

“第一次请求要 70 秒？”

第一次尝试：循环依赖

第二次尝试：Turbopack Tracing

火焰图告诉了我们真相

domain.ts 到底是什么？

为什么它会膨胀到这么大？

真正的问题：Fragment 被“无限展开”了

解决方案：inlineFragmentTypes = combine

效果立竿见影

后续与思考

总结

Debug issues with legacy browser on macOS

问题

解决方案

你的解决方案是什么？

The guardian of Server Component in Next.js

技术人怎么有效地做沟通？

方法

心态

react-native 从 v0.61.4 升级到 v0.70.6 踩坑指南

需求背景

寻找解决方案

过程中遇到的问题

其他依赖包主要的更新包括：

总结

参考资料

Draw tech diagrams clearly

整洁性

清晰地书写

线条不要有交叉

一致性

颜色、图形

箭头指向

解释性

图例

JavaScript 中与数字相关的奇怪问题

First of All

Why

So

And

CKEditor5食用指南

CKEditor5简介

编辑器类型

引入方式

官方

我们项目的引入方式

CKEditor5框架介绍

核心编辑器框架 Core editor architecture

编辑器类 Editor Classes

插件 Plugins

命令 Commands

事件系统和可观察对象 Event system and observables

7. 方案二：让 chunk 带上 `fetchpriority=high`