React 16 Roadmap

一.概観

機能面から見ると、React 16 の計画には 4 つの重要な特性があります：

• Concurrent Mode

• Hooks

• Suspense

  • for Code Splitting

  • for Data Fetching

  • for SSR

• Modernizing React DOM

その中で、Concurrent Mode（以前は Async Rendering と呼ばれていました）は間違いなく最も期待されるもので、変革をリードする可能性があります（協調スケジューリングメカニズムはブラウザ機能として一般化する可能性があります）

形式だけを見ると、Hooks は関数型コンポーネントの強化であり、クラスコンポーネントと対等に、さらには（期待としては）取って代わることを可能にします。実質的な意義は、さらに多くの関数型思想をフロントエンド領域に導入すること です。例えば Effect、Monad など。v = f(d) という UI 層の関数型思路を提案した後の、この道におけるさらなる探求と言えます

Suspense は Code Splitting シナリオですでに姿を現しており、主な貢献はユーザー体験と開発体験にあります。Data Fetching のシナリオも同様で、開発体験（データリクエストおよびキャッシュ方式の統一）を向上させると同時に、ユーザー体験（Loading の表示）も考慮します。一方、SSR シナリオにおける Suspense 能力は前 2 つとは異なり、ページ読み込みパフォーマンスとユーザー体験のバランスをより多く考慮し、サーバーサイドレンダリングとクライアントサイドレンダリングの連携（Hydration）を通じて、ページをできるだけ早く実際に使用可能な状態にすることを期待しています

Modernizing React DOM は React DOM（6 年）の技術的負債に対するリファクタリング計画で、コードネームは React Fire です。実装を簡素化し、現代のブラウザ DOM メカニズムに合わせることを目的としています。例えば、イベントシステムという不要な抽象化レイヤーを削除します。現代のブラウザ環境では、これらの 2013 年の polyfill はもはや必要ないからです

二.Concurrent Mode

Concurrent Mode は非ブロッキングレンダリングを意味します：

Concurrent Mode lets React apps be more responsive by rendering component trees without blocking the main thread.

P.S.Concurrent Mode は以前 async mode と呼ばれていました。名前を変更したのは、他の非同期レンダリング技術との違いを際立たせるためで、優先度スケジューリングの概念があり、タイムシェアリングオペレーティングシステムが複数のプログラムを並行実行する能力に類似 しています

計算集約（CPU-bound）型タスクにとって、Concurrent Mode がもたらす非ブロッキングレンダリング能力は、大きなコンポーネントツリーをレンダリングする同時に、アプリケーションのインタラクション応答能力を保証します（フリーズしない）。これはReact のビジョンにおいて非常に大きな部分です

具体的には、Concurrent Mode では時間のかかるレンダリングフローを中断でき、メインスレッドがより優先度の高い処理を行う機会を提供します：

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).

また、Suspense と連携して不要な Loading 状態をスキップできます（ネットワークが十分に速い場合、Loading をちらつかせる必要がなくなります）：

Concurrent Mode also improves the user experience of Suspense by skipping unnecessary loading states on fast connections.

さらに、Concurrent Mode 特性が依存する 協調スケジューリングメカニズム は、将来ブラウザがネイティブ実装を提供する可能性があります（すでに Chrome チームと協力 しています）

P.S.スケジューラの詳細情報については、cooperative scheduling を参照

リリースバージョン

React & React DOM 16.x（未リリース）

公式資料

• Andrew's talk

• JSConf Iceland talk

三.Hooks

Hooks は関数型コンポーネントにも状態、ライフサイクルなどのクラスコンポーネント特性（state、lifecycle、context、ref など）を持たせることができます：

Hooks let you use features like state and lifecycle from function components.

さらに、コンポーネントツリー構造のネスト関係に強く結合することなく、コンポーネント間で状態ロジックを再利用する能力も提供します：

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>
  );
}

これが関数型コンポーネントの「状態」であり、context、ref、コンポーネントインスタンス変数なども同���の Hook 方式でサポートが提供されているため、関数型コンポーネントはクラスコンポーネントとほぼ同等の表現力を獲得しました

さらに、Hooks は大きな期待を寄せられており、React コンポーネントの基本的な形式（クラスコンポーネントの代替オプション）になることが期待 されています：

In the longer term, we expect Hooks to be the primary way people write React components. Our goal is for Hooks to cover all use cases for classes as soon as possible.

しかし、関数型コンポーネントを大幅に強化するのは、単にもう一つのオプションを増やすためだけでなく、主な作用は以下の通りです：

• コンポーネントツリーのネストレベルを削減

• ライフサイクルロジックの再利用（関数型コンポーネント + Hooks で、クラスコンポーネントのクラス（コンポーネント）インスタンスレベルで再利用できない部分を抽出）

収益は 2 方面に現れます：

• 開発体験

  • コンポーネントネストの wrapper hell 問題を解決（"wrapper hell" of render props and higher-order components）

  • ライフサイクル中の重複ロジックを再利用

• 基礎建設

  • 大規模最適化の障壁を解決（例えばインラインコンポーネントのコンパイルの難題）

P.S.注意、Hooks の提案は Class を廃止するためではありません が、Hooks が広く適用された後、Class サポートを別個の package に分割して、bundle 体积を削減する可能性があります：

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 & React DOM v16.8.0

公式資料

• introduction

• overview

• [motivation](https://medium.com/ @dan_abramov/making-sense-of-react-hooks-fdbde8803889)

• API design

• talks

• Hooks in React Native

• FAQ

四.Suspense

Suspense はUI が他のものを待って一時停止することで、基本的なメカニズムはレンダリングを一時停止し、フォールバック効果を表示することです（suspending rendering and showing a fallback）：

Suspense refers to React's new ability to "suspend" rendering while components are waiting for something, and display a loading indicator.

2 つの目標：

• Code Splitting、Data Fetching などのシナリオに便利なプログラミングモデルを提供

• 並行モードでのユーザー体験を促進

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.

Suspense for Code Splitting

React.lazy でコンポーネントを遅延ロードし、これによりコンポーネント（ツリー）粒度のコード拆分を実現します。例えば：

// This component is loaded dynamically
const OtherComponent = React.lazy(() => import('./OtherComponent'));

function MyComponent() {
  return (
    <React.Suspense fallback={<Spinner />}>
      <div>
        <OtherComponent />
      </div>
    </React.Suspense>
  );
}

P.S.React コード拆分の詳細情報については、React Suspense を参照

リリースバージョン

React & React DOM v16.6.0

公式資料

• Code Splitting guide

• [practical explanation](https://medium.com/ @pomber/lazy-loading-and-preloading-components-in-react-16-6-804de091c82d)

Suspense for Data Fetching

Code Splitting と同様に、データリクエストのシナリオにも便利な通用方案を提供することを希望しています：

We'd like to provide officially supported ways to use it for data fetching too.

例えば UI がデータが戻るのを待ち、その間に React.Suspense で Loading を表示：

// 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>
  );
}

最終的なビジョンは、ネットワークライブラリが上層カプセル化を提供し、大多数のデータリクエストが Suspense を通じるようにすることです

react-cache

react-cache は Suspense for Data Fetching の设想に実験的な実装を提供しています

現在非常に不安定な段階にあり（キャッシュ期限切れなどの基礎特性さえ欠いています）、一時的な使用は推奨されません。主な理由は以下の通り：

• 依存する一部の底層 API がまだ ready ではない（Context.write を参照）ため、API を最終確定できない

• 一部の UI パターンサポートが欠如（例えばコンポーネントツリー階層に無関係な Loading）

しかし、最終的には一套の規範を形成し、他のネットワークライブラリ（Apollo など）は規範説明に従うだけで Suspense サポートに接入できます：

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 & React DOM 16.x（未リリース）

公式資料

• talk

• small demo

• React Cache

Suspense for Server Rendering

Suspense も SSR と連携でき、前後端合璧でページ読み込み体験を向上 できます

具体的には、漸進的にロードし、ページコンテンツをブロックごとにレンダリングし、同時に Suspense 特性と連携してロード中の視覚体験を向上：

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.

P.S.その中で double rendering は前後端レンダリング結果が一致しない場合（例えばフロントエンドレンダリングがデータリクエスト��依存）、状態の一致を保証するために、バックエンドレンダリング結果を破棄し、フロントエンドで再度該コンポーネントをレンダリングする必要があることを指します。詳細は Hydration を参照

現在関連メッセージは少ないですが、SSR 大幅リファクタリングは 2019 年の重点目標であることは確定しています：

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.

リリースバージョン

不確定

公式資料

• talk

五.Modernizing React DOM

React Fire と呼ばれる計画で、実装を簡素化（Simplifying）し、現代のブラウザ DOM に合わせる（Modernizing）ことを希望しています

現在まだ探索段階にあり、具体的な計画および進捗は React Fire: Modernizing React DOM を参照

リリースバージョン

不確定

公式資料

• React Fire: Modernizing React DOM

参考資料

• React 16.x Roadmap

• Tips for server-side rendering with React