c4605's blog

我写了一个 MCP 转 Skill 的 Skill

2026-01-23T00:00:00Z

最近写了个 skill，功能是把 MCP server 转成 Claude Code skill。听起来有点绕，但其实挺实用的。

为什么要转？

MCP 本身没什么问题，很好，至少给了一个统一的，可发现的交互协议，而且这个协议的接受度还这么广，太难得了，Restful 虽然很多服务商都支持，但是这个东西的约束太少，太灵活，实话说很多时候“可发现”这个事情很多大厂（尤其是不少中国的大厂）做的简直和屎一样；而 GraphQL, gRPC 之类的，接受度又都很有限，非常碎片化。有 MCP 至少这方面的问题解决很多。

但是它还是有点问题。

上下文窗口吃的太严重了

MCP 的工作方式是把所有 tool 的定义一股脑丢进上下文里。如果你接了好几个 MCP server，每个 server 又有一堆 tools，那上下文窗口里光是 tool 定义就占了一大坨，举个例子，我刚看了一下，GitHub mcp 占了我 10k token (5%) 的上下文。

Claude Code skill 有个叫 progressive disclosure（渐进式披露）的机制：AI 先看到一个简短的描述，只有在需要用到这个 skill 的时候才会加载完整的内容。这样上下文窗口就不会被一堆可能根本用不到的 tool 定义给塞满了。

虽然目前这个 skill 没办法把有些需要 OAuth 的 mcp 服务给变成 skill （严格来说，要做还是能做的，就是麻烦了点，我正在考虑后面有空的话就加上……），但是至少能少占一点是一点……

AI 调用 tool 效率太低了

这是让我最想做这个转换的原因。

传统的方式是让 AI 一个一个地调用 tool：先调用 A，拿到结果，再调用 B，再调用 C……每次调用都要走一遍"AI 决策 → 发起调用 → 拿到结果 → AI 再决策"的循环。

问题是这个过程很不可靠。AI 可能会漏掉某个步骤，可能会在中间突然疯了，而且每次调用的结果都要塞进上下文里，token 消耗蹭蹭往上涨，甚至可能会因为返回的内容过长而失败，然后 AI 还得想办法多次分页请求内容。

更好的方式是让 AI 写一段脚本，一次性完成所有调用（或者对响应结果进行预处理）。代码的控制流比 AI 的"思考链"要可靠得多，而且 Anthropic 官方也在研究这个方向——他们发了一篇叫 Code execution with MCP 的文章，数据显示 token 消耗从 15 万降到 2 千，减少了 98.7%。

我的这个 skill 生成的结果里就包含了一个 api.mjs，AI 可以直接 import 进来写脚本用：

import { callTool } from '/<mcp-skill-path>/scripts/api.mjs';

// 并行搜索多个仓库的 issues
const repos = ['facebook/react', 'vuejs/vue', 'sveltejs/svelte'];
const results = await Promise.all(
  repos.map(repo => callTool('search_issues', {
    repo,
    query: 'memory leak'
  }))
);

// 汇总结果，只返回需要的字段
const summary = results.flatMap((r, i) =>
  r.content[0].text.items?.slice(0, 3).map(issue => ({
    repo: repos[i],
    title: issue.title,
    url: issue.html_url
  })) ?? []
);

console.log(JSON.stringify(summary, null, 2));

如果用传统的 tool calling 方式，AI 得调用 3 次 search_issues，每次调用的完整结果都要塞进上下文，然后 AI 再"思考"一遍怎么汇总。用脚本的话，一次执行完，返回给 AI 的就是处理好的精简结果。

版本锁定

MCP server 通常是 npx @some/mcp-server 这样运行的，每次都拉最新版。这意味着 server 的维护者随时可以推一个恶意更新，而你完全不知道。

转成 skill 的时候可以锁定版本号，至少能防一手供应链攻击。

简单示例

用起来大概是这样：

> /mcp-skill-generator 帮我转一下 @anthropic/mcp-server-filesystem
> /mcp-skill-generator 帮我转一下 https://docs.devin.ai/work-with-devin/deepwiki-mcp

然后它会问你要存到哪里（项目目录还是个人目录），接着自动提取 schema、生成文件。最后得到的目录结构是：

mcp-filesystem/
├── SKILL.md
├── config.toml
├── tools/
│   ├── read_file.md
│   ├── write_file.md
│   └── ...
└── scripts/
    ├── mcp-caller.mjs
    ├── ...
    └── api.mjs          # AI 可以用这个写脚本

最后

代码在我的 claude-skills 仓库里，有兴趣的可以看看。

说实话这个 skill 本身就是用 Claude Code 写的，写的过程中我深刻体会到了"让 AI 写代码"比"让 AI 调用 tool"靠谱多少——至少代码跑不通的时候能看到报错信息，而不是 AI 默默地走偏了你还不知道。

shadow-cljs-vite-plugin v0.0.6: 修复 HMR 和 ES Module 兼容性问题

2026-01-22T00:00:00Z

shadow-cljs-vite-plugin 首次发布两周后，v0.0.6 带来了一些重要的修复，让开发体验更加顺滑。

问题一：ES Module 导入

首次发布时，ClojureScript 代码在 Vite 的 ESM 环境中存在一些导入问题，在部署到 Cloudflare Workers 时尤为明显。

这个问题需要上游配合修复，我们向 shadow-cljs 提交了一个 PR #1249，已在 v3.3.5 合并。感谢 @thheller 一起解决这个问题！

问题二：HMR 时 "Namespace already declared" 错误

这个问题比较恼人。在热更新时，Vite 会重新执行模块代码，但全局状态（比如 goog.loadedModules_）会跨 HMR 更新持久化。Google Closure Library 假设模块只会被加载一次，遇到重复注册就会抛错。

解决方案是让 goog.provide 和 goog.module 变成幂等操作：

goog.provide = function(name) {
  return goog.isProvided_(name) ? undefined : goog.constructNamespace_.call(this, name);
};

goog.module = Object.assign(function(name) {
  if (name in goog.loadedModules_) {
    goog.moduleLoaderState_.moduleName = name;
    return;
  }
  return origModule.call(this, name);
}, origModule);

更好的 HMR 批处理

之前如果你快速保存多个文件（或者编辑器保存时自动格式化），每次变更都会触发一次 HMR 更新。现在插件会使用防抖机制将多个文件变更合并为单次更新。

另外，修改 shadow-cljs.edn 后 Vite 会自动重启，不用再手动重启了。

Tailwind CSS 支持

插件和 Tailwind CSS 配合良好，我已经在我的博客前端使用这个组合，没有任何问题。

试试看

npm install shadow-cljs-vite-plugin

插件已经稳定，我正在生产环境使用。欢迎在 GitHub 上反馈和贡献。

bitcoin-wallet-connector: 可能是目前最好用的比特币钱包适配器

2026-01-06T00:00:00Z

标题党一下 🤪

上一篇文章我吐槽了比特币钱包生态有多混乱：WBIPs 标准没人实现、sats-connect 的兼容性、钱包各有各的 API...

这篇文章介绍下我写的库：bitcoin-wallet-connector。

先来试试 在线 Demo ，或者 Storybook

我来讲讲这个库关注什么

把那些莫名其妙的差异抹平

bitcoin-wallet-connector 提供了一套统一的 API，让你用同样的代码接入所有支持的钱包：

import {
  BitcoinWalletConnector,
  UnisatWalletAdapterFactory,
  XverseWalletAdapterFactory,
  LeatherWalletAdapterFactory,
} from "bitcoin-wallet-connector";

// 注册你想支持的钱包
const connector = new BitcoinWalletConnector([
  UnisatWalletAdapterFactory(),
  XverseWalletAdapterFactory(),
  LeatherWalletAdapterFactory(),
]);

// 订阅可用钱包变化
// 注意：钱包扩展注入 API 的时机是不确定的（有些在 DOMContentLoaded，
// 有些在 load 事件后），所以推荐使用 subscribe 而不是 get
connector.subscribeAvailableAdapters((availableAdapters) => {
  console.log(
    "可用钱包:",
    availableAdapters.map(([id]) => id)
  );
  // => ['unisat', 'xverse', ...]
});

// 连接钱包 - 所有钱包用同一套 API
const [adapterId, adapter] = availableAdapters[0];
await connector.connect(adapterId, adapter);

// 获取地址、签名、发送交易 - 统一接口
const addresses = await adapter.getAddresses();
const result = await adapter.signMessage(
  addresses[0].address,
  "Hello Bitcoin!"
);

就这样，你只需要写一遍代码，就能支持所有钱包。

目前支持的钱包：

钱包	Adapter	额外依赖
UniSat	`UnisatWalletAdapterFactory`	-
Xverse	`XverseWalletAdapterFactory`	`sats-connect`
OKX	`OkxWalletAdapterFactory`	-
Leather	`LeatherWalletAdapterFactory`	`@leather.io/rpc`
Bitget	`BitgetWalletAdapterFactory`	-
Magic Eden	`MagicEdenWalletAdapterFactory`	`sats-connect`

所有 adapter 都实现了相同的接口：

interface WalletAdapter {
  // 连接/断开
  connect(): Promise<void>;
  disconnect(): Promise<void>;

  // 获取地址
  getAddresses(): Promise<WalletAdapterAddress[]>;

  // 消息签名
  signMessage(address: string, message: string): Promise<SignMessageResult>;

  // 发送 BTC
  sendBitcoin(
    fromAddress: string,
    receiverAddress: string,
    satoshiAmount: bigint
  ): Promise<{ txid: string }>;

  // PSBT 签名
  signAndFinalizePsbt(
    psbtHex: string,
    signIndices: [address: string, signIndex: number][]
  ): Promise<{ signedPsbtHex: string }>;

  // 监听地址变化
  onAddressesChanged(callback): { unsubscribe: () => void };
}

无论用户选择哪个钱包，你的业务代码都是一样的。

关于 sendRunes/sendInscriptions/sendBRC20

目前这个库只支持 signMessage, sendBitcoin, 和 signPsbt，暂时不支持 sendRunes, sendInscriptions, sendBRC20。

因为这些都涉及到更复杂的依赖（比如需要一个 Ordinals Indexer, 还需要一个 BRC20 Indexer 等等）。这些会让一个 Connector 变的过于复杂。

在我看来，这应该是一个 Transaction Builder 的职责，由 Transaction Builder 负责构建交易，然后将交易交给 Connector 来签名和发送。

安全性很重要

在设计这个库的时候，我把依赖安全放在了很高的优先级。原因很简单：钱包库直接接触用户的资产，任何安全漏洞都可能造成真金白银的损失。

Peer Dependencies

我把一些重要的依赖声明为 peer dependencies，而不是打包进库里：

pnpm add bitcoin-wallet-connector @scure/base @scure/btc-signer

这意味着：

你可以直接控制这些依赖的版本
如果某个依赖爆出安全漏洞，你可以立即升级，不用等这个库发新版本
也不会出现最终的 bundle 里被打包了两个版本的 @scure/btc-signer 的尴尬场景

可选依赖：按需安装

钱包 SDK（如 sats-connect、@leather.io/rpc）是可选的 peer dependencies：

# 只支持 UniSat 和 OKX？不需要安装任何额外依赖

# 需要支持 Xverse？
pnpm add sats-connect

# 需要支持 Leather？
pnpm add @leather.io/rpc

你只安装你需要的，减少你被恶意包脚本攻击的风险。

动态导入：延迟加载

这是另外一个重要的安全设计：钱包 SDK 通过 dynamic import() 延迟加载。

// 内部实现示意
const availability = createAvailability({
  getPrecondition: () => window.unisat ?? null,
  initializer: async () => {
    // 只有用户真正要连接这个钱包时，才会加载对应的实现
    const { UnisatWalletAdapterImpl } = await import(
      "./UnisatWalletAdapter.impl"
    );
    return new UnisatWalletAdapterImpl();
  },
});

假设 sats-connect 这个包被供应链攻击了（这在 npm 生态并不罕见）。如果你的用户只使用 UniSat 钱包，恶意代码不会被加载和执行，因为 sats-connect 只有在用户点击"连接 Xverse"时才会被 import。

这一条应该能降低用户被供应链攻击的风险。

框架集成

目前提供了 React 集成，开箱即用的 Context Provider：

import {
  BitcoinConnectionProvider,
  useBitcoinConnectionContext,
} from "bitcoin-wallet-connector/react";
import {
  UnisatWalletAdapterFactory,
  XverseWalletAdapterFactory,
} from "bitcoin-wallet-connector/adapters";

const adapterFactories = [
  UnisatWalletAdapterFactory(),
  XverseWalletAdapterFactory(),
];

function App() {
  return (
    <BitcoinConnectionProvider
      adapterFactories={adapterFactories}
      onWalletConnected={(session) => console.log("Connected:", session)}
      onWalletDisconnected={() => console.log("Disconnected")}
    >
      <WalletUI />
    </BitcoinConnectionProvider>
  );
}

function WalletUI() {
  const { walletSession, availableAdapters, connect, disconnect } =
    useBitcoinConnectionContext();

  if (walletSession) {
    return (
      <div>
        <p>已连接: {walletSession.adapterId}</p>
        <button onClick={() => disconnect()}>断开连接</button>
      </div>
    );
  }

  return (
    <div>
      {availableAdapters.map(([adapterId, adapter]) => (
        <button key={adapterId} onClick={() => connect(adapterId, adapter)}>
          连接 {adapterId}
        </button>
      ))}
    </div>
  );
}

核心的 BitcoinWalletConnector 是框架无关的，如果你在用 Vue、Svelte、Solid 或其他框架，封装成对应的 hooks/composables 应该不难，当然也欢迎贡献！

欢迎使用和贡献

快速开始

pnpm add bitcoin-wallet-connector @scure/base @scure/btc-signer

# 按需安装钱包 SDK
pnpm add sats-connect      # Xverse / Magic Eden
pnpm add @leather.io/rpc   # Leather

或者 5 分钟跑通 Demo：

Clone 仓库
pnpm install
pnpm storybook
打开 http://localhost:6006

你可以在 Storybook 里测试各种钱包的连接、签名等功能。

贡献

这是一个开源项目，非常欢迎社区贡献！

如果你想添加新钱包的支持，有一个小小的期望：尽量不要依赖钱包官方的 SDK。

为什么？因为很多钱包的 API 其实就是挂在 window 对象上的，直接调用就行，没必要引入一个额外的 SDK。比如 UniSat、OKX、Bitget 的 adapter 都是零外部依赖的。

引入 SDK 意味着多一个潜在的供应链攻击入口、用户需要多安装一个包、可能引入不必要的 bundle size。当然，如果某个钱包确实只能通过 SDK 接入（比如 Xverse 的 sats-connect），那也没问题，我们可以把它作为可选的 peer dependency。

详细的贡献指南请看 CONTRIBUTING.md。

项目完全开源（MIT），欢迎 Star 和贡献！

比特币钱包生态有多土狗：从开始到放弃

2026-01-03T00:00:00Z

如果你正在开发一个比特币 dApp，你可能已经发现了，比特币社区的生态实在是太土狗了。

最简单的例子就是比特币钱包，大家似乎热衷于给其他人制定标准，但大家似乎又不热衷于实现这个标准。

"标准"？什么标准？

让例子更详细一点：

WBIPs：制定标准的人自己都不遵守

Leather 和 Xverse 搞了一个 WBIPs ，说是要制定一个统一的比特币钱包 API 标准，但：

signPsbt 的 finalize 参数

signPsbt 标准里定义了 finalize 参数，但两个发起者都没实现：

Leather 的代码
Xverse 的代码

钱包自动发现机制的实现完全不对啊老师

WBIP004 定义了钱包插件的自动发现机制，第一步是往 wbip_providers 里注入钱包 provider。

但实际上 Xverse 和 Leather 都是往 window.btc_providers 里注入的：

Leather 的代码
Xverse 的代码

另外两个主流钱包根本不 care

更不用说实际上占有大量流量的 UniSat 和 OKX Wallet 似乎对支持 WBIPs 没有丝毫兴趣。

sats-connect：标准之上的标准

然后在 WBIPs 之外，Xverse 还搞了一个 sats-connect ，似乎想在 WBIPs 之外再扩展一些自己的 API ，实现一套标准之上的标准。

这不算差，尤其是它还兼容了 UniSat API 。Magic Eden 还号称 "兼容 sats-connect"。

"这听起来简直太棒了！sats-connect 简直就是版本答案！世界救主！"，对吧？你肯定是这么想的。

不过完美世界的上空"还剩下两朵小小的乌云"：

sats-connect 不支持 OKX Wallet（虽然 OKX Wallet 的 API 现在已经迁移到和 UniSat 兼容了，但 sats-connect 没办法自动发现它）
Magic Eden 的自动发现跟的是另一个标准：ExodusMovement/bitcoin-wallet-standard，而不是 WBIPs 标准。所以你没办法靠 sats-connect 来自动发现它。

等下，又来一个标准？

"等下卧槽，这个 ExodusMovement/bitcoin-wallet-standard 又是个什么标准？我 TM 从来没听说过啊！"

对的，在我尝试集成 Magic Eden 之前，我也没听说过，现在我听说了，你也听说了。

来点示例代码

你可能会觉得那大不了我就自己在项目里都集成一遍呗。那让我们来看看为了实现一个简单的连接钱包功能，代码的差异：

// UniSat - 直接调用 window 对象
const unisatResponse = await window.unisat.requestAccounts();

// Leather - 又是另一套 API
const leatherResponse = await window.LeatherProvider.request("getAddresses");

// Xverse - 来自官方文档
import { request } from "sats-connect";
const xverseResponse = await request("getAddresses", null);

// Magic Eden - 来自官方文档
import { getAddress, AddressPurpose, BitcoinNetworkType } from "sats-connect";
await getAddress({
  getProvider: getBtcProvider,
  payload: {
    purposes: [AddressPurpose.Ordinals, AddressPurpose.Payment],
    message: "Address for receiving Ordinals and payments",
    network: {
      type: BitcoinNetworkType.Mainnet,
    },
  },
  onFinish: (response) => {
    console.log("onFinish response, ", response.addresses);
    connectionStatus?.setAccounts(response.addresses as unknown as Account[]);
  },
  onCancel: () => {
    alert("Request canceled");
  },
});

四个钱包，四种写法。

如果你得在你的项目里集成 6 个钱包呢？恭喜你，你会需要把我上面提到的问题都过一遍，和我一起愉快地浪费掉一大把人生的时间。

总结一下

"去他妈的傻逼比特币钱包生态，太他妈土狗了！"，你/我心想。

所以我写了一个库

所以我写了一个 bitcoin-wallet-connector ，可以让其他人少浪费一点时间在这些破事上。

下一篇文章我会详细介绍这个库的使用方法和设计理念。如果你已经等不及了，可以先看看：

在线 Demo
GitHub 仓库

我把我的配置共享仓库转移到了 LLM-oriented 模式

2026-01-02T00:00:00Z

啥是 "LLM-oriented 的配置共享方案"

简单来说，就是让配置共享项目提供 llms.txt ，使用方依此让 LLM 去下载/更新项目的配置文件，以保持配置的更新。而不是通过 npm registry 来分发配置。

那为不用 npm 了？

传统的工具配置共享方式，无论是通过 extends 继承还是 preset 预设，都面临一个根本性的矛盾：便利性与灵活性的两难选择。

继承模式的优点

当你使用类似 extends: "@company/eslint-config" 的方式时，好处显而易见：

升级简单：只需 npm update，所有使用该配置的项目都能获得更新
一致性保证：团队中所有项目使用相同的规则
维护集中：配置的改进和 bug 修复只需要在一个地方进行

但现实很骨感

问题出现在你需要做任何"非标准"操作的时候：

自定义需求：项目有特殊需求，需要覆盖某些规则
依赖版本冲突：你需要升级 ESLint，但上游配置包还没有跟进（比如 ESLint 更新到 flat mode config 了，你需要用到最新版的 ESLint 了，但是我懒，我还没更新 🤪）
规则分歧：上游更新了某个规则，但你的项目不适用（问题是你一开始可能不知道，等出问题了才发现"卧槽我被坑了"）

这时候，你有两个选择：

选择 A：在继承基础上打补丁

// eslint.config.js
export default [
  ...baseConfig,
  {
    rules: {
      // 覆盖一个规则
      "some-rule": "off",
      // 再覆盖一个
      "another-rule": ["error", { different: "options" }],
    },
  },
  // 还要处理插件版本冲突...
];

补丁越打越多，最终你的"继承"变成了一层又一层的覆盖，反而比从头写还难维护。

ESLint 其实已经还好了，Prettier 和 lint-staged 这种没有 extends/merge 机制的就更麻烦了，我之前写了一个超级麻烦的 lint-staged 配置（看这里 lint-staged.config.js 和 lint-staged.helpers.js，看起来挺 decent 的（好吧至少我自己这么觉得），其实超级难用，还把一个非常简单的事情搞的极其复杂

选择 B：Eject（弹出）

很多脚手架工具提供了 eject 命令，把所有配置文件复制到你的项目里，让你获得完全控制权。

但 eject 之后：

你失去了自动升级的能力，你得自己去更新，没办法享受上游已经测试过的插件之间的兼容性
当上游有重要更新时，你需要手动 diff 和合并

这就是两难困境：继承模式下你受制于上游，eject 之后你要承担维护成本。

LLM 是个好东西

现在我们有了 LLM 了，时代变了

新的工作流

获取最新配置：LLM 直接从 llms.md/llms.txt 获取最新的推荐配置
智能合并：LLM 理解你的项目上下文，把新配置合并到现有配置中
保留自定义：你的自定义修改会被识别并保留
按需更新：当你需要升级时，让 LLM 帮你处理合并冲突

为什么这比传统方式更好？

所有配置都在你的代码库中

没有隐藏的 node_modules 深处的配置文件，没有"这个规则是从哪里来的"的困惑。每一行配置都清清楚楚地在你的项目里。

升级变得可控

升级不再是一个"要么全要，要么不要"的决定。LLM 可以帮你：

查看上游有什么变化
理解每个变化的影响
选择性地应用更新
自动处理合并冲突

自定义是一等公民

你的自定义不再是"补丁"，而是配置的一部分。LLM 在更新时会理解并尊重这些自定义。

依赖版本自由

你可以随时升级任何依赖，不需要等待上游配置包更新。遇到问题？还能让 LLM 帮你调整配置（他们读起配置来也变简单了）。

上游的配置文件变的更简单了

还是看我的 lint-staged 配置文件

以前的版本：

lint-staged.config.js
为了方便下游能复用配置，还能自定义 lint-staged 的配置，不得不写的帮助函数 lint-staged.helpers.js

现在的版本：

lint-staged.config.js 算了，这个实在是太简单了，我直接 inline 了得了：

module.exports = {
  "*.{ts,tsx,js,jsx}": ["prettier --write", "eslint"],
  "*.{css,scss,sass,less,md,mdx}": ["prettier --write"],
};

lint-staged.helpers.js 已经不存在了，因为没必要

你说了这么多，但这看起来不还是倒退吗？

是，也不是。

是：配置文件确实在每个项目中独立存在，和最早的时候一样
不是：因为维护成本发生了本质变化：
- 以前：人工去看 CHANGELOG 或者看和上游配置文件的 diff -> 搞明白啥变了 -> 手动修改 -> 测试验证
- 现在：告诉 LLM "升级到最新推荐配置" -> 审查 LLM 的改动 -> 完成

维护的认知负担从"我需要理解所有这些配置"变成了"我需要审查 LLM 的建议"。这是和最早的时候不同的地方。

总结（AI 版，我自己编不出来）

传统的配置共享是在"一刀切的便利"和"完全自主的复杂"之间做选择。LLM-oriented 的方式让我们可以两者兼得：

保持配置的完全所有权和透明度
同时享受智能辅助的升级和维护

这不是技术的倒退，而是利用新工具重新定义了最佳实践。

我搞了一个 Elm 风格的 useEffectReducer hook

2025-11-12T00:00:00Z

GitHub: bolasblack/react-components/tree/develop/packages/useEffectReducer

什么是 "Elm 风格"？

Elm 有一个 Model-View-Update 模式，其中每次更新都会返回下一个 model 和要执行的命令：

update : Msg -> Model -> ( Model, Cmd Msg )

这种设计将所有关于 "事件 X 发生时会发生什么" 的逻辑集中在 一个地方 —— update 函数 —— 而不是将副作用分散在各种 useEffect 中。

它还保持了 reducer 的纯洁性，同时让 副作用何时发生、发生什么 变得明确，并可被运行时解释执行。

React 官方文档也呼应了这一理念：effect 应该是一个 逃生舱，而不是默认选择 —— 参见 You Might Not Need an Effect。

如果你想了解这种建模方式如何让 UI 逻辑变得优雅且易于维护，可以看看 David Khourshid 的经典文章 "No, disabling a button is not app logic."

为什么又造一个 Elm 风格的 reducer？

因为没有完全满足我的需求的版本：

有些已经归档了。 例如，useEffectReducer 和 react-use-bireducer 现在都是只读状态。
保持精简。 只需一个文件，几乎没有依赖 —— 随时可以复制、修改或删除。
Effect 作为普通对象 + 独立的解释器。 返回可序列化的 effect descriptors，然后在一个专门的地方实现实际的 effect 逻辑。这样更容易测试 reducer（只需断言描述符），而无需真正执行副作用。
降低门槛。 目标是让 Elm 风格的方法变得易于上手，而不需要深入了解 Elm 的 Cmd Msg 系统，也不需要学习像 XState 这样的完整状态机库。

来点代码

我们用 useEffectReducer 重新实现一下 David Khourshid 文章 "No, disabling a button is not app logic." 中的示例。

两种实现都可以在 GitHub 上找到：

useEffectReducer 版本: useEffectReducer.stories.tsx → L121–203
useReducer 版本: useEffectReducer.stories.tsx → L24–119

其他人的工作

将 Elm 风格的 "状态 + 副作用" reducer 引入 React 的优秀现有实现：

davidkpiano/useEffectReducer — 作者 David Khourshid；已归档
soywod/react-use-bireducer — 返回 [state, effects] 并通过独立的 effect reducer 处理副作用；已归档
ncthbrt/react-use-elmish — Elmish 风格的 hook，结合了 reducer 逻辑和异步辅助函数
redux-loop — Redux 增强器，添加类似 Elm 的 effect 元组
dai-shi/use-reducer-async — 扩展 dispatch 以支持异步 action
useReducerWithEmitEffect — Sophie Alpert 的 gist，启发了本工作的大部分内容

好文章

Christian Ekrem - "Chapter 2, Take 2: Why I Changed Course"
David Khourshid – "Redux is half of a pattern (1/2)"
David Khourshid – "There are so many fundamental misunderstandings about XState (and state machines in general)"
David Khourshid – "No, disabling a button is not app logic."
React docs – "You Might Not Need an Effect"

TypeScript 如何真正 keyof 一个枚举

2020-05-05T00:00:00Z

有一个朋友问我怎么才能 keyof 一个 TypeScript 里的枚举，因为如果你直接 keyof Enum 的话，得到的结果是类似 keyof number ，而不是得到枚举的所有可能的 key 。

于是我简单写了一下跟他解释，顺手发上来：

在 TypeScript 里，你在声明一个枚举的时候，其实声明了两个类型，一个是枚举容器的类型（是一个对象），一个是枚举成员的类型（是数字/字符串或者其他类型的子类型）。

TypeScript 的 keyof 操作符预设后面跟着的是类型，所以我们 keyof Enum 时，其实相当于是在 keyof (作为 number 的子类型的 Enum) ，也就是相当于 keyof number ，所以会得到 number 的属性和方法名。

而 typeof 操作符预设后面跟的是一个值，所以当我们这么写 keyof typeof Enum 的时候，我们是把 Enum 作为一个值（也就是上文提到的“对象”），展开来以后就是 keyof (作为类型的 Enum) ，所以能够得到枚举的 key 。

尝试用 TypeScript 模拟一个带 Payload 的枚举

2020-05-01T00:00:00Z

这两天逛 GitHub 时突然又注意到了 folktale ，发现它现在带了一个 adt/union 。看起来 folktale 现在的 Maybe, Result, Validation 都是从 union 里派生出来的，使用方法和 Swift/Rust 里的枚举非常相似：

const Either = union("Either", {
  Left: (value) => ({ value }),
  Right: (value) => ({ value }),
});

console.log(
  Either.Right(1).matchWith({
    Left: ({ value }) => `left ${value}`,
    Right: ({ value }) => `right ${value}`,
  })
);

正好我想在 TypeScript 里模拟一个带 Payload 的枚举机制已经想了很久了，觉得这个 API 设计得不错，可惜的是没有 TypeScript 的类型定义，在各种抓耳挠腮之下写了一个不完美的版本（下面解释）：

// 这是一个假的函数，只是做个占位而已
export function union<P extends BaseUnionPatterns>(
  typeId: string,
  patterns: P
): UnionTypes<P> {
  return null as any;
}

export type UnionModelMatchPatterns<P extends BaseUnionPatterns, R> = {
  [K in keyof P]: (patternFnReturn: ReturnType<P[K]>) => R;
};

export type UnionModelMatchPatternsWithAny<P extends BaseUnionPatterns, R> = {
  [K in keyof P]?: (patternFnReturn: ReturnType<P[K]>) => R;
} & {
  $$any: (patternFnReturn: ReturnType<P[keyof P]>) => R;
};

export type UnionInstance<P extends BaseUnionPatterns, Type extends keyof P> = {
  equals: (unionInstance: UnionInstance<P, any>) => boolean;
  matchWith: <R>(
    branches:
      | UnionModelMatchPatterns<P, R>
      | UnionModelMatchPatternsWithAny<P, R>
  ) => R;
};

export interface UnionType<P extends BaseUnionPatterns, K extends keyof P> {
  (...args: Parameters<P[K]>): UnionInstance<P, K>;
  hasInstance: (model: UnionInstance<P, keyof P>) => boolean;
}

export type UnionTypes<P extends BaseUnionPatterns> = {
  [K in keyof P]: UnionType<P, K>;
};

export interface BaseUnionPatterns {
  [type: string]: (...args: any) => any;
}

事情并不如愿，总归还是没有办法完全实现我想要的效果，最终的成效是：

// 在这段代码里

// Maybe 变量的类型是对的
const Maybe = union("Maybe", {
  // patterns 参数的类型约束是对的
  Nothing: () => null,
  Just: <T>(value: T) => ({ value }),
  Other: <T>(arg1: T, rest: T[]) => [arg1].concat(rest),
});

// a 变量的类型是对的
const a = Maybe.Just(1);
// b 变量的类型被成功推断
const b = a.matchWith({
  // branches 的类型约束是对的
  Nothing: (arg) => "no value", // arg 的类型确实是 null
  Just: (arg) => `value: ${arg.value}`, // arg 的类型是 { value: unknown } （问题一）
  Other: (arg) => `values: ${arg.join(",")}`, // arg 的类型是 unknown[] （问题二）
});
a.matchWith({
  Just: (arg) => `value: ${arg.value}`,
  // TypeScript 里指定的 Symbol 没办法作为 key 的类型，所以只能用特殊 key $$any
  // 来替代 folktale 里的 any Symbol （问题三）
  $$any: (arg) => `values: ${arg}`,
});

console.log(b);

我们来一个个看这些问题：

关于问题一，让人比较不爽，毕竟 Maybe.Just 的参数类型是出现过的，只是因为 patterns 参数里的 Just 函数是一个泛型函数，而我们在做类型转换的时候又没办法传递类型参数，所以没办法推断出 { value: T } 里 T 的类型；
关于问题二，其实可以理解的，毕竟整个 a 变量的生命周期里从来没提到过 Other 的 Payload 类型；
关于问题三，和问题一一样，都是属于语言设施功能上的缺位，大概只能等 TypeScript 支持相关的特性。

后来结合问题一问题二一想，其实这两个问题可以尝试一起解决，我们只要在声明变量 a 的时候给它传递一个更完整的类型信息就可以了，于是又一阵抓耳挠腮之后，终于写出来一个粗糙的方案：

export type UnionV<
  T extends UnionTypes<any>,
  WrappedValues extends T extends UnionTypes<infer P>
    ? { [K in keyof P]: ReturnType<P[K]> }
    : never
> = UnionInstance<
  { [K in keyof T]: (...args: Parameters<T[K]>) => WrappedValues[K] },
  keyof T
>;

const Maybe = union("Maybe", {
  Nothing: () => null,
  Just: <T>(value: T) => ({ value }),
  Others: <T>(con: T, rest: T[]) => [con].concat(rest),
});

type MaybeNumber = UnionV<
  typeof Maybe,
  {
    // 这里填进去 patterns 各个函数的返回值类型
    Nothing: null;
    Just: { value: number };
    Others: number[];
  }
>;
const a = Maybe.Just("a") as MaybeNumber;
// 这回 b 的类型被成功推断为 number | null
const b = a.matchWith({
  Nothing: (arg) => arg,
  Just: (arg) => arg.value, // arg 的类型为 { value: number }
  Others: (items) => items.length, // arg 的类型为 number[]
});
console.log(b);

目前这套方案在 patterns 的参数都是具体的类型时，不需要 UnionV 就能够工作得很好；在出现泛型函数时，我只能想到通过 UnionV 来为 tsc 提供额外的类型信息。

那么，我们这算是大功告成了吗？并没有，因为整套方案是真的不够优雅，UnionV 的第二个类型参数实在是让人倒胃口。而且如果你仔细看的话，会发现我上面这段代码里 Maybe.Just 的参数是一个字符串，而 tsc 并没有报错。我知道是因为我用了转型，但是如果我这么写 a: MaybeNumber = ，tsc 会报错说 Type '{ value: unknown; }' is not assignable to type '{ value: number; }'. ，所以……这就是为什么这个方案不够优雅的原因之二了。

目前还想不出来更好的方案，只能再等等了，看看 TypeScript 接下来会不会提供这套方案需要的东西吧。

无固有尺寸的 SVG 图片在各浏览器中的渲染尺寸问题

2020-04-09T00:00:00Z

故事

公司同事在做图片预览功能时发现，很多 SVG 图片在 Firefox 下通过 img 标签加载成功后，naturalWidth/naturalHeight 是 0，和其他浏览器表现不同。

这个事情让我有点好奇，按照经验，我觉得 Firefox 一般是最跟随标准的，但是它又何其他浏览器的实现都不相同。所以查了一些资料做了一些测试。经过简单测试后发现，没有固有尺寸¹ 的 SVG 在不同浏览器上使用 img 标签渲染时的尺寸是不同的。

我用几个浏览器跑了一遍 CodePen 上的例子²

这个例子一共有四张图：

有 viewBox 属性的正方图片
有 viewBox 属性的非正方图片
没有 viewBox 属性的非正方图片
有 viewBox 和 width, height 属性的非正方图片

分别在 Firefox v74, Chrome v80, Safari v13 里跑了一下代码：

document.querySelectorAll("img").forEach((el) => {
  console.log(
    "width",
    el.width,
    "height",
    el.height,
    "naturalWidth",
    el.naturalWidth,
    "naturalHeight",
    el.naturalHeight
  );
});

结果如下：

Firefox v74：
- img.naturalWidth/img.naturalHeight
  - 1, 2, 3 的这个属性都返回 0
  - 4 返回 SVG 图片 width, height 属性的值
- img.width/img.height
  - 1, 2 的 img.width 都是 100% 的计算值，img.height 按比例缩放
  - 3 返回 300x150
  - 4 返回 SVG 图片 width, height 属性的值
Chrome v80
- img.naturalWidth/img.naturalHeight
  - 1, 2 的 naturalHeight 都返回 150 ，naturalWidth 按比例缩放
  - 3 返回 300x150
  - 4 返回 SVG 图片 width, height 属性的值
- img.width/img.height 和 Firefox 表现一致
Safari v13
- img.naturalWidth/img.naturalHeight
  - 1, 2 的 naturalWidth 都返回 100% 的计算值，naturalHeight 按比例缩放
  - 3 返回 300x150
  - 4 返回 SVG 图片 width, height 属性的值
- img.width/img.height 和 Firefox 表现一致

然后我查了一下 2020-04-09 时的 HTML 的标准对 naturalWidth 的描述：

The IDL attributes naturalWidth and naturalHeight must return the density-corrected intrinsic width and height of the image, in CSS pixels, if the image has intrinsic dimensions and is available, or else 0.

看起来好像是 Firefox 的实现比较贴近当前的 HTML 标准。

那么如果我想体面地渲染一张随机的 SVG 图片，我该怎么办呢？

目前我没有想到什么特别好的方案，可能会需要自己根据需求来确定方案

如果可以获取到 SVG 文件的代码，而且可以执行 JavaScript ，那么我们可以通过判断 <svg> 标签有没有 width, height 来确认图片是否有固有尺寸，有的话就直接使用 naturalWidth/naturalHeight ，没有的话就使用一 img.width/img.height 计算出宽高比，然后使用我们预置的宽度/高度来渲染图片，另外一边等比缩放
如果没办法获取 SVG 文件的代码，或者没办法执行 JavaScript ，那么我们就只能给图片的外部套一个限制了宽高的容器了。如果图片有固有尺寸，那么图片会按照固有尺寸进行渲染（如果超出了我们限制的宽高它会等比缩放）；如果没有固有尺寸，它就会自动缩放以适应我们限制的宽高

其他资料

Intrinsic sizing of SVG in responsive web design - That Emil.

关于 React 和 Angular 的看法

2015-06-03T00:00:00Z

我最近也用了一段时间的 reactjs ，所以我想有还是稍微有点资格来谈论 angularjs 和 reactjs 的。

有一些文章会提到 angularjs 的两个很关键的问题：controller 拥有了自己的状态，和声明依赖比较容易出现循环依赖。

Facebook 确实提出了一个非常不错的解决方案，但这方案与 Virtual DOM 没有直接的关系（一些文章总是提这东西，我承认这是一个很重要的特性，但和解决 angularjs 的问题关系不大）。

这个方案是 Flux ：通过发布事件的方式来提醒模型更新状态，进而更新所有相关 DOM ，一个很巧妙的解决方案。而 Virtual DOM 只是这个解决方案里保证性能的一环而已。

而 data-binding ，实话说看到一些 reactjs 的拥趸一天到晚扯 data-binding 是邪恶的让我觉得很莫名其妙。data-binding 只是一种模式而已，reactjs 内置了数据的单向绑定难道这就不是 data-binding ？而且 reactjs 还带了一个扩展 ReactLink 用来实现数据的双向绑定又是什么意思？难道在 Vitrual DOM 的 onChange 属性里传一个回调函数然后更新 state 或者发出事件更新模型就不是数据绑定了？那么其他框架实现双向绑定的方法 “监听 DOM 事件，更新 ViewModel” 也不能算是双向绑定咯？因为这其实和在 reactjs 里做的没有任何区别。

我的观点就是，reactjs 是一个不错的东西，Flux 解决了不少其他 MVVM 框架的问题，而 data-binding 绝对是一种进步，因为它大量的减少了开发者的代码量（早就有人实现了一个使用 flux 模式的双向绑定扩展了）。