React 16

1.機能
フラグメント
テンプレートは、ReactElement配列および文字列に対応するフラグメントおよび文字列タイプをサポートします

v16.2.0は、JSXフラグメントのサポートも提供します。<> </>

エラー境界
コンポーネントレベルのエラー処理、サブコンポーネントツリーでの内部例外のキャプチャのサポート、およびUIレイヤーのソリューション

ポータルを
使用すると、コンポーネントツリーをDOMツリー構造と矛盾させることができ、ホバーカードやツールチップなどのシナリオで使用されます。

たとえば、tooltipのDOM構造では、targetとtipは一般に兄弟（レイアウトに必要）ですが、論理的にはtipは親子関係であるtargetに属します。ポータルは、このシナリオを処理するために使用されます。

特に、イベントバブリングが処理された後も、ポータルコンポーネントの親コンポーネントはバブリング通知を受信できます（React 16より前は、DOMイベントバブリングの違いをスムーズにするイベントシステムが組み込まれていました。ちなみに、バブリングバブリングの例はサポートされています）。

カスタムDOM属性のサポートには、
HTML / SVG属性名の組み込みホワイトリストがあり、カスタム属性はブロックされて無視されます。React16はこの制限を取り除きます。

この制限を取り除く理由は2つあります。1つは、このレイヤーの組み込みプロパティフィルタリングが、非標準（提案段階など）の新しいプロパティや他のライブラリ/フレームワーク（Angular、Polymerなど）に対応していないことです。2つ目は、バンドルで必要です。サイズが小さくない属性のホワイトリストが組み込まれているため、保守が面倒です。

改善されたサーバー側のレンダリングは
、React 15よりも3倍高速であると主張されており（ベンチマークシナリオ、ビジネスシナリオは1.3倍高速であると言われています）、いくつかのことを実行しました。

サポートストリーム

冗長なprocess.env（ノード環境でこの変数にアクセスするのは非常に時間がかかります）は、構築中に削除されました。

クライアントはチェックサムを計算しなくなりましたが、既存のDOMを可能な限り再利用します（DOMノードの再利用のためのinfernoの実装と同様ですが、infernoの再利用でいくつかの問題が発生したようで、ハイライト機能ではなくオプションとしてのみ提供されるようになりました）

注：React 16には、いくつかのDOMノードの再利用の問題があるようです。

However, it’s dangerous to have missing nodes on the server render as this might cause sibling nodes to be created with incorrect attributes.

PSどのような危険なシーンに注意を払うべきか、公式ブログは後で提供される可能性があり、当面は明確ではありません

ファイルサイズの縮小
Reactバンドルスリミング（リファクタリングされ、フラット化されたパッケージ戦略、およびロールアップに置き換えられました）、サイズが30％小さくなりました

2.
***の最大の変化は***であるはずですが、今回はそれを真剣に認識しました（前の***は地面に拾われているようです）

1.新しいAPI
サーバー側は、renderToString、renderToStaticMarkupにそれぞれ対応するrenderToNodeStream、renderToStaticNodeStreamを追加します

クライアント側にハイドレートを追加

2.緩い整合性検証
クライアント側の検証はそれほど厳密ではありません。

React 15では、クライアントは得られた***結果に対して文字レベルの整合性チェックを実行し、不一致がある場合、クライアントは結果全体を再生成して置き換えます。

React 16は、一貫性のない属性の順序を許可し、一貫性のない属性を自動的に修復せず、タグ構造全体を置き換えるのではなく、不一致のタグ構造に遭遇したときにサブツリーレベルの変更を行います

さらに、サーバーHTML構造のチェックサム（data-react-checksum）とid（data-reactid）も削除され、応答の本文のサイズが大幅に縮小されます。

<!-- react 15 -->
<div data-reactroot="" data-reactid="1"
    data-react-checksum="122239856">
  <!-- react-text: 2 -->This is some <!-- /react-text -->
  <span data-reactid="3">server-generated</span>
  <!-- react-text: 4--> <!-- /react-text -->
  <span data-reactid="5">HTML.</span>
</div>

<!-- react 16 -->
<div data-reactroot="">
  This is some <span>server-generated</span> <span>HTML.</span>
</div>

3.パフォーマンスの最適化
により、冗長なprocess.env.NODE_ENVアクセスがデフォルトで削除されます。手動でコンパイルして削除する必要はありません。

*** 1回限りの仮想DOMを作成する必要はなく、全体がはるかに高速になります

ストリームをサポートすると、次のパフォーマンス上の利点があります。

サーバーは、***が完了するのを待ってから一度に送信するのではなく、作成中に送信します。TTFB（最初のバイトまでの時間）の方が高速です。

クライアントは、応答コンテンツが完了するまで待ってから描画を開始するのではなく、接続中に描画します。解析、描画、および外部リソースの読み込みの時点はすべて進んでいます。

4.エラー境界とポータル
反応16はサポートされていません***エラー境界とポータルはサポートされていません

サービス端末コンポーネントのレンダリングは正しくなく、エラー境界によってブロックされません。パフォーマンス上の利点をストリーミングするために、エラー境界が犠牲になります。

This is intentional / a known limitation. With streaming rendering it’s impossible to “call back” markup that has already been sent, and we opted to keep renderToString and renderToNodeStream’s output identical.

renderToNodeStreamだけでなく、renderToStaticNodeStreamはError Boundaryもサポートしていません。また、renderToStringもサポートしていません。前述のように、出力結果の一貫性を保つために、維持するメカニズムの2つのセットはありません。

PS ***エラー境界の詳細については、componentDidCatchがReact16のrenderToStringで機能しないを参照してください。

ポータル機能により、エラー境界と同じ「リフロー」が発生する場合があります。ストリームメカニズムではサポートできません（もちろん、送信されたストリームにポータルコンテンツを挿入することはできません）。

3.
コンポーネントレンダリングメカニズムを完全に書き直すためのFiberの新しいコアアーキテクチャ（2年かかりました）。最も重要な機能は、スケジュール可能なレンダリングを実装する非同期レンダリングです（マウントプロセスが開始されると中断できないという問題を完全に解決します。問題）

リファクタリングプロセスは
非常に大きなものであり、リファクタリングの実行プロセスは非常に興味深いものです。一般的に言えば：

それを行うために新しいブランチを引っ張らないでください。日常のメンテナンスやコンフリクトハンドリングなどを簡素化すると言われているuseFiber機能スイッチで切り替えます。

最初のステップは、スケルトン（スケルトン）を作成することです。APIの一部をサポートしてから、すべてのテストケース（いわゆるTDD、テスト駆動型開発、そして最後に2000ケース）をゆっくりと実行します。

エンジニアリングエイド。進行状況の追跡、単一のテスト結果の追跡（1回の送信で修正されたもの、壊れているものを簡単に発見するための方法は非常に簡単です。gittrackingにtests-failing.txt、tests-passing.txtを追加）、継続的な実稼働環境の検証（いわゆるドッグフード、初期段階から最終的な単一のテストパスまでの全プロセスは継続的に「実際に検証」され、これは目に見える信念と見なすことができます）

テストベッドとして適切なビジネスを見つけてください。ほぼ安定した後、実際のビジネスで生産の準備ができていることを証明し、A / Bテストでデータを取得し、2億人のユーザーにそれを感じてもらい、それを最大限に削減します。同時に、内部システムを完全に削減し、検証シナリオを拡張します。最後に、Reactネイティブアプリケーションはグレースケールで提供されます

新しいメカニズムに直接ではありません。当分の間、同期的に実行されます（ただし、Fiberは非同期をサポートします）。移行をスムーズにするために、さらに数か月待つ準備をしてください。

特定のリファクタリングプロセスについては、React 16：フロントエンドUIライブラリのAPI互換リライトの内部を参照してください。

したがって、非同期レンダリングは一時的にサポートされていません。

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.

利点と
新機能

コンポーネントレベルのエラー処理、複数のコンポーネントへのレンダリングリターン、およびリファクタリング後に作成できる以前は実装が容易ではなかったその他の機能

アドバンテージを体験する

ファイバーは必ずしも高速ではありませんが、タスクの優先順位の制御に加えて、アニメーションやその他の優先順位の実行を可能にするため、よりスムーズになります（分割レンダリングタスクとバランススケジューリングにより、メインスレッドが長時間使用されないようにします）。

違いは非常に明白です。ReactStackとFiberを参照してください。

参考資料
Reactv16.0

React16のサーバーサイドレンダリングの新機能

ReactFiberがWebアプリとモバイルアプリをよりスムーズで応答性の高いものにする方法