From b26be2b8624b459a9ac6bb3b0377976392bb84a5 Mon Sep 17 00:00:00 2001 From: Yucohny Date: Fri, 7 Jul 2023 15:09:38 +0800 Subject: [PATCH] docs(cn): translate blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022 --- ...-what-we-have-been-working-on-june-2022.md | 73 ++++++++++--------- 1 file changed, 37 insertions(+), 36 deletions(-) diff --git a/src/content/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022.md b/src/content/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022.md index a689614844..f7ff1b5d3b 100644 --- a/src/content/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022.md +++ b/src/content/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022.md @@ -1,79 +1,80 @@ --- -title: "React Labs: What We've Been Working On – June 2022" +title: "React Labs：我们正在努力的方向——2022 年 6 月" --- -June 15, 2022 by [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Jan Kassens](https://twitter.com/kassens), [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Luna Ruan](https://twitter.com/lunaruan), [Mengdi Chen](https://twitter.com/mengdi_en), [Rick Hanlon](https://twitter.com/rickhanlonii), [Robert Zhang](https://twitter.com/jiaxuanzhang01), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Xuan Huang](https://twitter.com/Huxpro) +2022 年 6 月 15 日 [Andrew Clark](https://twitter.com/acdlite)、[Dan Abramov](https://twitter.com/dan_abramov)、[Jan Kassens](https://twitter.com/kassens)、[Joseph Savona](https://twitter.com/en_JS)、[Josh Story](https://twitter.com/joshcstory)、[Lauren Tan](https://twitter.com/potetotes)、[Luna Ruan](https://twitter.com/lunaruan)、[Mengdi Chen](https://twitter.com/mengdi_en)、[Rick Hanlon](https://twitter.com/rickhanlonii)、[Robert Zhang](https://twitter.com/jiaxuanzhang01)、[Sathya Gunasekaran](https://twitter.com/_gsathya)、[Sebastian Markbåge](https://twitter.com/sebmarkbage) 与 [Xuan Huang](https://twitter.com/Huxpro) --- -[React 18](https://reactjs.org/blog/2022/03/29/react-v18) 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) 经过多年的努力才得以问世，它为 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) (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 服务端组件](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components)（RSC）的实验性演示。从那时起，我们一直在完成 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 库（例如 react-fetch）的想法，转而采用了具有更好兼容性的 async/await 模型。这从技术上讲并不阻碍 RSC 的发布，因为还可以使用路由器进行数据获取。另一个变化是我们也放弃了文件扩展名的方法，而是采用了 [注释边界](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）对共享语义的支持。在发布之前，我们希望确保整个 React 生态系统中的 RSC 的语义是一致的。这是达到稳定状态的主要障碍。 -## 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. +目前，像脚本、外部样式、字体和图像等资源通常是通过预加载和外部系统加载的。这可能在新的环境（如流媒体、服务器组件等）之间协调起来比较棘手。 -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. +我们正在考虑通过 React API 添加预加载和加载去重的外部资源的 API，以在所有 React 环境中使用。 -## Static Server Rendering Optimizations {/*static-server-rendering-optimizations*/} +我们还正在研究如何支持 Suspense，这样就可以拥有在加载完成之前阻塞显示的图像、CSS 和字体，但不会阻塞流媒体和并发渲染。这可以帮助避免视觉上的 [popcorning](https://twitter.com/sebmarkbage/status/1516852731251724293) 现象，即视觉效果的突然出现和布局的变化 -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. +## 静态服务器渲染优化 {/*static-server-rendering-optimizations*/} -## React Optimizing Compiler {/*react-compiler*/} +静态站点生成（SSG）和增量静态再生成（ISR）是提高可缓存页面性能的好方法，但我们认为我们可以添加功能来改进动态服务器端渲染（SSR）的性能，特别是当大部分但不是全部内容都是可缓存的时候。我们正在探索利用编译和静态传递来优化服务器渲染的方式。 -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 优化编译器 {/*react-compiler*/} -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](/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. +我们在 React Conf 2021 上提供了 React Forget 的 [早期预览](https://www.youtube.com/watch?v=lGEMwh32soc)。它是一个编译器，可以自动生成等效的 `useMemo` 和 `useCallback` 调用，以最小化重新渲染的成本，同时保留 React 的编程模型。 -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. +最近，我们完成了编译器的重写，使其更可靠且功能更强大。这种新的架构使我们能够分析和缓存更复杂的模式，比如使用 [local mutation](/learn/keeping-components-pure#local-mutation-your-components-little-secret)，并开启了许多新的编译时优化机会，不仅仅与记忆化 hook 持平。 -## Offscreen {/*offscreen*/} +我们还正在开发一个用于探索编译器多个方面的 playground。尽管 playground 的目标是使编译器的开发变得更容易，但我们认为它将使尝试和建立对编译器工作方式的直观感觉变得更容易。它揭示了编译器在幕后的各种工作原理，并且可以在输入时实时渲染编译器的输出。它将与编译器一起发布。 -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. +## 离屏渲染 {/*offscreen*/} -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. +如今，如果你想隐藏和显示一个组件，有两种选择。一种是完全从树中添加或删除。这种方法的问题在于，每次卸载组件时，包括在 DOM 中存储的滚动位置在内的 UI 状态都会丢失。 -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. +另一种选择是保持组件挂载，并使用 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）引入了第三种选择：在视觉上隐藏 UI，但将其内容降低优先级。这个想法本质上类似于 `content-visibility` CSS 属性：当内容被隐藏时，它不需要与其他 UI 保持同步。React 可以将渲染工作推迟到应用程序的其他部分处于空闲状态，或者直到内容再次变得可见为止。 -* **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. +离屏渲染是一个低级能力，可以实现高级功能。类似于 React 的其他并发功能（如 `startTransition`），在大多数情况下，你不会直接与 Offscreen API 交互，而是通过一个偏好的框架来实现以下模式： + +* **即时过渡**。一些路由框架已经预取数据以加快后续导航，例如在悬停在链接上时。使用离屏渲染，它们还可以在后台预渲染下一个屏幕。 +* **可重用状态**。类似地，在路由或选项卡之间导航时，你可以使用离屏渲染来保留上一个屏幕的状态，以便你可以切换回来并继续之前的操作。 +* **虚拟化列表渲染**。显示大型项目列表时，虚拟化列表框架将预先渲染比当前可见行数更多的行。你可以使用离屏渲染以比列表中可见项目更低的优先级预渲染隐藏的行。 +* **后台内容**。我们还在探索一项相关功能，可以将后台内容降低优先级而不隐藏它，例如显示模态覆盖层时。 ## Transition Tracing {/*transition-tracing*/} -Currently, React has two profiling tools. The [original Profiler](https://legacy.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://legacy.reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html) 显示了性能分析会话中的所有提交的概览。对于每个提交，它还显示了所有已渲染组件以及它们渲染所花费的时间。我们还在 React 18 中引入了一个 [Timeline Profiler](https://github.com/reactwg/react-18/discussions/76) 的测试版本，它显示了组件何时安排更新以及 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` 发起，我们将其暂时称为 Transition Tracing），来解决这些问题。 -## New React Docs {/*new-react-docs*/} +## 新版文档 {/*new-react-docs*/} -Last year, we announced the beta version of the new React documentation website ([later shipped as react.dev](/blog/2023/03/16/introducing-react-dev)) 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.dev](/blog/2023/03/16/introducing-react-dev)）。新的学习材料首先介绍了 Hook，并提供了新的图表、插图，以及许多交互式示例和挑战。之前我们暂时中断了这项工作，专注于 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](/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. +我们目前正在撰写关于 effect 的详细部分，因为我们听说这是对新手和有经验的 React 用户来说最具挑战性的主题之一。[与 Effect 保持同步](/learn/synchronizing-with-effects) 是系列中首个发布的页面，接下来的几周还会有更多页面发布。当我们开始撰写关于 effect 的详细部分时，我们意识到许多常见的 effect 模式可以通过向 React 添加一个新的原语来简化。我们在 [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) 对本篇博客文章的审查！