咱们好，这里是咱们的林语冰。继续重视，坚持阅览，每天一次，前进一点。
免责声明
本文属所以语冰的直男翻译了属所以，略有修改，仅供粉丝参阅。英文原味版请传送 React Labs: What We’ve Been Working On。
本期同享的是 —— React 团队的官方博客去年最新作业发展的作业报告。
RSC（React 服务器组件）
RSC（React Server Components）是 React 团队规划的一种新式 App 架构。
咱们首要在官宣演讲和 RFC（征求意见稿）中同享了 RSC 的研讨。温故知新，咱们引进了一种新式组件 —— RSC，它会提早运转，并被扫除在 JS 打包外。RSC 可在构建时运转，让咱们从文件体系读取或恳求静态内容。RSC 还能够在服务器运转，让咱们无需构建 API 即可读写数据层。咱们能够经过 props 将数据从 RSC 传递到浏览器的交互式客户端组件。
RSC 把以服务器为中心的 MPA（多页面应用程序）的简略“恳求/呼应”思维模型、与以客户端为中心的 SPA（单页应用程序）的无缝交互性完美结合，为咱们供给两全其美的体验。
咱们合并了 RSC RFC 来同意该提案。咱们处理了 React 服务器模块约好提案中的典型问题，并与合伙人达到共识，遵从 "use client" 约好。这些文档还充当 RSC 兼容完成应该支撑的规范。
严重改变在于，咱们引进了 async/await 作为从 RSC 恳求数据的主要方案。咱们还方案经过引进一个新式 Hook 来解包 Promises，支撑从客户端加载数据。尽管咱们无法在纯客户端 App 的恣意组件中支撑 async/await，但咱们方案在咱们构建类似于 RSC App 结构的纯客户端 App 时，添加对它的支撑。
现在咱们现已对数据恳求稳当排序，咱们正在另辟蹊径：将数据从客户端发送到服务器，这样咱们能够执行数据库改变并完成表单。咱们经过答应咱们跨服务器/客户端边界传递 Server Actions（服务器操作）函数来完成，客户端能够调用该函数，供给无缝 RPC。Server Actions 还会在 JS 加载前，为咱们供给渐进增强的表单。
RSC 已在 Next App 路由中供给。这展示了路由的深度集成，真正将 RSC 作为原语，但这并不是构建 RSC 兼容路由和结构的不二法门。RSC 规范和完成供给的功用爱憎分明。RSC 旨在作为跨兼容 React 结构作业的组件规范。
咱们一般主张运用现有结构，但如果咱们需求构建自己的自界说结构，那也问题不大。构建自己的 RSC 兼容结构并非信手拈来，主要是因为需求深度打包器集成。现代的打包器十分适合在客户端运用，但它们的规划并没有为在服务器和客户端之间拆分单个模块图供给一流支撑。这便是咱们现在直接与打包器开发者梦幻联动，然后获得内置 RSC 的原语的原因。
资源加载
Suspense 答应咱们在组件的数据或代码仍在加载时，指定在屏幕上显示的内容。这能够在页面加载时、以及加载更多数据和代码的路由器导航期间，让咱们的用户逐渐看到更多内容。尽管可是，从用户视角来看，在考虑新内容是否准备就绪时，数据加载和烘托并不能说明悉数状况。默许状况下，浏览器独立加载样式表、字体和图画，这或许会导致 UI 跳转和连续布局改变。
咱们正在努力将 Suspense 与样式表、字体和图画的加载生命周期彻底集成，这样 React 会考虑它们，然后确定内容是否现已能够显示。在不改变咱们编写 React 组件办法的状况下，更新会以愈加连接和令人愉悦的办法进行。作为优化之一，咱们还会供给一种手动办法，直接从组件预加载字体等资源。
文档元数据
App 中的不同页面和屏幕或许具有不同的元数据（metadata），比方 <title> 标签、描绘、以及此屏幕专属的其他 <meta> 标签。从保护的视点来看，将这些信息保存在该页面或屏幕的 React 组件附近更具可扩展性。尽管可是，此元数据的 HTML 标签需求坐落该文档的 <head> 标签中，该文档一般在 App 根目录的组件中烘托。
今天，咱们用两大技能中之一来处理此问题。
一种技能是烘托一个特殊的第三方组件，将其内的 <title>、<meta> 和其他标签移动到文档的 <head> 标签中。这适用于干流浏览器，但有一大坨客户端不运转客户端 JS，比方 Open Graph 解析器，因此该技能并不普适。
另一种技能是将页面分为两部分进行 SSR（服务端烘托）。首要，烘托主要内容，并收集所有此类标签。然后，运用这些标签烘托 <head> 标签。最终，<head> 标签和主要内容被发送到浏览器。这种办法可行，但它会阻止咱们运用 React 18 的流服务器烘托器，因为咱们有必要等待所有内容烘托后，才能发送 <head> 标签。
这便是咱们在组件树中的恣意方位添加对烘托 <title>、<meta> 和元数据 <link> 标签的内置支撑的原因。这在所有环境中都殊途同归，包括彻底客户端代码、SSR 以及未来的 RSC。
React 优化编译器
咱们一直在积极迭代 React Forget（React 的优化编译器）的规划。咱们之前曾称之为“主动记忆化编译器”，某种意义上而言，这当之无愧。但构建编译器辅佐咱们更深入地了解 React 的编程模型。了解 React Forget 的最佳方案是，将其视为主动呼应性编译器。
React 的中心思维是，开发者将其 UI 界说为当前状况的函数。咱们能够运用纯 JS 值（数字、方针）、并运用规范 JS 习惯用法（if/for 等），来描绘组件逻辑。其心智模型是，只需 App 状况改变，React 就会从头烘托。咱们深信这种简略的心智模型和保持挨近 JS 语义，是 React 编程模型的重要原则。
问题在于，React 有时或许过于被迫：它或许会过多从头烘托。举个栗子，在 JS 中，咱们没有廉价方案来比较两个方针是否等价，比方具有相同的键值，因此为每次烘托创立一个新的方针，严格而言或许会导致 React 做剩余的无用功。这意味着，开发者有必要显式记忆化组件，避免对改变过度反应。
咱们运用 React Forget 的方针在于，确保 React App 默许具有适量的呼应性：当且仅当状况值发生有意义的改变时，App 才会从头烘托。从完成的视点来看，这意味着主动记忆化，但咱们相信呼应性结构是了解 React 和 Forget 的更好方案。考虑此问题的办法之一是，React 现在会在方针标识更改时从头烘托。借助 Forget，React 会在语义值改变时从头烘托，但不会产生深度比较的运转时本钱。
就具体发展而言，咱们对编译器的规划大幅迭代，然后与这种主动呼应性方案对齐，并纳入内部运用编译器的反应。从去年年底开端，对编译器重量级重构之后，咱们现在开端在 Meta（前脸书）有限区域的出产中运用此编译器。一旦咱们在出产中公证有效，咱们方案将其开源。
最终，一大坨道友对编译器的作业原理感兴趣。当咱们验证编译器并将其开源时，咱们等待同享更多细节。但咱们现在能够爆料某些内容：
编译器中心简直与 Babel 彻底解耦，中心编译器 API（大致）是旧 AST 输入，新 AST 输出（同时保存源码方位数据）。在底层，咱们运用自界说代码表明和转化管道来剖析初级语义。尽管可是，编译器的主要公共接口会经过 Babel 和其他构建体系插件完成。为了便于测试，咱们现在有一个 Babel 插件，它是一个十分小型的包装器，它调用编译器来生成每个函数的新版别，并将其交换。
在过去几个月重构编译器时，咱们希望聚集于完善中心编译模型，确保咱们能够处理条件、循环、从头赋值和改变等复杂性。尽管可是，JS 存在一大坨方案来表达这些功用：if/else、三元组、for-of 等。测验预先支撑完好的言语会延迟咱们能够完成的方针 —— 验证中心模型。相反，咱们从该言语的一个“麻雀虽小、五脏俱全”的子集开端：let/const、if/else、for 循环、方针、函数调用和若干其他功用。跟着咱们对中心模型的信心倍增，并完善咱们的内部笼统，咱们扩展了支撑的言语子集。咱们还明确指出尚不支撑的语法、日志诊断，并跳过不支撑的输入的编译。咱们有实用程序能够在 Meta 的代码库上测验编译器，看看哪些不支撑的功用最常见，这样咱们就能够优先考虑后续功用。咱们会循序渐进地扩展，直到支撑整个言语。
在 React 组件中制造简略的 JS 呼应式需求编译器对语义有深度了解，这样它才能精准了解代码的行为。经过采用这种方案，咱们正在创立一个 JS 呼应性体系，让咱们能够运用言语的完好表达能力编写任何复杂性的产品代码，而不受限于领域特定言语。
离屏烘托
离屏烘托是 React 中即将推出的一项功用，用于在后台烘托屏幕，而无需额定的功能开支。咱们能够将其视为 content-visibility CSS 特点的一个版别，它不仅适用于 DOM 元素，也适用于 React 组件。在咱们的研讨过程中，咱们发现了各种用例：
- 路由能够在后台预烘托屏幕，这样当用户导航到它们时，它们立即可用。
- 选项卡切换组件能够保存躲藏选项卡的状况，这样用户能够在它们之间切换不会丢掉进度。
- 虚拟列表组件能够在可见窗口上下方预烘托附加行。
- 打开形式或弹出窗口时，App 的其余部分能够置于“后台”形式，这样对除形式之外的所有内容禁用事件和更新。
大多数 React 开发者不会直接与 React 屏幕外 API 的交互。相反，离屏烘托将被集成到路由和 UI 库之类的东东中，然后运用这些库的开发者会主动受益，而无需额定的作业。
此主意指的是，咱们应该能够在屏幕外烘托任何 React 树，而无需更改编写组件的办法。当组件在屏幕外烘托时，它实际上不会安装，直到该组件变得可见 —— 它的 effect（作用）不会被触发。举个栗子，如果某个组件在初次出现时运用 useEffect 来打印剖析，那么预烘托不会影响这些剖析的准确性。相同，当组件离开屏幕时，其 effect 也会被卸载。离屏烘托的一个要害功用在于，咱们能够切换组件的可见性，而不会丢掉其状况。
咱们在 Android 和 iOS 的 React Native App 中，于 Meta 内部测试了预烘托的试验版别，并取得了积极的功能成果。咱们还改进了离屏烘托与 Suspense 的配合办法 —— 在离屏树内暂停，不会触发 Suspense 回退。咱们余下的作业包括最终确定向库开发者揭露的原语。咱们估计在今年晚些时候发布 RFC，以及用于测试和反应的试验性 API。
转化追寻
Transition Tracing API 可让咱们检测 React Transitions 何时变慢，并调查它们变慢的原因。咱们完成了此 API 的初步规划，并发布了 RFC。基本功用也现已完成。该项目现在处于放置状况。咱们欢迎对 RFC 的反应，并等待恢复其开发，为 React 供给更好的功能测量东西。这关于构建在 React Transitions 之上的路由器（比方 Next App 路由）特别有用。
本期论题是 —— React 18 用的最爽、最等待的新功用是哪一个？
欢迎在本文下方群聊自由言论，文明同享。谢谢咱们的点赞，掰掰~
《前端 9 点半》每日更新，继续重视，坚持阅览，每天一次，前进一点。
