关于前端:关于-React19你需要了解的前因后果

大家好，我卡颂。

React以后的稳固版本是 18.2，公布工夫是 22 年 6 月，在此之后就没有新的稳固版本公布。

直到往年 2 月 15 日，官网博客才走漏下一个稳固版本的打算。没错，他就是React19。

为什么时隔 1 年多才颁布下个稳固版本的打算？

为什么下个版本间接跳到了 19？

18 我都还没升呢，19 就来了，是不是要学很多货色？

这篇文章会为你具体解答这些疑难。

收费支付卡颂原创 React 教程（原价 359）、退出人类高质量前端群

近年来 React 最为人津津有味的版本应该是16.8，这个版本引入了Hooks，为React（乃至整个前端框架畛域）注入了新的生机。

再之后的 v17 没有新个性引入。既然没有新个性引入，为什么要公布一个大版本（从 16 到 17）呢？

这是因为从 同步更新 降级到 并发更新 的React，两头存在breaking change。

这么大体量的框架，在降级时须要保障过程尽可能平顺。这除了是一种业余、负责的体现，更重要的，版本割裂会造成大量用户损失（参考当年 ng1 降级到 anuglar2 时）。

当降级到 18 后，React 团队 发现 —— 真正降级到 18，并大量应用并发个性（比方useTransition）的开发者并不多。

更常见的场景是 —— 出名开源库集成并发个性，开发者再间接用这些库。

所以，React 团队 转变策略，将迭代重心从 赋能开发者 转变为 赋能开源库。那么，什么样的库受众最多呢？显然是框架。

所以，React的重心逐步变为 —— 赋能下层框架，开发者通过应用下层框架间接应用React。

为什么我说 React 团队 转变了策略，而不是 React 团队 一开始的打算就是 赋能下层框架 呢？

如果一开始的打算就是 赋能下层框架 ，React 团队 就不会花大量精力在 版本的渐进降级上 —— 反正开发者最终应用的会是下层框架（而不是React），版本割裂下层框架会解决，基本不须要疏导开发者降级React。

策略转变造成的影响是深远且宽泛的，这也是为什么 18.2 后一年多都没有新的稳固版本呈现。

最根本的影响是 —— 个性的迭代流程变了。

React诞生的初衷是为了解决 Meta 外部简单的前端利用，所以 React 之前的个性迭代流程是：

新个性开发实现
新个性在 React 外部产品试用，并最终达到稳固状态
开源供宽广开发者应用

但随着策略转变为 赋能下层框架，势必须要与支流下层框架团队（次要是Next.js）密切合作。

如果依照原来的迭代流程，下层框架团队属于 Meta 之外的第三方团队，只能等新个性开源后能力应用，这种单干模式显然太低效了。

于是，React团队提出了一个新的个性公布渠道 —— canary，即：新个性开发实现后，能够先打一个 canary 版本的 React 供内部试用，等个性稳固后再思考将其退出稳固版本中。

可能有些存在于 canary 中的个性永远不会呈现在稳固版本的 React 中，但不障碍一些开源库锁死 canary 版本的React，进而应用这些个性。

那么，为什么时隔 1 年多才颁布下个稳固版本的打算？次要有 4 个起因。

策略扭转除了影响 个性的迭代流程 ，还让React 团队成员 陷入一个两难的地步 —— 我该优先服务下层框架还是Meta？

咱们能够发现，在之前的迭代流程中，所有都围绕 Meta 本身需要开展。React 团队成员 作为 Meta 员工，这个迭代流程再天然不过。

然而，新的迭代流程须要亲密与 Next 团队单干，那么问题来了 —— 作为 Meta 员工，新个性应该优先思考 Next 的需要还是 Meta 的需要？

为了实现 赋能下层框架 的工作，显然应该更多思考 Next 的需要。咱们能看到一些 React 团队成员 最终跳槽到 Vercel，进入Next 团队。

所以，在此期间产出的个性（比方server action、useFormStatus、useFormState）更多是服务于Next，而不是React。

如果基于这些个性公布新的稳固版本，那不必 Next 的开发者用不到这些个性，用 Next 的开发者依赖的是canary React，所以此时降级稳固版本是没意义的。

Next是 web 框架，围绕他发明的新React 个性只用思考 web 这一场景。

但 React 本身的定位是 宿主环境无关的 UI 库 ，还有大量开发者在 非 web的环境应用 React（比方React Native），所以这些个性要呈现在稳固版本的React 中，必须保障他能适配所有环境。

举个例子，Server Actions这一个性，用于 简化客户端与服务器数据发送的流程 ，以后次要利用于Next 的App Router模式中。

比方上面代码中的 MyForm 组件，当表单提交后，serverAction函数的逻辑会在服务端执行，这样就能不便的进行 IO 操作（比方操作数据库）：

// 服务端代码

async function serverAction(event) {
  'use server'
  // 在这里解决服务端逻辑，比方数据库操作读写等
}

function MyForm() {
  return (<form action={serverAction}>
      <input name="query" />
      <button type="submit">Search</button>
    </form>
  );
}

App Router的场景次要是 RSC（React Server Component），除了RSC 外，SSR场景下是不是也有表单？不应用服务端相干性能，单纯应用 React 进行客户端渲染，是不是也有表单的场景？

所以，Server Actions个性起初改名为 Actions，因为不止Server 场景，其余场景也要反对Actions。

比方上面代码中，在客户端渲染的场景应用 Actions 个性：

// 前端代码

const search = async (event) => {event.preventDefault();
  const formData = new FormData(event.target);
  const query = formData.get('query');

  // 应用 fetch 或其余形式发送数据
  const response = await fetch('/search', /* 省略 */);

  // ... 解决响应
};

function MyForm() {
  return (<form action={search}>
      <input name="query" />
      <button type="submit">Search</button>
    </form>
  );
}

你认为这就完了？还早。form组件反对 Actions，那开发者自定义的组件能不能反对Actions 这种 前、后端交互模式？

比方上面的 Calendar 组件，之前通过 onSelect 事件响应交互：

<Calendar onSelect={eventHandler}>

当前能不能用 Actions 的模式响应交互：

<Calendar selectAction={action}>

如何将平平无奇的交互变成 Actions 交互 呢？React 团队 给出的答案是 —— 用 useTransition 包裹。所以，这前面又波及到 useTransition 性能的批改。

Actions只是一个例子，能够发现，尽管新个性是以 web 为始，但为了呈现在稳固版本中，须要以 笼罩全场景 为终，天然进步了交付难度。

新个性越来越多，老个性为了兼容这些新个性也必须作出批改，这须要大量的工夫开发、测试。

举两个例子，Suspense在 v16.6 就引入了，它 容许组件“期待”某些内容变得可用，并在此期间显示一个加载指示器（或其余后备内容）。

Suspense最后只反对懒加载组件（React.lazy）这一场景。随着 React 新个性不断涌现，Suspense又相继兼容了如下场景：

Actions提交后的期待场景
并发更新的期待场景
Selective Hydration的加载场景
RSC流式传输的期待场景
任何 data fetching 场景

为了兼容这些场景，Suspense的代码量曾经十分恐怖了，但开发者对此是无感知的。

再举个和 Suspense、useEffect 这两个个性相干的例子。

Suspense为什么能在 中间状态 与实现状态 之间切换？是因为在 Suspense 的源码中，他的外部存在一个 Offscreen 组件，用于实现两颗子 Fiber 树 的切换。

React 团队 心愿将 Offscreen 组件抽离成一个独自的新个性（新名字叫 Activity 组件），起到相似 Vue 中Keep-Alive组件的作用。

Activity组件既然能让组件显 / 隐，那势必会影响组件的 useEffect 的触发机会。毕竟，如果一个组件暗藏了，但他的 useEffect create 函数触发了，会是一件很奇怪的事件。

所以，为了落地 Activity 组件，useEffect的触发逻辑又会变得更简单。

尽管这一年 React 团队 开发了很多个性，但很多个性无奈独自交付，必须形成一个体系后再对立交付。

比方方才提到的 useFormStatus、useFormState 是服务于 Actions 个性的，Actions又是由 Server Actions 演变而来的，Server Actions又是RSC（React 服务端组件）体系下的个性。

独自将 useFormStatus 公布在稳固版本中是没意义的，他属于 RSC 体系下的一环。

所以，即便新个性曾经准备就绪，他所在的体系还没筹备好的话，那体系下的所有个性都不能在稳固版本中交付。

为什么时隔 1 年多才颁布下个稳固版本的打算？次要是 4 个起因：

新个性次要服务于 Next，没必要呈现在稳固版本中
新个性必须满足各种场景，交付难度大
老个性须要兼容的场景越来越多，工作量很大
个性必须造成体系能力交付

那为什么下个稳固版本不是 v18.x 而是 v19 呢？这是因为局部新个性（次要是 Asset Loading、Document Metadata 这两类个性）对于一些利用会产生breaking change，所以须要发一个大版本。

从上述 4 个起因中的第四点能够晓得，既然有 v19 的音讯，势必是因为 曾经有成体系的新个性能够交付，那是不是意味着要学很多货色呢？

这一点倒不必放心，如果你不必 Next，那你大概率不会接触到RSC，既然不会接触RSC，那么RSC 体系下的新个性你都不会用到。

v19 对你最大的影响可能就是新个性对老 API 的影响了，比方：

useContext变为use(promise)
Activity组件使 useEffect 的触发机会更简单（应该不会在 v19 的第一个版本中）

这些的学习老本都不大。

对于 v19 的进一步音讯，会在往年 5 月 15～16 的 React Conf 颁布。

关于前端:关于-React19你需要了解的前因后果

从 React16 聊起

策略扭转造成的影响

起因 1：新个性次要服务于 Next，没必要呈现在稳固版本中

起因 2：新个性必须满足各种场景，交付难度大

起因 3：老个性须要兼容的场景越来越多，工作量很大

起因 4：个性必须造成体系能力交付

总结

Just My Socks（注册教程内含优惠码）

关于前端:关于-React19你需要了解的前因后果

从 React16 聊起

策略扭转造成的影响

起因 1：新个性次要服务于 Next，没必要呈现在稳固版本中

起因 2：新个性必须满足各种场景，交付难度大

起因 3：老个性须要兼容的场景越来越多，工作量很大

起因 4：个性必须造成体系能力交付

总结

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）