Promiseをthrowするのはなぜ天才的デザインなのか

ReactのConcurrent Modeが最初に発表されたのはもう1年近くも前のことです（記事執筆時点[^note_published]）。Concurrent Modeはたいへん奥深い機能で正式版がたいへん待ち遠しいですが、Concurrent Modeの代名詞として多くのReactユーザーに知られているのは**Promiseをthrowする**というAPIデザインです。Concurrent Modeでは、コンポーネントがレンダリング時にPromiseをthrowすることで、レンダリングをサスペンドした（Promiseが解決されるまでレンダリングできない）ことを表します。

[^note_published]: 2020年9月

Concurrent Modeに関しては筆者の既存記事[Concurrent Mode時代のReact設計論 (1) Concurrent Modeにおける非同期処理](https://qiita.com/uhyo/items/4a6315bfccf387407631)などをご参照いただきたいのですが、ここではPromiseをthrowするということ自体に焦点を当てます。

Proimseをthrowするというのは斬新な行為で、多くのReactユーザーに驚きをもって迎えられました。驚きだけではなく、気持ち悪いとか分かりにくいといった反発も見られました。そこで、この記事ではPromiseをthrowするというAPIデザインがいかに天才的かを解説します。キーワードは**大域脱出**と**型**、そして**副作用**です。

## Promiseのラッパー: Loadable

いきなり核心に迫りますが、次のように定義されるPromiseのラッパーを考えてみてください。Recoilに倣ってこれを`Loadable`と呼びましょう。

```ts
type LoadableState<T> = {
    type: "pending";
    promise: Promise<T>;
} | {
    type: "fulfilled";
    result: T;
} | {
    type: "rejected";
    error: unknown;
}

class Loadable<T> {
    #state: LoadableState<T>;

    constructor(promise: Promise<T>) {
        const p = promise.then((result) => {
            this.#state = {
                type: "fulfilled",
                result,
            };
            return result;
        }, (error) => {
            this.#state = {
                type: "rejected";
                error,
            };
            throw error;
        })
        this.#state = {
            type: "pending",
            promise: p,
        };
    }

    get(): T {
        switch (this.#state.type) {
            case "pending": {
                throw this.#state.promise;
            }
            case "fulfilled": {
                return this.#state.result;
            }
            case "rejected": {
                throw this.#state.error;
            }
        }
    }
}
```

このラッパーは`new Loadable(new Promise(...))`のように、Promiseをラップする形で使います。Loadableは内部の`#state`に今Promiseがどの状態なのか（`"pending"`, `"fulfill"`, `"rejected"`のいずれか）を保持しています。`"pending"`（まだPromiseが解決していないとき）はPromiseを保持しており、`"fulfill"`（解決済）のときは解決された値を保持しており、`"rejected"`（失敗済）の時はエラーオブジェクトを保持しています。

そして、特徴的なのは`get`メソッドです。この関数は、Promiseが解決済のときのみその値を返します。Promiseが未解決の場合はPromiseをthrowします。一応、Promiseが失敗していた場合はエラーをthrowするようになっています。

## 大域脱出と返り値の型

`get`メソッドの返り値の型が`T`型であるのはとても注目に値します。LoadableはPromiseという非同期処理を取り扱うクラスのはずなのに、`get`の返り値の型からはそのことが消えています。これは、`await loadable.get()`などとせず、単に`loadable.get()`とすることで目的の値が取得できるということです。

ただし、お分かりの通り、`get`がちゃんと値を返すのはPromiseが解決済である時だけです。だからこそ、`T`型という返り値の型が実現しているわけですが。

そして、そのトリックは言うまでもなく、`T`型の値を返せない時はthrowしてしまうという`get`の実装によるものです。実際にReactアプリケーションの中でLoadableを使用した場合、throwされたものはReactが裏で面倒を見ることになります。

言い方を変えれば、Loadableは**非同期処理の扱いをReactに丸投げ**（throwだけに）**することによってインターフェースから非同期処理を隠蔽している**のです。

この「丸投げ」が可能なのは、throwが**大域脱出**（実行をその場で中断して外側に制御を移すこと）を伴う構文だからです。JavaScriptの構文の中でも関数から脱出する大域脱出が可能なのはthrowだけです。関数の外側へ大域脱出するということは、関数から返り値を返すのを放棄するということでもあります。関数から戻り値を放棄することによって、関数の返り値の型（`T`）に影響を与えずに関数の実行を中断することができます。これがthrowの力であり、このためにthrowが使われるのは必然であると言えます。


また、このような実装が可能になる裏には、以上の事情をきちんと処理・推論することができるTypeScriptの尽力があってこそです。

### 簡単な例で理解する

上記のLoadableの例はいきなり核心に迫るよい例ですが、いまいちピンとこないという方もいるかもしれません。もっと簡単な例でも大域脱出の力を見ておきましょう。

```ts
function getDataOrUndefined(): string | undefined {
 // ...
}
```

このような`getDataOrUndefined`があったとしましょう。その名の通りデータを取得する関数ですが、データが無いかもしれません。そのときは結果が`undefined`となります。

しかし、ここで「いや`undefined`とか困るから絶対に`string`を返して」というオーダーがあったとしましょう。
明らかに無理難題ですが、`throw`なら解決してくれます。そう、なかった場合の処理は外に丸投げしてしまえばいいのです。

```ts
function getData(): string {
  const maybeData = getDataOrUndefined();
  if (maybeData === undefined) {
    throw new Error("あとは任せた！！！！！！！");
  }
  // ここでは maybeData は string型
  return maybeData;
}
```

こうすれば必ず`string`を返す関数である`getData`の完成です（例外が投げられる可能性が生じましたが）。

一見ふざけているように見えますが、エラーハンドリングさえできるのであればこれもまともな設計になり得ます。むしろ、こうやって外側にエラー処理を任せてどこかにエラーハンドリングの処理をまとめる方が伝統的なエラーハンドリングの姿ではないでしょうか。

このように大域脱出は、外側でのハンドリングの必要性と引き換えに、型をシンプルにする効果を持っているのです。Reactの場合は、そのハンドリングを全部Reactがやってくれるというわけです。

## 大域脱出と副作用

この記事では、throwを用いた大域脱出によって非同期処理をインターフェースから隠蔽するというAPIデザインの妙について説明しました。
大域脱出は、関数型的な文脈では**副作用**の一つであると考えられています。

また、ReactはReact Hooksの登場以降このような複雑性の隠蔽を特徴としてきています。React Hooksにおいても、「状態を持つ」という**副作用**を、それをうまく隠蔽するフックというAPIを通じて利用できるようになっています。今回の「Promiseをthrowする」というのは、実際にthrowという副作用を隠蔽するのはReact本体ではなく（先述のLoadableのような）Suspenseに対応したステート管理ライブラリやデータフェッチングライブラリになるわけですが、いずれにせよユーザーからは隠蔽される（ユーザーからは`get(): T`のような副作用のないAPIが見える）という点は同じです。

その意味で、ReactのConcurrent Modeで導入される「Promiseをthrowする」というのは突飛な変化ではなく、むしろ**React Hooksの流れを汲んだ正統進化**であるということができるでしょう。

## まとめ

まとめると、ReactのSuspenseにおいては、**throwによる大域脱出と型推論の天才的かつ芸術的なコラボレーション**によって非同期処理からその非同期性を隠蔽することができているのです。Suspense（throwによりReactコンポーネントのレンダリングがサスペンドするやつ）は主にデータの取得のために使われることが想定されています。データとは、Loadableの`T`型に相当するものです。Loadableの`get`を使えば、返り値が`T`なのですから非同期処理であることをコンポーネントの表面から隠蔽しながらデータ取得ができるというわけです。

また、この新しい機能は副作用の隠蔽というテーマにおいてReact Hooksの流れを維持した進化形態となっています。

## 追記：コメント返し

この記事を公開してからすぐに色々な反響がありました。そこで、いくつかのコメントに反応したいと思います。コメント返しは記事の至らないところを最短距離で補える素晴らしいやり方ですが、みなさまのコメントがあってこそです。コメントをくださった皆様ありがとうございます。

ここでは反対意見ばかり取り上げていますが、お褒めの言葉もいただいています。重ねてお礼申し上げます。

- **型チェックをランタイムのチェックに変換していてむしろ型の守備範囲が狭くなってしまっているのでは？**

これはその通りですね。`throw`は本来ハンドリングすべき情報（`undefined`の可能性とか）を型から消すことができますが、逆に言えば型から消えてしまったものはランタイムの機構（try-catchとか）でうまく補ってあげる必要があります。TypeScriptの登場以降、主にこのことが理由で`throw`が敬遠されるようになってきた歴史があります。

筆者の考え方としては「ライブラリ（React）のレベルで危険性が隠蔽されていればそれでいい」と考えています。これは筆者の以前のトーク「[安全性の極北から見るTypeScript](https://speakerdeck.com/uhyo/an-quan-xing-falseji-bei-karajian-rutypescript)」などで説明した考え方ですが、よいインターフェースのためにさまざまな単位（文、関数、モジュール、そしてライブラリ単位）で危険性を受け入れ、隠蔽するのも価値があることです。

- **Promiseをthrowする理由が分からなかった。**
- **Promiseをthrowするメリットを説明していない。**

はい、この記事ではPromiseの部分は触れずに説明しました。どちらかというとthrowの部分が本質的に重要だからです。

Promiseを投げるのは、それをキャッチしたReactに「このコンポーネントはいつレンダリングの準備ができるのか」を伝えるためです。投げられたPromiseが解決されたら、それを投げたコンポーネントのレンダリングをリトライするという仕組みになっています。

- **「大域脱出と型推論の天才的かつ芸術的なコラボレーション」の型推論要素どこ？**

TypeScriptが`throw`が含まれるロジックをうまく解釈し、`get()`の返り値の型が`T`となったり`getData()`の返り値の型が`string`となったりするのはTypeScriptが頑張ってくれたおかげです。具体的には、フロー解析と呼ばれる処理を行わないとこの推論はできません。

また、どちらかというと大域脱出と「型システムそのもの」のコラボレーションと言ってもいいかもしれません。

- **素人が仕事のコードで真似すべきではない。**
- **多くの開発者がthrow Promiseを真似すると地獄になる。**

そうですね、仕事でReactを再実装するのは避けたほうが良いです。ただ、この記事はPromiseにはそこまで注目しておらずthrowに焦点を絞っていましたから、throwを使うと即地獄が生まれるかどうかは意見が割れそうですね。尤も、近年の関数型チックな風潮の中ではthrowを全部禁止したくなる気持ちも分かります。自分のところの設計と相談しましょう。

- **他のライブラリもPromiseをthrowするようになったら混ざってしまう。**

これは説得力がある懸念だと思いました。とはいえ、Reactの場合はコンポーネントは完全にReactに制御されたコールスタックの中で実行されますから、Reactと無関係ないライブラリがPromiseをthrowしても（無責任にPromiseを投げっぱなしにしない限りは）取り違えが発生することはまず無いでしょう。Reactのコンポーネントツリーの中に（React本体のSuspenseとは無関係に）Promiseを投げるサードパーティーライブラリも考えられない訳ではありませんが、それはReactに乗っかっている以上、サードパーティーライブラリ側が配慮すべきだと思います。その意味では、（知られる限りでは）最初にPromiseの“意味”をReact本体側で予約したのは上手くやったなと思います。


- **天才的かつ芸術的という語彙で本質をぼかしている。**
- **天才とは程遠いただ愚かなだけのプログラミングスタイルである。**

自分は天才的かつ芸術的だと思ったのでそう書きましたが、万人に賛同されるものではなかったかもしれません。いずれにせよ、天才的という言葉がなくてもこの記事で伝えたかったことは伝わると考えています。

- **エラー以外のものをthrowで投げるのが気持ち悪い。**
- **エラー以外のものをthrowで投げるのはthrowの本来の意図に反する。**
- **こんなことにthrowを使うのはバッドノウハウ・アンチパターンである。**

筆者の感覚では、気持ち悪いという感情的な問題よりはインターフェースが整うといった実利的なメリットの方が優先されると思っています。エラー以外を投げるのは`throw`の本来の意図に反するという点については、そうはいっても言語仕様上許されるのだから使い倒せばいいじゃんと思っています。何と言っても、関数境界を超える大域脱出が可能なのは`throw`だけなのですから。

とはいえ、考え方の問題ですから筆者が頭ごなしに否定することもできません。ぜひ自分の考え方を貫きましょう。

- **gotoの再発明。**
- **モダンgoto。**

確かに大域脱出ができるという点でgotoとthrowは似ていますね。インターフェースを簡潔にするという目的はTypeScriptにgotoがあればそれで解決できたかもしれません。ただ、throwは行き先を指定しないという点やcomposableであるという点でgotoとは異なり、そうでなければReactにこのように使われることは無かったと思います。