docs(cn): translate content/blog/2022-06-15-react-labs-what-we-have-b…

…een-working-on-june-2022.md into Chinese (#870)

Co-authored-by: Xuan Huang (黄玄) <huxpro@gmail.com>
Co-authored-by: yongdu.lhb <yongdu.lhb@alibaba-inc.com>
Co-authored-by: KnowsCount <knowscount@gmail.com>

content/blog/2022-06-15-react-labs-what-we-have-been-working-on-june-2022.md

@@ -3,68 +3,67 @@ title: "React Labs: What We've Been Working On – June 2022"
 author: [acdlite,gaearon,kassens,josephsavona,joshcstory,laurentan,lunaruan,mengdichen,rickhanlonii,robertzhang,gsathya,sebmarkbage,huxpro]
 ---
 
-[React 18](https://reactjs.org/blog/2022/03/29/react-v18.html) was years in the making, and with it brought valuable lessons for the React team. Its release was the result of many years of research and exploring many paths. Some of those paths were successful; many more were dead-ends that led to new insights. One lesson we’ve learned is that it’s frustrating for the community to wait for new features without having insight into these paths that we’re exploring.
+[React 18](https://reactjs.org/blog/2022/03/29/react-v18.html)  已经酝酿多年，它为 React 团队带来了宝贵的经验。它的发布是多年的研究和众多路线探索的结果。其中一些路线是成功的；更多的则是在进入了死胡同后换来了新的洞见。我们学到的一个教训是，社区一直在等待新功能的发布，却没有深入了解我们正在探索的这些路线，这让我们很沮丧。
 
-We typically have a number of projects being worked on at any time, ranging from the more experimental to the clearly defined. Looking ahead, we’d like to start regularly sharing more about what we’ve been working on with the community across these projects.
+通常，在任何时候，我们都有许多项目在同时进行，从更具实验性的到明确定义的。以后，我们希望开始定期分享更多我们在这些项目中与社区相关的内容。
 
-To set expectations, this is not a roadmap with clear timelines. Many of these projects are under active research and are difficult to put concrete ship dates on. They may possibly never even ship in their current iteration depending on what we learn. Instead, we want to share with you the problem spaces we’re actively thinking about, and what we’ve learned so far.
+大家要有一些心理预期，这并没有一个有明确时间表。其中许多项目正在积极研究中，很难确定具体的发布日期。根据我们目前的评估，应该不会在当前的迭代中发布。虽然这样，我们还是想与你分享我们正在积极思考哪些问题，以及我们迄今为止已经有所认识的东西。
 
-## Server Components {#server-components}
+## 服务器组件 {#server-components}
 
-We announced an [experimental demo of React Server Components](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html) (RSC) in December 2020. Since then we’ve been finishing up its dependencies in React 18, and working on changes inspired by experimental feedback.
+我们于 2020 年 12 月宣布了  [React 服务器组件 (RSC) 的实验性方案](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html) 。从那时起，我们就一直在 React 18 里去完成对他的支持，并致力于根据实验反馈对他进行改进。
 
-In particular, we’re abandoning the idea of having forked I/O libraries (eg react-fetch), and instead adopting an async/await model for better compatibility. This doesn’t technically block RSC’s release because you can also use routers for data fetching. Another change is that we’re also moving away from the file extension approach in favor of [annotating boundaries](https://github.com/reactjs/rfcs/pull/189#issuecomment-1116482278).
+特别是，我们放弃了使用 I/O libraries（例如 react-fetch）的想法，而是采用 async/await 模型以获得更好的兼容性。这在技术上并不会阻碍 RSC 的发布，因为你还可以使用 routers 来获取数据。另一个变化是我们已经不用文件扩展名这种方式，转而支持 [注释边界（annotating boundaries）](https://github.com/reactjs/rfcs/pull/189#issuecomment-1116482278)。
 
-We’re working together with Vercel and Shopify to unify bundler support for shared semantics in both Webpack and Vite. Before launch, we want to make sure that the semantics of RSCs are the same across the whole React ecosystem. This is the major blocker for reaching stable.
+我们正在与 Vercel 和 Shopify 合作，在 Webpack 与 Vite 中找到通用的语义来统一 bundler 的支持。在发布之前，我们希望确保 RSC 的语义在整个 React 生态系统中是相同的，这样才能达到稳定。
 
-## Asset Loading {#asset-loading}
+## 静态资源加载 {#asset-loading}
 
-Currently, assets like scripts, external styles, fonts, and images are typically preloaded and loaded using external systems. This can make it tricky to coordinate across new environments like streaming, server components, and more.
-We’re looking at adding APIs to preload and load deduplicated external assets through React APIs that work in all React environments.
+目前，脚本、外部样式、字体和图像等资产通常是使用外部系统预加载或者实时加载的。这会使跨新环境（如流、服务器组件等）进行协调变得很棘手。我们正在考虑添加新的 API 使得预加载与去重加载外部资产可以在任何 React 环境中通过 React 第一方的 API 表达。
 
-We’re also looking at having these support Suspense so you can have images, CSS, and fonts that block display until they’re loaded but don’t block streaming and concurrent rendering. This can help avoid [“popcorning“](https://twitter.com/sebmarkbage/status/1516852731251724293) as the visuals pop and layout shifts.
+我们也在考虑让他们支持 Suspense，这样你就可以让图像、CSS 和字体在加载之前阻塞显示，但不会阻塞流式传输（streaming）和并发渲染（concurrent rendering）。这有助于避免在视觉效果和布局发生变化时出现 [“爆米花“](https://twitter.com/sebmarkbage/status/1516852731251724293)。
 
-## Static Server Rendering Optimizations {#static-server-rendering-optimizations}
+## 静态服务端渲染优化 {#static-server-rendering-optimizations}
 
-Static Site Generation (SSG) and Incremental Static Regeneration (ISR) are great ways to get performance for cacheable pages, but we think we can add features to improve performance of dynamic Server Side Rendering (SSR) – especially when most but not all of the content is cacheable. We're exploring ways to optimize server rendering utilizing compilation and static passes.
+静态站点生成 (SSG) 和增量静态重新生成 (ISR) 是获得可缓存页面性能的好方法，但我们认为我们可以添加功能来提高动态服务器端渲染 (SSR) 的性能——特别是当大多数内容是可缓存的时候。我们正在探索利用编译（compilation）静态优化服务器渲染的方法。
 
-## React Optimizing Compiler {#react-compiler}
+## React 优化编译器 {#react-compiler}
 
-We gave an [early preview](https://www.youtube.com/watch?v=lGEMwh32soc) of React Forget at React Conf 2021. It’s a compiler that automatically generates the equivalent of `useMemo` and `useCallback` calls to minimize the cost of re-rendering, while retaining React’s programming model.
+我们在 React Conf 2021 上[预告](https://www.youtube.com/watch?v=lGEMwh32soc) 了 React Forget 项目。它是一个可以自动生成等效于 useMemo 和 useCallback 代码的编译器，旨在保持 React 现有的编程模型的前提下最小化重新渲染的成本。
 
-Recently, we finished a rewrite of the compiler to make it more reliable and capable. This new architecture allows us to analyze and memoize more complex patterns such as the use of [local mutations](https://beta.reactjs.org/learn/keeping-components-pure#local-mutation-your-components-little-secret), and opens up many new compile-time optimization opportunities beyond just being on par with memoization hooks.
+最近，我们完成了对编译器的重写，使其更加可靠和强大。这种新架构使我们能够分析和缓存例如用了 [局部可变数据（local mutations）](https://beta.reactjs.org/learn/keeping-components-pure#local-mutation-your-components-little-secret) 等更复杂模式的代码，并开辟了许多新的编译时优化的机会，而不仅仅局限于现有 Hooks 能做的优化。
 
-We’re also working on a playground for exploring many aspects of the compiler. While the goal of the playground is to make development of the compiler easier, we think that it will make it easier to try it out and build intuition for what the compiler does. It reveals various insights into how it works under the hood, and live renders the compiler’s outputs as you type. This will be shipped together with the compiler when it’s released.
+我们还在开发一个用于探索编译器许多方面的 Playground 。虽然 Playground 的主要目标是使编译器的开发本身更容易，但我们认为它也将方便大家上手 Forget 以及了解 Forget 做了什么。它揭示了 Forget 背后的一些原理，并且可以实时渲染编译器的生成代码。它会编译器一起发布。
 
-## Offscreen {#offscreen}
+## 离屏 {#offscreen}
 
-Today, if you want to hide and show a component, you have two options. One is to add or remove it from the tree completely. The problem with this approach is that the state of your UI is lost each time you unmount, including state stored in the DOM, like scroll position.
+今天，如果你想隐藏和显示一个组件，你有两个选择。一种是从树中完全添加或删除它。这种方法的问题在于，每次卸载时 UI 的状态都会丢失，包括存储在 DOM 中的状态，例如滚动位置。
 
-The other option is to keep the component mounted and toggle the appearance visually using CSS. This preserves the state of your UI, but it comes at a performance cost, because React must keep rendering the hidden component and all of its children whenever it receives new updates.
+另一种选择是保持组件安装并使用 CSS 直观地切换外观。这会保留 UI 的状态，但会以性能为代价，因为 React 必须在收到新更新时不断渲染隐藏组件及其所有子组件。
 
-Offscreen introduces a third option: hide the UI visually, but deprioritize its content. The idea is similar in spirit to the `content-visibility` CSS property: when content is hidden, it doesn't need to stay in sync with the rest of the UI. React can defer the rendering work until the rest of the app is idle, or until the content becomes visible again.
+Offscreen 引入了第三种选择：在视觉上隐藏 UI，但降低其内容渲染的优先级。这个想法在本质上类似于 `content-visibility` CSS 属性：当内容被隐藏时，它不需要与 UI 的其余部分保持同步。React 可以推迟渲染工作，直到应用程序的其余部分空闲，或者直到内容再次可见。
 
-Offscreen is a low level capability that unlocks high level features. Similar to React's other concurrent features like `startTransition`, in most cases you won't interact with the Offscreen API directly, but instead via an opinionated framework to implement patterns like:
+Offscreen 只是一个底层能力，他的目的是解锁更高级的功能。与 React 的其他并发特性类似 `startTransition`，在大多数情况下，你不会直接与 Offscreen API 交互，而是通过一个完善的框架来实现以下模式：
 
-* **Instant transitions.** Some routing frameworks already prefetch data to speed up subsequent navigations, like when hovering over a link. With Offscreen, they'll also be able to prerender the next screen in the background.
-* **Reusable state.** Similarly, when navigating between routes or tabs, you can use Offscreen to preserve the state of the previous screen so you can switch back and pick up where you left off.
-* **Virtualized list rendering.** When displaying large lists of items, virtualized list frameworks will prerender more rows than are currently visible. You can use Offscreen to prerender the hidden rows at a lower priority than the visible items in the list.
-* **Backgrounded content.** We're also exploring a related feature for deprioritizing content in the background without hiding it, like when displaying a modal overlay.
+* **即时过渡（Instant transitions）**： 一些路由框架已经可以通过预加载数据来加速后续导航，例如悬停在链接上时。使用 Offscreen，他们还可以在后台预渲染下一个屏幕。
+* **可重用状态（Reusable state）**： 同样，在路线或选项卡之间导航时，你可以使用 Offscreen 来保留前一个屏幕的状态，以便你可以切换回来并从中断处继续。
+* **虚拟化列表渲染（Virtualized list rendering）**： 显示大型项目列表时，虚拟化列表框架将预呈现比当前可见的更多行。你可以使用 Offscreen 以低于列表中可见项目的优先级预呈现隐藏行。
+* **背景内容（Backgrounded content）**： 我们还在探索一项相关功能，用于在不隐藏背景的情况下降低内容渲染的优先级，例如在显示叠加层时。
 
-## Transition Tracing {#transition-tracing}
+## 过渡跟踪 {#transition-tracing}
 
-Currently, React has two profiling tools. The [original Profiler](https://reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html) shows an overview of all the commits in a profiling session. For each commit, it also shows all components that rendered and the amount of time it took for them to render. We also have a beta version of a [Timeline Profiler](https://github.com/reactwg/react-18/discussions/76) introduced in React 18 that shows when components schedule updates and when React works on these updates. Both of these profilers help developers identify performance problems in their code.
+目前，React 有两个分析工具。[最早的 Profiler](https://reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html)  显示了分析会话中所有提交的概览。对于每次提交，它还显示所有渲染的组件以及渲染它们所花费的时间。我们还有一个在 React 18 中引入的 [时间线（Timeline） Profiler](https://github.com/reactwg/react-18/discussions/76) 的 beta 版本，它显示组件何时安排更新以及 React 何时处理这些更新。这两个分析器都可以帮助开发人员识别代码中的性能问题。
 
-We’ve realized that developers don’t find knowing about individual slow commits or components out of context that useful. It’s more useful to know about what actually causes the slow commits. And that developers want to be able to track specific interactions (eg a button click, an initial load, or a page navigation) to watch for performance regressions and to understand why an interaction was slow and how to fix it.
+我们已经意识到，开发人员并没有发现，其实了解单个缓慢的提交或脱离上下文的组件是很有用的。了解导致缓慢提交的真正原因会更有用。并且开发人员希望能够跟踪特定的交互（例如按钮单击、初始加载或页面导航）以观察性能回归并了解交互缓慢的原因以及如何去修复它。
 
-We previously tried to solve this issue by creating an [Interaction Tracing API](https://gist.github.com/bvaughn/8de925562903afd2e7a12554adcdda16), but it had some fundamental design flaws that reduced the accuracy of tracking why an interaction was slow and sometimes resulted in interactions never ending. We ended up [removing this API](https://github.com/facebook/react/pull/20037) because of these issues.
+我们之前尝试通过创建 [交互跟踪 API](https://gist.github.com/bvaughn/8de925562903afd2e7a12554adcdda16) 来解决这个问题，但它存在一些降低跟踪交互缓慢原因准确性的基本设计缺陷，有时会导致交互永无止境。由于这些问题，我们最终 [移除了这个 API](https://github.com/facebook/react/pull/20037) 。
 
-We are working on a new version for the Interaction Tracing API (tentatively called Transition Tracing because it is initiated via `startTransition`) that solves these problems.
+我们正在开发一个新版本的交互跟踪 API（暂时称为转换跟踪，因为它是通过 `startTransition` 开启的）来解决这些问题。
 
-## New React Docs {#new-react-docs}
+## 新的 React 文档 {#new-react-docs}
 
-Last year, we announced the [beta version](https://beta.reactjs.org/) of the new React documentation website. The new learning materials teach Hooks first and has new diagrams, illustrations, as well as many interactive examples and challenges. We took a break from that work to focus on the React 18 release, but now that React 18 is out, we’re actively working to finish and ship the new documentation.
+去年，我们宣布了新的 React 文档网站的 [beta 版本](https://beta.reactjs.org/) ，新的学习材料从 Hooks 开始，并有新的图表、插图以及许多交互式示例和挑战。之前我们因为要专注于 React 18 的开发而暂停了这项工作，但现在既然 React 18 已经发布，我们就开始积极努力地完成与发布新文档了。
 
-We are currently writing a detailed section about effects, as we’ve heard that is one of the more challenging topics for both new and experienced React users. [Synchronizing with Effects](https://beta.reactjs.org/learn/synchronizing-with-effects) is the first published page in the series, and there are more to come in the following weeks. When we first started writing a detailed section about effects, we’ve realized that many common effect patterns can be simplified by adding a new primitive to React. We’ve shared some initial thoughts on that in the [useEvent RFC](https://github.com/reactjs/rfcs/pull/220). It is currently in early research, and we are still iterating on the idea. We appreciate the community’s comments on the RFC so far, as well as the [feedback](https://github.com/reactjs/reactjs.org/issues/3308) and contributions to the ongoing documentation rewrite. We’d specifically like to thank [Harish Kumar](https://github.com/harish-sethuraman) for submitting and reviewing many improvements to the new website implementation.
+我们目前正在写一个关于 effects 的详细章节，因为我们这听说对于新的和有经验的 React 用户来说都是相对具有挑战性的主题之一。[与 Effects 同步](https://beta.reactjs.org/learn/synchronizing-with-effects) 是该系列中的第一篇文章，接下来几周我们还会发布更多内容。当我们第一次开始编写有关 effects 的详细部分时，我们已经意识到可以通过向 React 添加新的原始 API 来简化许多常见的 effects 模式。[useEvent RFC](https://github.com/reactjs/rfcs/pull/220) 中分享了一些初步想法。它目前处于早期研究阶段，我们仍在迭代这个想法。我们感谢社区迄今为止对 RFC 的评论，以及对正在进行的文档重写的 [反馈](https://github.com/reactjs/reactjs.org/issues/3308) 和贡献。我们要特别感谢 [Harish Kumar](https://github.com/harish-sethuraman) 提交并审查了对新网站实施的诸多改进。
 
-*Thanks to [Sophie Alpert](https://twitter.com/sophiebits) for reviewing this blog post!*
+*感谢 [Sophie Alpert](https://twitter.com/sophiebits) 对本篇文章的校对!*