大家好，我卡颂。

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

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

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

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

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

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

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

从React16聊起

近年来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之前的个性迭代流程是：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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为始，但为了呈现在稳固版本中，须要以笼罩全场景为终，天然进步了交付难度。

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

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

举两个例子，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的触发逻辑又会变得更简单。

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

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

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

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

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

总结

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

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

那为什么下个稳固版本不是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颁布。