なぜわざわざ車輪の再発明に近い事をしているのか、その理由を考えてみます。つっこみコメント歓迎です！！
なぜReactjsの考え方は素晴らしいのか
まず、なぜReactjsの考え方が素晴らしいのか、いろんな人からいろんな理由が挙げられてますね。
- Virtual DOMが効率的だから。
- FRPの実装で、FRPこそが次のパラダイムだから
- シンプルに書けるから
等々です。
ですが、私は、これらはすべてに通じる根っこがあるように感じます。
その根っことは、
- プログラミングの最も純粋な形に近いから
です。
…一気に抽象的になってわけがわからなくなりました！！
説明しますね。
そもそも、プログラミングって？
プログラミングというのは、コンピュータへ与える命令を記述する作業の事ですね。
そして、コンピュータというのは、情報処理を行うために作られた道具です。
そうです、プログラミングとは、情報処理の手順書を書く事なのです。
当たり前？そうです、ですが当たり前で終わらせず、もう少しお付き合い下さい！
情報とは？処理とは？
情報ってなんでしょう？コンピュータが扱うのは主にデジタル情報ですよね。0と1です。
ですが、0と1だけでは表現力不足です。なので8個でひとくくりにしてみましょう。
なんということでしょう！！byteが出来上がったではありませんか！！
……当たり前です。ですが流さないでください！！
01の並びに一定のルールを課したもの、これが情報なのです。プログラミング言語においては「型」として表現されますね。
そして、処理とは、情報を加工することを指します。
プログラミング言語においては、これは「関数」として扱われます。
さてさて、 ここがとっても重要です！！ 情報処理を、プログラミング言語の文脈で解釈します。
そうすると……
- 型Aを、関数Fで、型Bに加工する
です。これこそが、プログラミングの最も純粋な形です。
変数の再代入がなぜダメなのか
コーディングする上で、できれば避けた方がいいコードがありますよね。
例えば、変数の再代入です。
1 int a = random(10);//a = 1~10
2 a = checkGT(a, 1);//a = 0 or 1
なんでダメなのか、なかなか上手く説明し辛いですよね。これを行ったせいで困った経験があれば簡単に実感できるんですが……
ですが、今なら上を使って説明できそうです。
- 1のaと2のaは違う型だから
です。同じintじゃないかって？そうなんですが、型の原点に立ち返ってみてください。
型とは、「01のならびに一定のルールを課したもの」ですよね。1のaと2のa、課せられるルールが違うのです。よって、本来ならば
1 int a = random(10);
2 bool result = checkGT(a, 1);
こうすべきなのです。ではこれはどうでしょうか。
1 int a = 3;
2 bool result = checkGT(a, 1);
3 result = checkLT(a, 1);
これもやっぱりダメなのです。冗長に書くと、2のresultはcheckGT(a,1)の結果を受け取ったbool型、3のresultはcheckLT(a, 1)の結果を受け取ったbool型なのです。課せられるルールが違います。ではこれは？
1 int a = 3;
2 bool result = withSideEffect(a, 1);
3 result = withSideEffect(a, 1);
同じ関数なので良さそうです。が、名前に注目してください！副作用を含んでいます！！言い換えると、2のwithSideEffectと3のwithSideEffectは違う関数なのです。よってこれもダメです。
だったら何だったらいいんだー、と言いたくなりますね…。うん、ええと、これなら大丈夫！！
1 int a = 3;
2 bool result = check(a, 1);
3 result = check(a, 1);
……無意味ですね。
さて、他のアンチパターンには触れませんが、 純粋な形から外れるので、アンチパターンとなる場合が多いです。
純粋な形というのは、問題から解法に向かっての最短距離なのです。言うなれば単純です。
シンプル。いいですね。
そこに制約条件が加わって、どんどん複雑になってしまいます。複雑は悪です。ですが、エンジニアリングは、現実という制約から逃げられません。
制約を迂回するために、遠回りを強いられることは往々にしてあります。
そのホットな代表選手といえは…
コールバック、君だ！！！！
コールバック……なぜ必要なのか
純粋な形、つまり、あらゆる制約条件を無視した場合、情報処理を一番自然に記述できるのは、関数型プログラミングです。ここに時間、空間に厳しい制約が加わると、オブジェクト指向プログラミングが解になります。
コールバック、非同期プログラミングがもてはやされたきっかけを覚えていますか？
C10k問題です。それまでは同期でよかったわけです。フロントのJavaScriptも、シングルスレッドという厳しい制限を課せられています。そう、コールバックとは、 制約を迂回するために複雑化したもの なのです。
で、Reactjsは……
Reactjsは、JavaScriptの性能が上がり、方法論が熟したいまだからこそ出現した、より純粋な形への回帰、と言えます。
やっと、Relayなのです
さて、ようやくRelayの話です。もう一度、情報処理を引っ張ってきます。
- 型Aを、関数Fで、型Bに加工する
型Aが膨大な情報を含んでいて、Bはその一部を処理したもの、という場合、A -> Bの変換にかかる計算資源は膨大になります。そういった巨大なデータを扱うFが、Relayです。
そしてそのFの引数を記述する言語が、GraphQLです。
つまりグラフ構造を上手く扱えるインメモリデーターベースを作ってるぜ！ということなのでしょう。
問題となるのが、サーバからRelayへデータを置く、そしてRelayからサーバへ置く方法ですが、SaaSのグラフデータベースを提供する予定とかあるのでしょうかね…
と本題が余談気味になったまま終わります！！Relayはどうでもよくて、コールバックますとだい！と書きたかったのが見え見えですね！！