Getting Started: はじめに

Installation Instructions: インストール手順

The beta has been published to NPM with the tag “next”. Regular NPM installs will continue to use the 15.6 release. To install the beta use:

β版は”next”タグがついた状態でnpmに公開されています。通常のnpmのインストールをすると、15.6がインストールされます。β版をインストールするには以下のようにします。

# Yarn
yarn add react@next react-dom@next

# Npm
npm install --save react@next react-dom@next

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 (eg <IE11), 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のためのpolufillを使った環境は以下のようになります。

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 purposes would be:

Reactはまた（テスト環境においても）requestAnimationFrameに依存しています。テスト用の簡単なshimは以下のようになります。

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

What Does React 16 Mean for You?: React 16はあなたにとって何を意味するのか？

React 16 is the first release that ships with a rewrite of the React core (previously codenamed “Fiber”). This rewrite had a few goals:

React 16はReact coreの書き換え（これまで”Fiber”というコードネームがつけられていました）を積んだ最初のリリースとなります。この書き換えにはいくつかの目的があります。

・Remove old internal abstractions that didn’t age well and hindered internal changes.
・Let us ship some of the most requested features like returning arrays from render, recovering from component errors, and readable component stack traces for every error.
・Enable us to start experimenting with asynchronous rendering of components for better perceived performance.

• 良い方向に進化できず内部の変更を妨げている古い内部抽象を取り除くこと。
• renderから配列を返すこと、コンポーネントのエラーからリカバリングすること、全てのエラーに対するコンポーネントのスタックトレースの可読化などリクエストされていた機能のいくつかを追加すること。
• より良い感覚的なパフォーマンスのためにコンポーネントの非同期レンダリングを試すことを可能にすること。

This initial React 16.0 release is mostly focused on compatibility with existing apps. It does not enable asynchronous rendering yet. We will introduce an opt-in to the async mode later during React 16.x. We don’t expect React 16.0 to make your apps significantly faster or slower, but we’d love to know if you see improvements or regressions.

この最初のReact 16.0のリリースは既存のアプリとの互換性に最も焦点を当てています。非同期レンダリングはまだ有効化されていません。後のReact 16.xのどこかで非同期モードへのオプトインを導入する予定です。React 16.0はみなさんのアプリケーションを大幅に早くも遅くもしませんが、みなさんのアプリケーションに改善または後退が見られるかとても知りたいです。

Points of Interest: 注目ポイント

・This is a complete rewrite of React but we expect it to work with your existing code. If you fixed all deprecation warnings introduced in 15.x, the 16 beta should work for you.
・Third party libraries that relied on deprecated or unsupported APIs may need updates to work correctly with this new release. Now is a good time to file issues against libraries that have problems. (And tell us if we broke something!)
・We are particularly interested in hearing about performance differences you notice between 15.x and 16.x. We don’t expect any massive changes but would love to know about improvements or regressions. Please report them here!
・The server renderer has been completely rewritten, and now offers a streaming mode (it’s currently exposed via react-dom/node-stream). Server rendering does not use markup validation anymore, and instead tries its best to attach to existing DOM, warning about inconsistencies. This server renderer code is still very new, so it is likely to have issues. Please report them.
・React Native follows a different release cycle and will update to the beta in a future release. (It’s already using an alpha release but not yet using Fiber.)

• React 16はReactの完全な書き換えとなりますが、既存のコードでも動くようになっています。15.xで導入された全ての非推奨の警告（deprecation warnings）を修正しておけば、16β版は問題なく動作します。
• 非推奨なAPIやサポートされていないAPIに依存しているサードパーティのライブラリはReact 16で正しく動作するようにアップデートする必要があるかもしれません。
• 私たちは15.xと16.x間のパフォーマンスの違いについてみなさんの声を聞くのに特に興味があります。大きな変更はしていませんが、改善されたかそれとも後退したかについてとても知りたいです。ここでそれらを報告してください。
• serverレンダラは完全に書き換えられており、すでにストリーミングモードを提供しています（現在はreact-dom/node-streamを通して公開されています）。サーバーレンダリングは、もはやmarkup validationを使用しません。その代わりに矛盾に関する警告を出すことで、既存のDOMにアタッチするようにしています。serverレンダラのコードはまだまだ新しいので、問題があるかもしれません。それらを報告してください。
• React Nativeは別のリリースサイクルに従って開発されているので、β版へのアップロードは今後のリリースにて行われます（すでにα版として使用することはできますが、まだFiberを使うことはできません）。

Breaking Changes: 破壊的変更

Error Handling: エラーハンドリング

・Previously, runtime errors used to put React into a broken state and produce cryptic errors. React 16 fixes this by introducing a special kind of components called “error boundaries”. Error boundaries can catch runtime errors in a component tree, log them, and display a fallback UI instead.
・If there is an uncaught error in a component, and there is no error boundary up in the tree, the whole component tree will be unmounted. This helps avoid very nasty bugs where the UI has been corrupted due to an error, but it means that you need to add a few error boundaries to your app to handle the errors gracefully.
・React 15 had a very limited undocumented support for error boundaries with a different method name. It used to be called unstable_handleError, but has been renamed to componentDidCatch.

• これまではランタイムエラーは、Reactをbroken stateの状態に変え、cryptic error（隠蔽されたエラー）を作るようになっていました。React 16では、”Error Boundary”と呼ばれる特別なコンポーネントを導入することでこれを修正しています。Error Boundaryはコンポーネントツリーの中のランタイムエラーをcatchし、それらのログをとり、代わりのフォールバックのUIを表示することができます。
• もしコンポーネントの中にcatchされないエラーがあり、ツリーの中にバウンドリーアップされるエラーがなかったら、全てのコンポーネントツリーはアンマウントされなくなります。このことは、エラーによってUIが破損してしまう大変厄介なバグを防ぐのに役立ちます。しかし、エラーを難なくハンドリングするためには、アプリにError Boundaryを追加する必要があるということを意味しています。
• React 15は極めて限定的でドキュメントされていない異なったメソッド名を持ったError Boundaryをサポートしていました。当時はunstable_handleErrorと呼んでいましたが、componentDidCatchと名前を変更しています。

You can learn more about the new error handling behavior here.

こちらで新しいエラーハンドリングの振る舞いについてより詳細を学べます。

Scheduling and Lifecycle: スケジューリングとライフサイクル

・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.
　　・Calling setState directly in render always causes an update. This was not previously the case. Regardless, you should not be calling setState from render.
　　・setState callback (second argument) now fires immediately after componentDidMount / componentDidUpdate instead of after all components have rendered.
・When replacing <A /> with <B />, B.componentWillMount now always happens before A.componentWillUnmount. Previously, A.componentWillUnmount could fire first in some cases.
・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.
・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. Now an explicit error will be thrown. Instead you should clean up your component trees using ReactDOM.unmountComponentAtNode. componentDidUpdate lifecycle no longer receives prevContext param. (See #8631)

• setState:
  • nullを伴うsetStateの呼び出しはもはや更新のトリガーとなりません。再レンダリングしたい場合は、updater functionで決めることができます。
  • render内で直接setStateを呼び出すと、常に更新を引き起こします。これまでは、そうではありませんでした。それでも、renderからsetStateを呼び出すべきではありません。
  • setStateのcallback関数（第二引数）は、全てのコンポーネントがレンダリングされた後ではなく、componentDidMount / componentDidUpdateの後に直ちに発火します。
• <A />を<B />に置き換える時、B.componentWillMountは、常にA.componentWillUnmountの前に発動します。以前は、A.componentWillUnmountはいくつかのケースによっては最初に発火することがありました。
• 以前は、コンポーネントへのref（参照）を変更すると、そのコンポーネントのrenderが呼び出される前に常にrefを切り離していました。今回のバージョンでは、DOMに変更を適用する際は、refを後に変更します。
• React以外のものによって修正されたコンテナーとして再レンダリングすることは安全ではありません。以前は一部のケースでは動作しましたが、サポートはされていませんでした。現在のバージョンでは明示的なエラーが投げられます。その代わりに、ReactDOM.unmountComponentAtNodeを使うことで、コンポーネントツリーをクリーンアップするべきです。
• componentDidUpdateはもうprevContextパラメータを受け取りません。(See #8631)

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 this issue, and we’ll try to figure out a migration strategy for you.
・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.
・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/lib/*やreact-dom/lib/*はもうありません。CommonJS環境においても、ReactとReactDOMは単一ファイル（”flat bundles”）としてプリコンパイルされています。もしあなたが以前から文書化されていないReactの内部に依存しており、もはや動作しなくなってしまったとしたら、この問題における特殊なケースについてお知らせください。あなたのためにマイグレーションの方法を明らかにするように努めます。
• react-with-addons.jsビルドはもうありません。全ての互換性のあるアドオンは切り離されてnpmに公開されており、必要であれば単一ファイルとなっているブラウザバージョンもあります。
• 単一ファイルとなっているブラウザビルドのディベロップビルドとプロダクションビルドの違いをわかりやくするように、例えば以下のようにファイル名とファイルへのパスを変更しています。
  • 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

Addons: アドオン

react-addons-perf will not work in React 16. We may provide similar functionality at some point during 16.x release cycle but it’s not settled yet. You can use Chrome Performance tab for profiling components, and Performance Observer API for aggregating this data programmatically. See this proof of concept.

react-addons-perfはReact 16では動きません。16.xのリリースサイクルのどこかで似たような機能を提供する予定ですが、まだ未定です。コンポーネントのプロファイリングのためにChromeのPerformanceタブや、プログラム上でパフォーマンスのデータを集計するためにPerformance Observer APIを使うことができます。この概念実証（proof of concept）を見てください。

Known Issues: 既知の問題

・The server renderer crashes in production with inline styles. (#10299, fixed by #10300)
　　・Fixed in 16.0.0-beta.2
・The server renderer doesn’t yet support returning arrays and strings from components (PR in #10221, needs review).
・The server renderer still renders data-reactid somewhat unnecessarily. (#10306)
・Shallow renderer doesn’t implement unstable_batchedUpdates. (TBD)
・Some popular third party libraries won’t work yet (e.g. Enzyme).
・There is a report that Google crawler can’t render the page using 16 (link).
・In some cases Error: null is reported instead of the real error. (reactjs/react-redux#756 (comment))
・(Please report more issues in this thread.)

• serverレンダラは、プロダクションにインライン・スタイルが使われているとクラッシュします。(#10299, #10300によってfixされました)
  • 16.0.0-beta.2でfixされます
• serverレンダラはまだコンポーネントから配列や文字列を返すことをサポートしていません（＃10221内のPR、レビューが必要です）。
• serverレンダラは依然としてdata-reactidをいくらか不必要にレンダリングします。(#10306)
• shallowレンダラはunstable_batchedUpdatesを実装していません（現在は未決定だが、将来決定する予定）。
• 有名なサードパーティのライブラリ（例えばEnzyme）がまだ動きません。
• GoogleのクローラーがReact 16を使用しているページをレンダリングできないという報告があります。（link）
• 一部のケースにて本当のエラーの代わりにError: nullが報告されます。（reactjs/react-redux#756 (comment)）
• （他に問題がありましたら、こちらのスレッドにご報告ください。）

Updates: アップデート

Published the initial beta to NPM on 2017-07-24.

最初のβ版は2017年7月24日にnpmへ公開されました。

まとめ

React 16は、Reactの内部実装が書き換えられる大きな変更が実施されます。しかし、上記でも述べられているように、Reactでの実装方法が大きく変わるということはなく、基本的にこれまで通り普通に使うことができるようになっています。若干の破壊的変更が含まれているので、そこは押さえておくと良いでしょう。特にエラーハンドリングに関しては、Reactの公式ブログでも取り上げられているので、合わせてチェックしておくと良いでしょう。

• Error Handling in React 16 – React Blog
• React 16で導入されたError Boundaryについて – dackdive's blog

React 16のリリースはまだはっきりとはわかっていませんが、近いうちにリリースされるはずです。リリースが今から楽しみです。当記事などを参考に、リリースに備えてもらえればと思います。