把 React 应用里的条件渲染和 props 校验交给模式匹配，听起来像是一次函数式编程改造。实际上，当组件需要处理的数据形状越来越复杂时，手写 if/else 或 switch 会迅速膨胀，而 SmartCheck 和 Patterns 的组合正好提供了一种声明式的替代方案。SmartCheck 偏重运行时数据校验，能够对对象、数组、正则、自定义类型做深度检查；Patterns 则让代码可以按照数据形状直接匹配到对应的渲染函数，省去层层嵌套。本文会从旧代码的痛点出发，逐步演示如何把现有 React 组件迁移到 SmartCheck + Patterns 模式匹配检测体系。

迁移前：条件渲染与运行时校验的割裂

在传统 React 组件中，数据是否合法通常由 PropTypes 承担，而业务分支则散落在 render 或函数体里。PropTypes 只能在开发环境给出警告，无法阻止生产环境中错误数据流入；另一方面，针对不同数据形态的判断往往写成多层 if 语句。比如一个用户卡片需要区分游客、编辑和管理员，每种角色还有不同的字段要求，代码会很快陷入嵌套。

这种写法有两个明显问题。第一，校验逻辑和渲染逻辑分离，开发者需要在组件开头手动调用各种判断，容易遗漏。第二，条件分支不是声明式的，新增一种角色意味着要在多处修改 if/else，回归测试成本高。即使使用 TypeScript，也只能覆盖编译期，无法处理从 API 返回的未知结构。

下面是一段常见的旧代码，可以看到同时存在类型判断和角色分支：

function UserCard({ user }) {
  if (!user || typeof user.name !== 'string') {
    return null;
  }
  if (user.role === 'admin' && typeof user.level === 'number') {
    return <AdminPanel user={user} />;
  } else if (user.role === 'editor' && Array.isArray(user.posts)) {
    return <EditorPanel user={user} />;
  } else {
    return <GuestPanel />;
  }
}

SmartCheck 与 Patterns 各司其职

SmartCheck 可以作为运行时数据校验层。它接收一个描述结构，检查传入对象是否满足要求，并在失败时给出详细的字段路径和原因。例如，一个用户对象的模式可以写成：

import { check } from 'smartcheck';
const userSchema = {
  id: Number,
  name: String,
  role: /admin|editor|viewer/,
  posts: Array,
};
if (check(apiData, userSchema)) {
  // 数据合法
}

Patterns 则解决条件分支问题。它类似函数式语言里的 match 表达式，用一组 pattern 描述数据形状，匹配成功后执行对应的回调。Patterns 可以匹配字面量、类型、正则和嵌套对象，还能提供通配模式作为兜底。下面的例子展示了如何把前面手写的角色判断改写成模式匹配：

import { match, pattern } from 'patterns';
const view = match(user, [
  pattern({ role: 'admin', level: Number }, (u) => <AdminPanel user={u} />),
  pattern({ role: 'editor', posts: Array }, (u) => <EditorPanel user={u} />),
  pattern(_, () => <GuestPanel />),
]);

把两者结合，SmartCheck 先确认数据结构，Patterns 再根据数据形状分发渲染。这样校验和路由放在同一个流水线上，组件主体只需关注 UI 的返回。

从现有组件迁移的三个步骤

第一步，保留 PropTypes 或 TypeScript 作为静态提示，同时引入 SmartCheck 和 Patterns。不要立即删除所有旧校验，而是先在新数据入口处增加运行时校验，例如在自定义 Hook 中统一处理 API 返回。

第二步，将组件内分散的 if/else 和 switch 替换为 match 表达式。先从最简单的角色分支开始，把每个条件分支映射为一个 pattern。注意模式顺序很重要，越具体的模式越靠前，通配模式放在最后。

第三步，把校验逻辑抽离到独立的 schema 文件中，形成可复用的数据契约。例如：

// schemas/userSchema.js
import { check } from 'smartcheck';
export const userSchema = {
  id: Number,
  name: String,
  role: /admin|editor|viewer/,
};
export function isValidUser(data) {
  return check(data, userSchema);
}

之后在 Hook 中调用 isValidUser，只把合法数据写入 state，非法数据走错误边界或降级 UI。这样可以避免组件内部出现大量防御性代码。

在 React 组件中落地模式匹配检测

假设有一个用户详情页，需要根据用户角色渲染不同的仪表板。迁移前，组件可能包含多个条件判断和默认返回值。迁移后，组件可以写成：

import { match, pattern } from 'patterns';
import { isValidUser } from './schemas/userSchema';
function UserDashboard({ apiData }) {
  const user = isValidUser(apiData) ? apiData : null;
  return match(user, [
    pattern(null, () => <ErrorState message="数据不合法" />),
    pattern({ role: 'admin' }, (u) => <AdminDashboard user={u} />),
    pattern({ role: 'editor' }, (u) => <EditorDashboard user={u} />),
    pattern(_, () => <ViewerDashboard />),
  ]);
}

这种写法的好处是，所有分支一眼可见，并且每个分支的参数都经过对应 pattern 约束。如果未来新增一种角色，只需在上方插入一条 pattern，不需要改动其他分支。

对于更复杂的嵌套数据，模式匹配也能表达。例如一个活动列表，每个活动可能是线上或线下类型：

const activityView = match(activity, [
  pattern({ type: 'online', url: String }, (a) => <OnlineCard link={a.url} />),
  pattern({ type: 'offline', address: String }, (a) => <OfflineCard address={a.address} />),
  pattern(_, () => <UnknownCard />),
]);

这种模式匹配比多层 if 更接近数据定义本身，可读性更高。

性能开销与调试建议

模式匹配会在每次渲染时执行，如果匹配逻辑复杂并且组件更新频繁，可能带来额外开销。建议使用 useMemo 缓存匹配结果，只有当依赖数据变化时才重新计算。例如：

const view = useMemo(() => match(user, [
  pattern(null, () => <Loading />),
  pattern({ role: 'admin' }, (u) => <AdminPanel user={u} />),
  pattern(_, () => <GuestPanel />),
]), [user]);

使用 useMemo 需要注意闭包依赖，把 user 作为依赖传入。如果 match 结果是一个 React 元素，直接缓存元素是安全的；如果结果是一个函数或需要进一步处理的值，则要谨慎。

调试方面，SmartCheck 的错误信息通常包含字段路径，建议在开发环境把校验失败的数据和 schema 打印到控制台。Patterns 如果没有匹配到任何分支并且没有通配模式，会抛出异常，因此一定要保留一个通配分支作为兜底。

最后，迁移不是一蹴而就的。可以先把所有 API 返回的数据层接入 SmartCheck，再把组件内部最复杂的条件分支替换为 Patterns 匹配，逐步降低回归风险。