React 16.x 蓝图[双语版]

React 16.x 蓝图   2018年11月27号, Dan Abramov
React 16.x Roadmap November 27, 2018 by Dan Abramov
你可能在以前的文章和演讲中已经据说过这些特性, 好比 "Hooks", "Suspense", 和 "Concurrent Rendering". 在该博文中, 咱们将看一下怎么将它们融合在一块儿和它们在 React 稳定版中可用的预期时间线.
You might have heard about features like "Hooks", "Suspense", and "Concurrent Rendering" in the previous blog posts and talks. In this post, we’ll look at how they fit together and the expected timeline for their availability in a stable release of React.
简而言之

tl;drhtml

咱们计划把 React 新特性的推出分为如下几个里程碑:
We plan to split the rollout of new React features into the following milestones:
  • React 16.6: Suspense for Code Splitting (already shipped)
  • React 16.7: React Hooks (~Q1 2019)
  • React 16.8: Concurrent Mode (~Q2 2019)
  • React 16.9: Suspense for Data Fetching (~Q3 2019)
这些都是预计, 细节可能会随着咱们的推动而改变. 这里还有至少两个项目咱们打算在 2019 年完成, 它们须要更多的探索而且尚未和特定的版本捆绑在一块儿.
These are estimates, and the details may change as we’re further along. There’s at least two more projects we plan to complete in 2019. They require more exploration and aren’t tied to a particular release yet:
  • Modernizing React DOM
  • Suspense for Server Rendering
咱们预计在接下来的几个月会更加清晰它们的发布时间线
We expect to get more clarity on their timeline in the coming months.
注意:
该文章只是一个蓝图 — 其中没有任何内容须要您当即关注. 当发布每个功能时, 咱们会发布一篇完整的文章宣布它们.
Note

This post is just a roadmap — there is nothing in it that requires your immediate attention. When each of these features are released, we’ll publish a full blog post announcing them.前端

发布时间线

Release Timelinereact

咱们对全部的这些功能如何组合在一块儿有个想法, 但咱们会在每个部分准备就绪以后发布它, 以便于你能够更快的测试并使用它们.在单独查看它们的时候, API 的设计看起来不是那么合理; 这篇文章列出了咱们计划的主要部分, 它能够帮助你了解总体状况.(参阅咱们的版本策略, 了解咱们对于稳定性的承诺)
We have a single vision for how all of these features fit together, but we’re releasing each part as soon as it is ready so that you can test and start using them sooner. The API design doesn’t always make sense when looking at one piece in isolation; this post lays out the major parts of our plan to help you see the whole picture. (See our versioning policy to learn more about our commitment to stability.)
逐步发布策略能够帮助咱们优化 API, 可是在某些事情还没有准备就绪的过渡时期可能使人感到迷惑. 让咱们看一下不一样的功能对于您的应用程序意味着什么, 他们如何关联, 以及什么时候开始学习和使用它们.
The gradual release strategy helps us refine the APIs, but the transitional period when some things aren’t ready can be confusing. Let’s look at what these different features mean for your app, how they relate to each other, and when you can expect to start learning and using them.
React 16.6: 为了代码分割的 Suspense (已发布)
React 16.6: Suspense for Code Splitting (shipped)
Suspense 是指 React 在组件等待某事时 "暂停" 渲染的新功能, 而且显示一个 loading 指示器. 在 React 16.6 中, Suspense 只支持一个使用场景: 懒加载组件使用 React.lazy() and <React.Suspense>.
Suspense refers to React’s new ability to "suspend" rendering while components are waiting for something, and display a loading indicator. In React 16.6, Suspense supports only one use case: lazy loading components with React.lazy() and <React.Suspense>.
const OtherComponent = React.lazy(() => import('./OtherComponent'));

function MyComponent() {
  return (
    <React.Suspense fallback={<Spinner />}> <div> <OtherComponent /> </div> </React.Suspense> ); } 复制代码
代码分割指南中记录了使用 React.lazy()<React.Suspense>来实现代码分割. 你能够在本文中找到另外一个实用的解释
Code splitting with React.lazy() with <React.Suspense> is documented in the Code Splitting guide. You can find another practical explanation in this article.
在 Facebook, 从七月份就已经开始使用 Suspense 来进行代码分割, 并指望它保持稳定. 在 16.6.0 的初始公开发布中有一些回归, 但它们在 16.6.3 中得以修复.
We have been using Suspense for code splitting at Facebook since July, and expect it to be stable. There’s been a few regressions in the initial public release in 16.6.0, but they were fixed in 16.6.3.
代码分割只是 Suspense 的第一步. 咱们对 Suspense 的长期远景包括让它处理数据获取(并与像 Apollo 这样的库集成).除了方便的编程模型, Suspense 也在 Concurrent Mode 下提供更好的用户体验. 你将在下面找到有关这些主题的信息.
Code splitting is just the first step for Suspense. Our longer term vision for Suspense involves letting it handle data fetching too (and integrate with libraries like Apollo). In addition to a convenient programming model, Suspense also provides better user experience in Concurrent Mode. You’ll find information about these topics further below.
React DOM: 从 React 16.6.0 可用
Status in React DOM: Available since React 16.6.0.
React DOM Server: 目前 Suspense 在服务端渲染中还不可用. 这不是由于缺少关注. 咱们已经开始研究一个新的异步服务端渲染器, 其将支持 Suspense, 可是这是一个大型项目, 须要占用 2019 年的大部分时间才能完成.
Status in React DOM Server: Suspense is not available in the server renderer yet. This isn’t for the lack of attention. We’ve started work on a new asynchronous server renderer that will support Suspense, but it’s a large project and will take a good chunk of 2019 to complete.
React Native: 拆包在 React Native 中并非那么有用. 可是在给模块 Promise 的时候, 没有什么技术阻止 React.lazy()<Suspense> 工做.
Status in React Native: Bundle splitting isn’t very useful in React Native, but there’s nothing technically preventing React.lazy() and <Suspense> from working when given a Promise to a module.
建议: 若是你只进行客户端渲染, 咱们建议普遍采用 React.lazy()<React.Suspense> 进行代码拆分 React 组件. 若是你进行服务端渲染, 你则必须接受等待, 直到新的服务端渲染器准备就绪.
Recommendation: If you only do client rendering, we recommend widely adopting React.lazy() and for code splitting React components. If you do server rendering, you’ll have to wait with adoption until the new server renderer is ready.
React 16.7: Hooks (~Q1 2019)
React 16.7: Hooks (~Q1 2019)
Hooks 容许你在函数组件中使用 state 和生命周期. 它们还容许你在组件之间重用有状态的逻辑, 而无需在树中引入无用的嵌套
Hooks let you use features like state and lifecycle from function components. They also let you reuse stateful logic between components without introducing extra nesting in your tree.
function Example() {
  // Declare a new state variable, which we'll call "count"
  const [count, setCount] = useState(0);

  return (
   <div> <p>You clicked {count} times</p> <button onClick={() => setCount(count + 1)}> Click me </button> </div>
 );
}
复制代码
Hooks 介绍概述 是个开始的好地方. 观看 这些演讲, 了解视频介绍和深度探讨. FAQ 应该能够回答你的大多数问题. 要了解更多 Hooks 背后的动机, 你能够阅读 这篇文章. 这个 RFC 讨论中解释了 Hooks 的 API 设计的一些基本原理.
Hooks introduction and overview are good places to start. Watch these talks for a video introduction and a deep dive. The FAQ should answer most of your further questions. To learn more about the motivation behind Hooks, you can read this article. Some of the rationale for the API design of Hooks is explained in this RFC thread reply.
从九月开始, 在 Facebook 就已经开始内部测试 Hooks. 咱们不但愿在实施中出现重大 bug. Hooks 如今仅仅在 React的 16.7 alpha 版本中可用. 一些 API 预期有可能在最终的 16.7 版本中被改变(详细信息请参阅 该评论 的结尾部分)
We have been dogfooding Hooks at Facebook since September. We don’t expect major bugs in the implementation. Hooks are only available in the 16.7 alpha versions of React. Some of their API is expected to change in the final 16.7 version (see the end of this comment for details).
Hooks 表明着咱们对于 React 将来的愿景. 它们解决了 React 用户直接体验问题(render props和高阶组件的 "wrapper hell", 生命周期方法中的逻辑重复), 以及咱们遇到的大规模 React 优化的问题(例如使用编译器在内联组件上遇到的困难(译者注: 详细的 issue 可见 here)). Hooks 不会抛弃类. 可是, 若是 Hooks 成功了, 有可能在一个将来的主版本中可能将类的支持移至一个单独的包中, 来减小 React 的默认包尺寸.
Hooks represent our vision for the future of React. They solve both problems that React users experience directly (“wrapper hell” of render props and higher-order components, duplication of logic in lifecycle methods), and the issues we’ve encountered optimizing React at scale (such as difficulties in inlining components with a compiler). Hooks don’t deprecate classes. However, if Hooks are successful, it is possible that in a future major release class support might move to a separate package, reducing the default bundle size of React.
React DOM: 支持 Hooks 的 reactreact-dom 的第一个版本是 16.7.0-alpha.0. 咱们预计在接下来的几个月发布更多的 alphas 版本(在本文书写时, 最新的版本为 16.7.0-alpha.2). 你能够经过安装 react@nextreact-dom@next 来尝试它们. 不要忘记更新 react-dom — 不然 Hooks 不会工做.
Status in React DOM: The first version of react and react-dom supporting Hooks is 16.7.0-alpha.0. We expect to publish more alphas over the next months (at the time of writing, the latest one is 16.7.0-alpha.2). You can try them by installing react@next with react-dom@next. Don’t forget to update react-dom — otherwise Hooks won’t work.
React DOM Server: react-dom 的 16.7 alpha 版本用 react-dom/server 来彻底支持 Hooks.
Status in React DOM Server: The same 16.7 alpha versions of react-dom fully support Hooks with react-dom/server.
React Native: 目前没有任何官方的支持在 React Native 中尝试 Hooks. 若是你喜欢冒险, 查看 此主题 来获取非官方指示. 这里有一个已知问题, useEffect 被触发的太晚, 仍然须要解决.
Status in React Native: There is no officially supported way to try Hooks in React Native yet. If you’re feeling adventurous, check out this thread for unofficial instructions. There is a known issue with useEffect firing too late which still needs to be solved.
建议: 当你准备好了, 咱们鼓励你在写新组件时开始尝试使用 Hooks.确保你的团队中的每个人都使用它们并熟悉本文档. 咱们不建议你将已存在的类重写为 Hooks, 除非你已经有计划去重写它们(例如: 修复 bugs). 在 这里 阅读有关采用策略的更多信息.
Recommendation: When you’re ready, we encourage you to start trying Hooks in new components you write. Make sure everyone on your team is on board with using them and familiar with this documentation. We don’t recommend rewriting your existing classes to Hooks unless you planned to rewrite them anyway (e.g. to fix bugs). Read more about the adoption strategy here.
React 16.8: Concurrent Mode (~Q2 2019)
React 16.8: Concurrent Mode (~Q2 2019)
Concurrent Mode 经过非阻塞主线程渲染组件树来让 React 应用程序更具响应性. 它是选择性的加入, 而且容许 React 来中断长时间的渲染(例如, 渲染新得到的故事), 去处理高优先级事件(例如, 文本输入或者是 hover). Concurrent Mode 还经过在快速的网络链接环境中跳过没必要要的 loading 状态来改善 Suspense 的用户体验.
Concurrent Mode lets React apps be more responsive by rendering component trees without blocking the main thread. It is opt-in and allows React to interrupt a long-running render (for example, rendering a new feed story) to handle a high-priority event (for example, text input or hover). Concurrent Mode also improves the user experience of Suspense by skipping unnecessary loading states on fast connections.
注意:
你以前可能已经据说过 Concurrent Mode 被称为 "async mode". 咱们已经将其名字改成 Concurrent Mode, 以突出显示 React 在不一样优先级上执行工做的能力. 这使得它与其余异步渲染的方法区别出来.
Note

You might have previously heard Concurrent Mode being referred to as “async mode”. We’ve changed the name to Concurrent Mode to highlight React’s ability to perform work on different priority levels. This sets it apart from other approaches to async rendering.git

// Two ways to opt in:

// 1. Part of an app (not final API)
<React.unstable_ConcurrentMode>
  <Something /> </React.unstable_ConcurrentMode> // 2. Whole app (not final API) ReactDOM.unstable_createRoot(domNode).render(<App />); 复制代码
目前尚未为 Concurrent Mode 写文档. 重要的是强调, 概念模型最初有可能不熟悉. 记录它的好处, 如何高效的使用它, 和它存在的缺陷是咱们的高度优先事项, 而且将其称为稳定的先决条件. 在此以前, Andrew 的演讲 是最好的介绍.
There is no documentation written for the Concurrent Mode yet. It is important to highlight that the conceptual model will likely be unfamiliar at first. Documenting its benefits, how to use it efficiently, and its pitfalls is a high priority for us, and will be a prerequisite for calling it stable. Until then, Andrew’s talk is the best introduction available.
Concurrent Mode 比 Hooks 更加精致.一些 API 目前尚未正确的 "连线", 而且没有作到被指望的样子. 在撰写本文时, 咱们不建议将其用于除了早期试验以外的任何事情. 咱们预计并发模式自己并不存在不少错误, 但请注意, 在 <React.StrictMode> 中产生警告的组件可能没法正常工做. 另外, 咱们已经看到 Concurrent Mode 在其余代码中面临性能问题, 这些问题有时被误认为是 Concurrent Mode 自身的性能问题. 例如, 一个运行在每毫秒的无主的 setInterval(fn, 1) 调用在 Concurrent Mode 下将会有更差的影响. 咱们计划发布更多关于诊断和解决此类问题的向导, 做为 16.8 发布文档的一部分.
Concurrent Mode is much less polished than Hooks. Some APIs aren’t properly "wired up" yet and don’t do what they’re expected to. At the time of writing this post, we don’t recommend using it for anything except very early experimentation. We don’t expect many bugs in Concurrent Mode itself, but note that components that produce warnings in may not work correctly. On a separate note, we’ve seen that Concurrent Mode surfaces performance problems in other code which can sometimes be mistaken for performance issues in Concurrent Mode itself. For example, a stray setInterval(fn, 1) call that runs every millisecond would have a worse effect in Concurrent Mode. We plan to publish more guidance about diagnosing and fixing issues like this as part of the 16.8 release documentation.
Concurrent Mode 是咱们对于 React 愿景的一个重要部分. 对于 CPU 密集型工做, 它容许非阻塞渲染, 并在渲染复杂组件树的时候保持你的应用程序的响应. 这是咱们在 JSConf 冰岛演讲 的第一部分演示的. Concurrent 也令 Suspense 更好. 它容许你避免闪烁加载 loading 指示器, 若是网络足够快. 可是没有看到实例很难解释, 因此 Andrew 的演讲 是目前最好的资源. Concurrent Mode 依赖于协做主线程调度程序, 咱们正在与 Chrome 团队合做, 最终将此功能带到浏览器自己.
Concurrent Mode is a big part of our vision for React. For CPU-bound work, it allows non-blocking rendering and keeps your app responsive while rendering complex component trees. That’s demoed in the first part of our JSConf Iceland talk. Concurrent Mode also makes Suspense better. It lets you avoid flickering a loading indicator if the network is fast enough. It’s hard to explain without seeing so Andrew’s talk is the best resource available today. Concurrent Mode relies on a cooperative main thread scheduler, and we are collaborating with the Chrome team to eventually move this functionality into the browser itself.
React DOM: 一个很是不稳定的 Concurrent Mode 版本, 在 React 16.6 中以 unstable_ 前缀存在, 可是咱们不推荐尝试它, 除非你愿意常常遇到障碍或者缺乏功能. 16.7 alpha 版本包括没有 unstable__ 前缀的 React.ConcurrentModeReactDOM.createRoot, 可是咱们可能在 16.7 中保持前缀, 而且只在 React 16.8 中记录和标记 Concurrent Mode 为稳定.
Status in React DOM: A very unstable version of Concurrent Mode is available behind an unstable_ prefix in React 16.6 but we don’t recommend trying it unless you’re willing to often run into walls or missing features. The 16.7 alphas include React.ConcurrentMode and ReactDOM.createRoot without an unstable_ prefix, but we’ll likely keep the prefix in 16.7, and only document and mark Concurrent Mode as stable in React 16.8.
React DOM Server: Concurrent Mode 不会直接影响服务端渲染. 它将工做在已经存在的服务端渲染中.
Status in React DOM Server: Concurrent Mode doesn’t directly affect server rendering. It will work with the existing server renderer.
React Native: 目前的计划是延迟在 React Native 中启用 Concurrent Mode, 直到 React Fabric 项目接近完成.
Status in React Native: The current plan is to delay enabling Concurrent Mode in React Native until React Fabric project is near completion.
建议: 若是你但愿在将来采用 Concurrent Mode, 在 <React.StrictMode> 中包装一些组件子树并修复生成的警告是很好的第一步. 一般, 旧代码预计不会当即兼容. 例如, 在 Facebook, 咱们主要打算在最近开发的代码库中使用 Concurrent Mode, 并在不久的未来保持旧代码运行在同步模式下.
Recommendation: If you wish to adopt Concurrent Mode in the future, wrapping some component subtrees in and fixing the resulting warnings is a good first step. In general it’s not expected that legacy code would immediately be compatible. For example, at Facebook we mostly intend to use the Concurrent Mode in the more recently developed codebases, and keep the legacy ones running in the synchronous mode for the near future.
React 16.9: 为了数据获取的 Suspense (~mid 2019)
React 16.8: Concurrent Mode (~Q2 2019)
如前所述, Suspense 指的是可以在组件等待某事的时候 "暂停" 渲染的能力, 而且显示一个 loading 指示器. 在已经发布的 16.6 版本中, Suspense 惟一支持的使用场景就是代码分割. 在将来的 16.9 版本中, 咱们还但愿在使用它在为了获取数据的场景下提供官方的支持. 咱们将提供与 Suspense 兼容的一个基础的 "React Cache" 的参考实现, 可是你也能够写一个你本身的. 数据获取库, 像 Apollo 和 Relay, 将可以经过遵循咱们将要记录的简单规范来与 Suspense 集成.
As mentioned earlier, Suspense refers to React’s ability to “suspend” rendering while components are waiting for something, and display a loading indicator. In the already shipped React 16.6, the only supported use case for Suspense is code splitting. In the future 16.9 release, we’d like to provide officially supported ways to use it for data fetching too. We’ll provide a reference implementation of a basic "React Cache" that’s compatible with Suspense, but you can also write your own. Data fetching libraries like Apollo and Relay will be able to integrate with Suspense by following a simple specification that we’ll document.
// React Cache for simple data fetching (not final API)
import {unstable_createResource} from 'react-cache';

// Tell React Cache how to fetch your data
const TodoResource = unstable_createResource(fetchTodo);

function Todo(props) {
  // Suspends until the data is in the cache
  const todo = TodoResource.read(props.id);
  return <li>{todo.title}</li>;
}

function App() {
  return (
    // Same Suspense component you already use for code splitting
    // would be able to handle data fetching too.
    <React.Suspense fallback={<Spinner />}>
      <ul>
        {/* Siblings fetch in parallel */}
        <Todo id="1" />
        <Todo id="2" />
      </ul>
    </React.Suspense>
  );
}

// Other libraries like Apollo and Relay can also
// provide Suspense integrations with similar APIs.
复制代码
目前尚未官方的文档说明如何使用 Suspense 获取数据, 可是你能够在 此演讲这个小型 demo 中找到一些早期信息. 咱们将在 React 16.9 发布左右编写 React Cache 的文档(以及如何编写本身的 Suspense 兼容库), 可是若是你很好奇, 你能够在 这里 找到它的很是早期的源码
There is no official documentation for how to fetch data with Suspense yet, but you can find some early information in this talk and this small demo. We’ll write documentation for React Cache (and how to write your own Suspense-compatible library) closer to the React 16.9 release, but if you’re curious, you can find its very early source code here.
其实在 React 16.6 中, 底层 Suspense 机制(暂停渲染而且显示 loading 组件)就预计稳定了. 咱们已经在生产环境中使用它用来代码分割数月了. 可是, 用来数据获取的上层 API 还很是不稳定. React Cache 正在迅速变化, 而且至少会改变几回.有一些底层的 API 缺乏高级 API 可用. 除非是早期试验, 不然咱们不建议在任何地方使用 React Cache. 注意 React Cache 自身并不严格依赖于 React 版本, 并且当前的 alphas 版本缺乏基础特性, 例如缓存失效. 你很快就会遇到障碍. 咱们预计在 React 16.9 版本中有一些东西可用.
The low-level Suspense mechanism (suspending rendering and showing a fallback) is expected to be stable even in React 16.6. We’ve used it for code splitting in production for months. However, the higher-level APIs for data fetching are very unstable. React Cache is rapidly changing, and will change at least a few more times. There are some low-level APIs that are missing for a good higher-level API to be possible. We don’t recommend using React Cache anywhere except very early experiments. Note that React Cache itself isn’t strictly tied to React releases, but the current alphas lack basic features as cache invalidation, and you’ll run into a wall very soon. We expect to have something usable with the React 16.9 release.
最终咱们但愿经过 Suspense 来获取大多数数据, 可是这须要很长的事件, 直到全部的集成都准备就绪. 在实践中, 咱们指望可使用很是递进式的采用, 而且一般经过 Apollo 和 Relay 这样的中间层使用, 而不是直接使用. 缺乏上层 API 并非惟一的障碍 — 还有有些很是重要的 UI 模式咱们尚未支持, 例如在加载器视图层次结构以外显示进度指示器. 与往常同样, 咱们将在本博客的发布说明中传达咱们的进展.
Eventually we’d like most data fetching to happen through Suspense but it will take a long time until all integrations are ready. In practice we expect it to be adopted very incrementally, and often through layers like Apollo or Relay rather than directly. Missing higher level APIs aren’t the only obstacle — there are also some important UI patterns we don’t support yet such as showing progress indicator outside of the loading view hierarchy. As always, we will communicate our progress in the release notes on this blog.
React DOM 和 React Native: 从技术的角度来看, 在 React 16.6 中一个兼容的 cache 就已经能够和 <React.Suspense> 工做了. 可是, 在 React 次级版本发布以前咱们尚未拥有一个好的 cache 实现. 若是你是勇于冒险的, 你能够经过查看 React Cache alphas 来尝试写一个你本身的 cache. 可是, 请注意, 心智模型(译者注: 关于心智模型见 here)是彻底不一样的, 在文档准备好以前误解的可能性很是高.
Status in React DOM and React Native: Technically, a compatible cache would already work with <React.Suspense> in React 16.6. However, we don’t expect to have a good cache implementation until this React minor release. If you’re feeling adventurous, you can try to write your own cache by looking at the React Cache alphas. However, note that the mental model is sufficiently different that there’s a high risk of misunderstanding it until the docs are ready.
React DOM Server: 目前 Suspense 在服务端渲染中还不可用. 正如咱们前面提到的, 咱们已经开始研究一个新的异步服务端渲染器,它将支持Suspense,但它是一个大型项目,须要2019年的大部分时间才能完成.
Status in React DOM Server: Suspense is not available in the server renderer yet. As we mentioned earlier, we’ve started work on a new asynchronous server renderer that will support Suspense, but it’s a large project and will take a good chunk of 2019 to complete.
建议: 为了使用数据获取的 Suspense, 请等待该 React 次级版本发布. 不要在 16.6 版本中尝试为了数据获取使用 Suspense 特性; 还不支持. 可是当 数据获取的 Suspense 成为官方支持的时候, 现存的为了代码分割的 <Suspense> 组件也将能够正常显示 loading 状态.
Recommendation: Wait for this minor React release in order to use Suspense for data fetching. Don’t try to use Suspense features in 16.6 for it; it’s not supported. However, your existing components for code splitting will be able to show loading states for data too when Suspense for Data Fetching becomes officially supported.
其余项目

Other Projects程序员

让 React DOM 更加现代化
Modernizing React DOM
咱们开始调查 ReactDOM 的简化和现代化, 目标是减少包的尺寸而且和浏览器的行为更紧密的对齐. 由于如今该项目还处于早期探索阶段, 如今说哪些要点将要 "成功" 还为时过早. 咱们将在 这个issue(译者注: 上面的简化和现代化的 issue 连接) 上面传递咱们的进展.
We started an investigation into simplifying and modernizing ReactDOM, with a goal of reduced bundle size and aligning closer with the browser behavior. It is still early to say which specific bullet points will “make it” because the project is in an exploratory phase. We will communicate our progress on that issue.
服务端渲染的 Suspense
Suspense for Server Rendering
咱们开始设计一个新的服务端渲染器, 其支持 Suspense(包括在服务器上面等待异步渲染数据而不进行双重渲染), 并逐步加载和用 chunks 合成页面内容来得到最佳的用户体验.你能够在 本次演讲 中观看其早期原型的概述. 这个新的服务端渲染器将成为咱们2019年的主要焦点, 可是如今说关于它的发布计划还为时过早. 它的发展, 将一如既往的 发生在 github 上面,
We started designing a new server renderer that supports Suspense (including waiting for asynchronous data on the server without double rendering) and progressively loading and hydrating page content in chunks for best user experience. You can watch an overview of its early prototype in this talk. The new server renderer is going to be our major focus in 2019, but it’s too early to say anything about its release schedule. Its development, as always, will happen on GitHub.
仅此而已, 正如你所看到的, 这里有不少事情让咱们忙碌, 可是咱们期待在接下来的几个月取得更多进展.
And that’s about it! As you can see, there’s a lot here to keep us busy but we expect much progress in the coming months.
咱们但愿该文章能让你了解到咱们正在开展的工做, 今天你可使用什么, 以及在将来你可使用什么. 虽然在社交平台上面有不少关于新特性的讨论, 可是若是你阅读了该篇文章, 你将不会错过任何重要的东西.
We hope this post gives you an idea of what we’re working on, what you can use today, and what you can expect to use in the future. While there’s a lot of discussion about new features on social media platforms, you won’t miss anything important if you read this blog.
咱们始终乐于接受反馈, 而且但愿在 RFC repository, issue tracker, Twitter 上面听到你的声音
We’re always open to feedback, and love to hear from you in the RFC repository, the issue tracker, and on Twitter.

译者注:github

译者并不精通英语, 可是深知英语对于程序员的重要性, 因此译者在翻译的时候保留了英语原文, 但愿给你一个原滋原味的阅读体验而且能熟悉一些常见的英文.数据库

但愿有读者能够指出个人翻译错误, 感激涕零.编程

译文转载请注明出处react-native

相关文章
相关标签/搜索