React v16.0

September 26, 2017 by Andrew Clark

We’re excited to announce the release of React v16.0! Among the changes are some long-standing feature requests, including fragments, error boundaries, portals, support for custom DOM attributes, improved server-side rendering, and reduced file size.

React v16.0のリリースのアナウンスに興奮しています。今回の変更には、fragments、Error Boundaries、Portals、カスタムDOM属性の対応、改良したサーバーサイドレンダリング、ファイルサイズの縮小など長い間要望されていた機能が含まれています。

New render return types: fragments and strings – 新しいrenderはfragmentsやstringなどの型を返します

You can now return an array of elements from a component’s render method. Like with other arrays, you’ll need to add a key to each element to avoid the key warning:

コンポーネントのrenderメソッドから要素の配列を返すことができるようになりました。これまでの配列と同じように、keyの警告を避けるためにそれぞれの要素にkeyをつけてください。　

render() {
  // No need to wrap list items in an extra element!
  return [
    // Don't forget the keys :)
    <li key="A">First item</li>,
    <li key="B">Second item</li>,
    <li key="C">Third item</li>,
  ];
}

In the future, we’ll likely add a special fragment syntax to JSX that doesn’t require keys.

将来的には、keyを必要としない特別な構文をJSXに追加したいです。

We’ve added support for returning strings, too:

さらに、文字列を返すこともできるようになりました。　

render() {
  return 'Look ma, no spans!';
}

See the full list of supported return types.

返すことのできる型の一覧を見る

Better error handling – エラーハンドリングの改善

Previously, runtime errors during rendering could put React in a broken state, producing cryptic error messages and requiring a page refresh to recover. To address this problem, React 16 uses a more resilient error-handling strategy. By default, if an error is thrown inside a component’s render or lifecycle methods, the whole component tree is unmounted from the root. This prevents the display of corrupted data. However, it’s probably not the ideal user experience.

これまでは、レンダリング中のランタイムエラーが発生すると、Reactは壊れた状態になり、cryptic error（隠蔽されたエラー）メッセージが作られ、復旧するためにページを更新する必要がありました。この問題に対処するために、React 16では、強力なエラーハンドリング戦略を用いています。デフォルトでは、エラーがコンポーネントのrenderやライフサイクルメソッドの中にthrowされた場合、ルートからコンポーネントツリーの全体がアンマウントされます。これは破損したデータが表示されるのを防ぎます。しかし、これは理想的なユーザー体験ではないでしょう。

Instead of unmounting the whole app every time there’s an error, you can use error boundaries. Error boundaries are special components that capture errors inside their subtree and display a fallback UI in its place. Think of error boundaries like try-catch statements, but for React components.

エラーが発生するたびにアプリ全体をアンマウントする代わりに、Error Boundariesを使うことができるようになりました。Error Boundariesは、エラーをサブツリーの中でキャプチャし、その代わりにフォールバックのUIを表示する特別なコンポーネントです。Error Boundariesはtry-catch構文のように考えられますが、れっきとしたReactのコンポーネントです。

For more details, check out our previous post on error handling in React 16.

より詳細については、以前の投稿である「Error Handling in React 16」をチェックしてください。

Portals

Portals provide a first-class way to render children into a DOM node that exists outside the DOM hierarchy of the parent component.

portalsは、子（children）を親コンポーネントのDOM階層以外のDOMノードにレンダリングする素晴らしい方法を提供します。

render() {
  // React does *not* create a new div. It renders the children into `domNode`.
  // `domNode` is any valid DOM node, regardless of its location in the DOM.
  return ReactDOM.createPortal(
    this.props.children,
    domNode,
  );
}

See a full example in the documentation for portals.

portalsのドキュメントで完全な事例を確認してみましょう。

Better server-side rendering – サーバーサイドレンダリングの改善

React 16 includes a completely rewritten server renderer. It’s really fast. It supports streaming, so you can start sending bytes to the client faster. And thanks to a new packaging strategy that compiles away process.env checks (Believe it or not, reading process.env in Node is really slow!), you no longer need to bundle React to get good server-rendering performance.

React 16では、サーバーレンダラが完全に書き換えられています。これは本当に速いです。ストリーミングをサポートすることで、クライアントへのデータの送信をより早く開始することが可能となっています。そして、process.envをチェックせずにコンパイルする新しいパッケージングの戦略のおかげで（信じないかもしれませんが、Node上でprocess.envを読むのは本当に遅いです）、もうサーバーレンダリングの良いパフォーマンスを得るためにReactをバンドルする必要がなくなりました。

Core team member Sasha Aickin wrote a great article describing React 16’s SSR improvements. According to Sasha’s synthetic benchmarks, server rendering in React 16 is roughly three times faster than React 15. “When comparing against React 15 with process.env compiled out, there’s about a 2.4x improvement in Node 4, about a 3x performance improvement in Node 6, and a full 3.8x improvement in the new Node 8.4 release. And if you compare against React 15 without compilation, React 16 has a full order of magnitude gain in SSR in the latest version of Node!” (As Sasha points out, please be aware that these numbers are based on synthetic benchmarks and may not reflect real-world performance.)

コアチームのメンバーであるSasha Aickinは、React 16のSSRの改善について触れた素晴らしい記事を書きました。Sashaの合成ベンチマーク (Synthetic Benchmark）によると、React 16におけるサーバーレンダリングは、React 15のおおよそ３倍速いです。「process.envでコンパイルされたReact 15と比較すると、Node 4では約2.4倍、Node 6では約3.8倍、そして最新のNode 8.4ではちょうど3.8倍のパフォーマンス改善が見られました。コンパイルしていないReact 15と比べたら、Nodeの最新バージョンでのSSRにおいてReact 16の受ける恩恵は計り知れません！」（Sashaが指摘しているように、これらの数値は合成ベンチマークに基づいたものであり、実際のパフォーマンスを反映していないかもしれないことに注意してください。）

In addition, React 16 is better at hydrating server-rendered HTML once it reaches the client. It no longer requires the initial render to exactly match the result from the server. Instead, it will attempt to reuse as much of the existing DOM as possible. No more checksums! In general, we don’t recommend that you render different content on the client versus the server, but it can be useful in some cases (e.g. timestamps).

さらに、React 16はクライアントに到達したサーバーレンダリングされたHTMLのハイドレーションを上手くやります。もうサーバーからの結果と完全に一致するように初期レンダリングを行う必要はありません。代わりに、React 16は既存のDOMを最大限に再利用することを試みます。チェックサムは必要ありません！一般的に、クライアント側とサーバー側で異なったコンテンツをレンダリングすることはおすすめしませんが、あるケース（例えば、タイムスタンプなど）では役に立つ場合もあります。

See the documentation for ReactDOMServer for more details.

より詳細はReactDOMServerのドキュメントでご確認ください。

Support for custom DOM attributes – カスタムDOM属性の対応

Instead of ignoring unrecognized HTML and SVG attributes, React will now pass them through to the DOM. This has the added benefit of allowing us to get rid of most of React’s attribute whitelist, resulting in reduced file sizes.

React 16は認識できないHTMLやSVGの属性を無視する代わりに、それらをそのままDOMに渡すようになりました。これによって属性のホワイトリストの大部分を取り除くということができ、結果としてファイルサイズを減らすことに繋がりました。

Reduced file size – ファイルサイズの縮小

Despite all these additions, React 16 is actually smaller compared to 15.6.1!

React 16は上記の通りこれだけ追加されたにも関わらず、実際に15.6.1と比べると容量が小さくなっています。

・react is 5.3 kb (2.2 kb gzipped), down from 20.7 kb (6.9 kb gzipped).
・react-dom is 103.7 kb (32.6 kb gzipped), down from 141 kb (42.9 kb gzipped).
・react + react-dom is 109 kb (34.8 kb gzipped), down from 161.7 kb (49.8 kb gzipped).

• reactは20.7kb（gzipで6.9kb）から5.3kb（gzipで2.2kb）になりました。
• react-domは141kb（gzipで42.9kb）から103.7kb（gzipで32.6kb）になりました。
• react + react-domで161.7kb（gzipで49.8kb）から109kb（gzipで34.8kb）になりました。

That amounts to a combined 32% size decrease compared to the previous version (30% post-gzip).

これは、以前のバージョンと比べると、32％もサイズが縮小されたことになります（gzip後は30％）。

The size difference is partly attributable to a change in packaging. React now uses Rollup to create flat bundles for each of its different target formats, resulting in both size and runtime performance wins. The flat bundle format also means that React’s impact on bundle size is roughly consistent regardless of how you ship your app, whether it’s with Webpack, Browserify, the pre-built UMD bundles, or any other system.

これだけサイズが異なるのは、パッケージングの変更が部分的に関わっています。Reactは様々なターゲット形式のフラットバンドルを作るためにRollupを採用し、結果としてサイズもランタイムパフォーマンスも以前のバージョンに勝ることとなりました。さらに、フラットバンドル形式になったということは、アプリをWebpack、Browserify、ビルド済みのUMDバンドル、またはその他のシステムなどを使ってどのように出力するかに関わらず、Reactのバンドルサイズへのインパクトをほぼ一定なものにできるということを意味しています。

MIT licensed – MITライセンス

In case you missed it, React 16 is available under the MIT license. We’ve also published React 15.6.2 under MIT, for those who are unable to upgrade immediately.

こちらを見逃している人もいるかと思うので言っておきますが、React 16はMITライセンスで利用できるようになりました。またすぐにReact 16にアップグレードできない方のためにReact 15.6.2もMITライセンスで公開しました。　　

New core architecture – 新しいコアアーキテクチャ

React 16 is the first version of React built on top of a new core architecture, codenamed “Fiber.” You can read all about this project over on Facebook’s engineering blog. (Spoiler: we rewrote React!)

React 16は「Fiber」というコードネームがつけられていた新しいコアアーキテクチャの上に構築された初めてのバージョンです。Facebookのエンジニアブログを通してこのプロジェクトについての全てを読むことができます。（スポイラー: we rewrote React!）。

Fiber is responsible for most of the new features in React 16, like error boundaries and fragments. Over the next few releases, you can expect more new features as we begin to unlock the full potential of React.

Error BoundariesやFragmentsなどのReact 16の新しい機能のほとんどはFiberが担っています。次の数回のリリースをかけて、Reactの完全なポテンシャルを引き出すことを始めているので、より新しい機能を期待していてください。

Perhaps the most exciting area we’re working on is async rendering—a strategy for cooperatively scheduling rendering work by periodically yielding execution to the browser. The upshot is that, with async rendering, apps are more responsive because React avoids blocking the main thread.

現在取り組んでる中でおそらく最もエキサイティングな領域は、非同期レンダリング（async rendering）です。これは、ブラウザに定期的に実行結果を与えることで、レンダリングを協調的にスケジューリングするための戦略です。結論はこうです。非同期レンダリングにより、Reactはメインスレッドのブロッキングを避けるようになり、アプリのレスポンスが向上します。

This demo provides an early peek at the types of problems async rendering can solve:

このデモでは、非同期レンダリングが解決できる問題がどう言ったものか垣間見ることができます。

We think async rendering is a big deal, and represents the future of React. To make migration to v16.0 as smooth as possible, we’re not enabling any async features yet, but we’re excited to start rolling them out in the coming months. Stay tuned!

非同期レンダリングは大きな計画であり、Reactの将来を象徴するものだと考えています。できるだけスムーズにv16.0に移行するために、非同期の機能はまだ有効にしていませんが、今後数ヶ月でそれらを公開し始めていくことに興奮しています。期待していてください。

Installation – インストール

React v16.0.0 is available on the npm registry.

React v16.0.0はnpmレジストリで利用可能です。

To install React 16 with Yarn, run:

YarnでReact 16をインストールする場合

To install React 16 with npm, run:

npmでReact 16をインストールする場合

We also provide UMD builds of React via a CDN:

CDN経由のReactのUMDビルド版も提供しています。

<script crossorigin src="https://unpkg.com/react@16/umd/react.production.min.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@16/umd/react-dom.production.min.js"></script>

Refer to the documentation for detailed installation instructions.

ドキュメントでインストール手順についての詳細をご参照ください。

Upgrading – アップグレード

Although React 16 includes significant internal changes, in terms of upgrading, you can think of this like any other major React release. We’ve been serving React 16 to Facebook and Messenger.com users since earlier this year, and we released several beta and release candidate versions to flush out additional issues. With minor exceptions, if your app runs in 15.6 without any warnings, it should work in 16.

React 16は重要な内部的な変更を含んでいますが、アップグレードに関しては、これまでのReactのメジャーリリースと同じものと考えてよいです。React 16は今年の初めからFacebookやMessenger.comのユーザーに提供してきており、そして新たな問題を洗い出すためにいくつかのベータ版とRC版をリリースしました。マイナーな例外はあるかもしれませんが、現在のアプリが15.6で警告が出ないようであれば、16でも動くはずです。

New deprecations – 新たな非推奨

Hydrating a server-rendered container now has an explicit API. If you’re reviving server-rendered HTML, use ReactDOM.hydrate instead of ReactDOM.render. Keep using ReactDOM.render if you’re just doing client-side rendering.

サーバーレンダリングされたコンテナをハイドレーションするために明示的なAPIが追加されました。サーバーレンダリングされたHTMLをクライアント側で再利用している場合は、ReactDOM.renderの代わりにReactDOM.hydrateを使用してください。クライアントサイドでレンダリングを行なっている場合は、ReactDOM.renderを使い続けてください。

React Addons

As previously announced, we’ve discontinued support for React Addons. We expect the latest version of each addon (except react-addons-perf; see below) to work for the foreseeable future, but we won’t publish additional updates.

これまでアナウンスしてきたように、Reactアドオンのサポートを中止してきました。各アドオンの最新バージョンであればまだしばらくは使用できると思いますが（react-addons-perfは除きます。以下を参照）、今後アドオンのアップデートを行う予定はありません。

Refer to the previous announcement for suggestions on how to migrate.

移行方法についての提案はこれまでのアナウンスを見てください。

react-addons-perf no longer works at all in React 16. It’s likely that we’ll release a new version of this tool in the future. In the meantime, you can use your browser’s performance tools to profile React components.

react-addons-perfはもうReact 16では動きません。今後、このツールの新しいバージョンをリリースできればと考えています。それまでの間は、ブラウザのパフォーマンスツールを使ってReactのコンポーネントのプロファイルを行なってください。

Breaking changes – 破壊的変更

React 16 includes a number of small breaking changes. These only affect uncommon use cases and we don’t expect them to break most apps.

React 16はちょっとした破壊的変更をいくつか含んでいます。これらは珍しいユースケースにしか影響を及ぼさず、ほとんどのアプリには影響ないと思われます。

• React 15 had limited, undocumented support for error boundaries using unstable_handleError. This method has been renamed to componentDidCatch. You can use a codemod to automatically migrate to the new API.

  React 15は限定されたドキュメントされていないunstable_handleErrorを使ったError Boundariesをサポートしていました。このメソッドはcomponentDidCatchに名前が変更されました。自動的に新しいAPIに移行するにはcodemodを使います。

• ReactDOM.render and ReactDOM.unstable_renderIntoContainer now return null if called from inside a lifecycle method. To work around this, you can use portals or refs.

  ReactDOM.renderとReactDOM.unstable_renderIntoContainerは、ライフサイクルメソッドの内部で呼ばれた場合、nullを返すようになりました。portalsまたはrefsを使用すると、これを回避できます。

• setState:

  • Calling setState with null no longer triggers an update. This allows you to decide in an updater function if you want to re-render.

    nullを指定してsetStateを呼び出せば、更新がトリガーされなくなりました。これにより再レンダリングしたい場合、アップデータ関数内で決定することができます。

  • Calling setState directly in render always causes an update. This was not previously the case. Regardless, you should not be calling setState from render.

    render内で直接setStateを呼び出した場合、常に更新が行われるようになりました。以前は更新が行われない場合がありました。だからと言って、renderからsetStateを呼び出すべきではありません。

  • setState callbacks (second argument) now fire immediately after componentDidMount / componentDidUpdate instead of after all components have rendered.

    setStateの第二引数に渡したコールバックは、全てのコンポーネントがレンダリングされてからではなく、componentDidMount / componentDidUpdateの後直ちに発火するようになりました。　

• When replacing <A /> with <B />, B.componentWillMount now always happens before A.componentWillUnmount. Previously, A.componentWillUnmount could fire first in some cases.

  <A />を<B />に置き換える時は、B.componentWillMountが常にA.componentWillUnmountの前に発火するようになりました。以前は、場合によってはA.componentWillUnmountが先に発火しました。

• Previously, changing the ref to a component would always detach the ref before that component’s render is called. Now, we change the ref later, when applying the changes to the DOM.

  以前は、refをコンポーネントに変更する際、refの切り離し（デタッチ）は常にコンポーネントのrenderが呼び出される前に行われていました。React 16では、DOMに変更が適用される際は、refの切り離しが後になりました。

• It is not safe to re-render into a container that was modified by something other than React. This worked previously in some cases but was never supported. We now emit a warning in this case. Instead you should clean up your component trees using ReactDOM.unmountComponentAtNode. See this example.

  React以外のものによって変更されたコンテナに再レンダリングすることは安全ではありません。以前はサポートしていたわけではありませんが、いくつかのケースで機能しました。React 16ではこの場合警告が出るようになりました。これを回避するには、ReactDOM.unmountComponentAtNodeを使用してコンポーネントツリーをクリーンアップしてください。この例を見てください。

• componentDidUpdate lifecycle no longer receives prevContext param. (See #8631)

  componentDidUpdateライフサイクルメソッドは引数としてpreContextを受け取らなくなりました（#8631を見てください）。

• Shallow renderer no longer calls componentDidUpdate because DOM refs are not available. This also makes it consistent with componentDidMount (which does not get called in previous versions either).

  DOMのrefsが利用できなくなったため、Shallow rendererはcomponentDidUpdateを呼び出さなくなりました。　これにより（以前のバージョンでも呼び出さなかった）componentDidMountと一貫性を持つようになりました。

• Shallow renderer does not implement unstable_batchedUpdates anymore.

  Shallow renderはもうunstable_batchedUpdatesを実装していません。

Packaging – パッケージング

• There is no react/lib/* and react-dom/lib/* anymore. Even in CommonJS environments, React and ReactDOM are precompiled to single files (“flat bundles”). If you previously relied on undocumented React internals, and they don’t work anymore, let us know about your specific case in a new issue, and we’ll try to figure out a migration strategy for you.

  react/lib/*とreact-dom/lib/*はなくなりました。CommonJS環境でも、ReactとReactDOMは一つのファイル（フラットバンドル）にプリコンパイルされます。これまで文書化されていないReactの内部に依存していて、それが動かなくなった場合は、移行戦略を見つけるようにしますので、新しい問題における特定のケースについてお知らせください。　

• There is no react-with-addons.js build anymore. All compatible addons are published separately on npm, and have single-file browser versions if you need them.

  react-with-addons.jsはなくなりました。全ての互換性のあるアドオンはnpmで公開されていますし、シングルファイルのブラウザバージョンも持ち合わせています。

• The deprecations introduced in 15.x have been removed from the core package. React.createClass is now available as create-react-class, React.PropTypes as prop-types, React.DOM as react-dom-factories, react-addons-test-utils as react-dom/test-utils, and shallow renderer as react-test-renderer/shallow. See 15.5.0 and 15.6.0 blog posts for instructions on migrating code and automated codemods.

  15.xで紹介された廃止予定だったものがコアパッケージから削除されました。React.createClassはcreate-react-classとして、React.PropTypesはprop-typesとして、React.DOMはreact-dom-factoriesとして、react-addons-test-utilsはreact-dom/test-utilsとして、shallow rendererはreact-test-renderer/shallowとして利用できます。コードや自動化されたcodemodsの移行方法については15.5.0や15.6.0のブログ投稿を見てください。

• The names and paths to the single-file browser builds have changed to emphasize the difference between development and production builds. For example:
  ・react/dist/react.js → react/umd/react.development.js
  ・react/dist/react.min.js → react/umd/react.production.min.js
  ・react-dom/dist/react-dom.js → react-dom/umd/react-dom.development.js
  ・react-dom/dist/react-dom.min.js → react-dom/umd/react-dom.production.min.js

  シングルファイルのブラウザビルド版のファイル名とパスは、開発ビルド版とプロダクションビルド版の違いを強調するために例えば以下のように変更されました。

  • react/dist/react.js → react/umd/react.development.js
  • react/dist/react.min.js → react/umd/react.production.min.js
  • react-dom/dist/react-dom.js → react-dom/umd/react-dom.development.js
  • react-dom/dist/react-dom.min.js → react-dom/umd/react-dom.production.min.js

JavaScript Environment Requirements – JavaScript環境要件

React 16 depends on the collection types Map and Set. If you support older browsers and devices which may not yet provide these natively (e.g. IE < 11), consider including a global polyfill in your bundled application, such as core-js or babel-polyfill.

React 16はMapとSetのコレクション型に依存しています。これらにまだ対応していない古いブラウザやデバイス（例えばIE11以下など）をサポートする場合は、core-jsまたはbabel-polyfillのようなグローバルなpolyfillをバンドルされたアプリケーションに含めるようにしてください。

A polyfilled environment for React 16 using core-js to support older browsers might look like:

古いブラウザをサポートするためにcore-jsを使ったReact 16のpolyfill環境は以下のようになります。

import 'core-js/es6/map';
import 'core-js/es6/set';

import React from 'react';
import ReactDOM from 'react-dom';

ReactDOM.render(
  <h1>Hello, world!</h1>,
  document.getElementById('root')
);

React also depends on requestAnimationFrame (even in test environments). A simple shim for test environments would be:

ReactはまたrequestAnimationFrameに依存しています（テスト環境においても）。テスト環境のためのシンプルなshimは以下のようになります。

global.requestAnimationFrame = function(callback) {
  setTimeout(callback, 0);
};

Acknowledgments – 謝辞

As always, this release would not have been possible without our open source contributors. Thanks to everyone who filed bugs, opened PRs, responded to issues, wrote documentation, and more!

いつものように、今回のリリースはオープンソースのコントリビューターなしでは可能ではありませんでした。バグを報告し、プルリクエストを開き、問題に対応し、ドキュメントを書いてくれた全ての方に感謝します。

Special thanks to our core contributors, especially for their heroic efforts over the past few weeks during the prerelease cycle: Brandon Dail, Jason Quense, Nathan Hunzaker, and Sasha Aickin.

特にプレリリースサイクル期間の過去数週間に渡ってヒーロー的な貢献をしてくれたコアコントリビューター: Brandon Dail、Jason Quense、Nathan Hunzaker、Sasha Aickinに特別な感謝をします。

まとめ

リリースノートの中にも書いてありましたが、今回のReact v16からJest、Flow、Immutable.js、GraphQLなどと共にMITライセンスの下で利用できるようになりました。これまでのBSDライセンスは何かと物議を醸していたので、これまでライセンスが原因でReactを敬遠していた方がReactの方を向いてくれるきっかけになってくると良いですね。この流れに乗ってなのか、Reactの公式サイトも独自ドメイン（reactjs.org）で運用されるようになりました。

• React – A JavaScript library for building user interfaces

React v16は、コアアーキテクチャーが完全に書き換えられましたが、これまでと同様に使えるということなので、安心ですね。ただし、いくつか変更点もあるので、そこはしっかりと確認してください。ちなみに、koba04さんのブログ記事が事例付きで大変わかりやすいです。当記事と併せて確認されるとReact　v16についての理解も深まるかと思います。

• React v16 changes – blog.koba04.com

1年半ぶりのメジャーバージョンアップをぜひ十分にご堪能ください！