00:06
はい、1月15日、火曜日ですね。 遅刻は朝9時を回りました。
今日も天気、あんまりよろしくないですね、東京は。 昨日もそうだったんですけど、急に雨が降ってきたので、
体調の悪い皆さんも気をつけていただければと思います。 はい、おはようございます。ひめみんのkeethこと桑原です。
では、本日も朝活を始めていきます。
えーとですね、今日は、ちょっと、何やかんや言って、 結局テクノロジー的な技術的な記事を、今日は読もうと思ってます。
で、タイトルがありますね。リミックスっていうJavaScriptのフレームワークですね。
またフロントエンド回って感じですけど、 ついつい僕が流れてきて、
かつ興味がある技術がやっぱりフロントエンド回りなので、 ご了承いただければ幸いです。
で、タイトルですね。The Yang to React's Yinですね。
まあ、リアクトの影に光よっていうタイトルで、 結構、なんかエモーショナルなタイトルだなと思いましたけど、
まあ、リミックスの記事を読めるんだったら、 ちょっと読んでいこうかなと思ってます。
で、えーと、翻訳しようと思ったんですけど、
これですね。この記事の日本語翻訳をされている方がいらっしゃったので、 そっちの方の記事を読んでいこうと思います。
ありがたいですね。ほんとに。 じゃあ、続きたいと思います。
私は2015年からリアクトのアプリを作り続けてきました。
その時から、リアクトは私の生産性を飛躍的に向上させる 唯一無二の存在でした。
リアクトの状態に応じてUIをレンダリングする 先限型モデルっていうのは、
私の考えるウェブのUIの構築方法を 劇的に簡単にしてくれましたと。
また、リアクトっていうのは、アンギラJSやバックボーンを使ってきた時の 遥か先を行く状態に関する素晴らしい考えも与えてくれましたと。
懐かしいですね。アンギラJSの方ですね。 アンギラじゃなくて、アンギラJSの方です。
とか、あとバックボーンですね。
昔のJavaScriptの3大フレームワークと 言われているものの2つですね。
もう1個はノックアウトJSっていうのがありましたね。 すごい懐かしいですね。
もう8年前とかになるんじゃないですかね。
僕が新卒の頃にそんな名前を見て ほーっと思ったのを覚えてます。
戻りますね。
リアクトのタグラインっていうのは、 ユーザーインターフェースを構築するための
JavaScriptライブラリというところになっております。
リアクトはこれを先限型コンポーネントモデルを 一番に開発し提供することで見事に実現しております。
状態管理なしではユーザーインターフェースを 構築することはできません。
例えばこのコンボボックスのメニューが オープンなのかクローズなのかみたいなところですね。
例えばですけど。
はい、などなどです。
それが理由でリアクトはコンポーネントの 状態管理ができるようになってます。
ちなみに状態管理はリアクトの中でも 一応ステートっていうのを持ってはいる。
JavaScriptフレームワークというか ライブラリの中にもあるんですけど、
今は普通に外部的なステート管理のライブラリを 使うことがほとんど多いと思います。
同じフェイスブック社ですね。
今メタですけど元フェイスブックの時にですね。
フェイスブック社が最初にリアクト作った時に、
単一フローの状態管理っていうところの考え、 概念を構築して、
それを実際にライブラリに落とし込んだものに、
03:02
フレックスじゃなくてフラックスですね。
フラックスっていう概念があって、
それそのままフラックスという名前の ライブラリもあるんですけど、
っていうのを提唱したと。
これが一つまた大きかったと思いますね。
昔はその状態管理っていうのは、
DOMの方とJavaScript、Logicの方で、
結構緊密に行われてたりしたので、
割とカオスな状態管理をしてたと思います。
DOMの方でも割と、
DOMからシンプルなHTMLじゃなくて、
いろんな状態がガチャガチャしてたので、
見づらいというか、
管理しづらいみたいな時もあったんですけど、
リアクトの方では状態管理っていうか、
状態フローを一つ一本にしておって、
その間にちょっとコードが冗長になったりするとか、
少し面倒くさい書き方になってしまいましたけど、
ただ状態管理っていうそのものについては、
それもシンプルかつ、
分かりやすい設計になったので、
それもすごく良かったと思います。
そこから発展して、
Reduxっていうものが生まれて、
Reduxが一旦、
一時代を築いたと言ってもいいんじゃないかなと思います。
フロントエンドの状態管理として、
Reduxが一つの時代を築いたなと思ってますね。
それと似たようなものとして、
VueがReduxを作ったっていうのもありますし、
あれも結局状態としては一つの、
単一フローっていうところは、
継承じゃないか、何だっけ。
真似て作ったっていう感じですよね。
これはなかなか良かったと思いますね。
すいません、余談でした。
戻りますと、大事なのはですね、
Webアプリケーションの要素っていうのは、
ローカルのコンポーネント状態の以外にも、
たくさんあるっていうところです。
実際に典型的なリアクトのアプリケーションで、
読み込まれる状態の大多数は、
全くもって状態ではなく、
サーバー由来の状態のキャッシュ、
おそらくデータベースなど、
永続層から取得したものになります。
状態と言っても、
結局欲しいのはデータですからね、要は。
データが今どうなってますかっていうところが、
結果状態として反映されるだけなので、
そこですよね。
リアクトは常に素晴らしい状態管理方法を
提供しているとはいえ、
我々が管理している状態の多くが、
実はキャッシュであり、
キャッシングの問題に悩まされているという事実を
隠すことはもちろんできません。
大体この辺は皆さんもおおむね同意だと思います。
フィルカールトンの有名な格言が示す通り、
フィルカールトンの有名な格言というところが、
別の記事が貼られていますね。
2017年12月に
Naming Things Hardという記事が書かれています。
それも興味ある人は見てみてください。
後ほどこの記事もお知らせします。
格言が示していますけど、
コンピュータサイエンスには
2つだけ難しいことがある。
1つはキャッシュの無効化、
もう1つは命名だとおっしゃっています。
いろんな意味でこれはジョークなんですけど、
キャッシュの無効化は確かに間違いなく
難しいものになります。
命名も確かに難しいけど、
この辺はジョークでしょうね。
そしてこの問題を簡単にするために、
無数のライブラリやツールが
開発されていることからも分かる通り、
リアクトは現時点までで
キャッシュ問題の解決策を
何も提供していきませんでした。
例えばReduxとか、今はReduxツールキットに
集約されましたね。
とかMobXとかApollo、
06:00
これはGraphQLのライブラリですね。
とかリアクトクエリですね。
リアクトクエリは今Turnstackという名前になって
リアクト依存というか
リアクトのためだけのものではなくて、
あらゆるライブラリとかJavascriptフレームワークにも
使えるようになりましたね。Turnstackとなりました。
とかあとSWRとか、
もしくはそれ以外のいろんなツールが出ましたけど、
いろんなツールとか方向性解決策が生まれつつ、
ただ1本これだというものは
なかなかまだないというところですね。
ウェブ開発において
リアクトが下記の解決策を
自前で提供していないという
共通の問題のためだけに
これらのツールにたどり着いているんですよと。
その解決策というのは
ネットワークキャズムの管理というところだそうです。
一言に言うとそういう風に言われるということですよね。
僕は今この言葉どういうことだろうと思っているので
続けて読んでいこうと思います。
ネットワークキャズムとはというところですけど、
ネットワークキャズムなんか
一応画像がペッて貼られていまして、
一つの大きい四角い箱があって、
その中に箱二つ分かれていますね。
クライアントとサーバーがあって、
その真ん中にネットワークキャズムというものがあるんですけど、
それらは一つの大きい全体集合みたいな形で
くくられているという感じですね。
これがネットワークキャズムだということだそうです。
ウェブデベロッパーとして、
我々はクライアント側、いわゆるブラウザー側と
サーバー側で動くコードというのを書きます。
我々はそのネットワークのコントロールというのはできません。
そもそもこれが理由でキャッシュを考えなければならなくなっている
というところです。
ユーザーがTACOSの選択をするために
リアクトコンポーネントをサイレンダーするとき、
そのTACOSで選べるオプションに
同期的にアクセスする必要があります。
まあまあそういうことですね。
だからネットワークを介してHTTPリクエストを作って
サイレンダーのときに使えるように
その値をリアクトの状態、もしくは何かしらのライブラリを使って
メモリ内キャッシュに保存しますと。
あなたはその大規模小規模両方のアプリで
最もバグを引き起こす原因を知っていますかと
結局答えはコードだそうですね。
プログラミングコードだそうです。
ネットワークキャズムというのは大量のコードの源になります。
それを正しく扱うのは極めて困難ですが
ウェブサイトを作っているのですから
挑戦しなくてはなりません。
その結果、JavaScript、今どきのFetch API、
もしくは便利なライブラリを駆使して
HTTP経由でネットワークキャズムを跨いで
バックエンドとデータをやり取りするための
掛け橋を作ることになりますと。
現在のクライアントサイドアプリは基本SPAになって
バックエンドがNodeだったりRailsだったり
PHPだったりJavaだったり
リクエストを投げるというところですね。
クライアント側がSPAで
ネットワークキャズムはネットワーク通信に挟んで
サーバーがフレームワークですね。
この掛け橋に必要なコードは全てフロントエンド側にあります。
データの取得においてはどのコードを取得するべきか
どのコードを取得するべきかを把握する必要があって
大抵の場合データを取得するコードと
そのデータを使うコードを同じ場所に置きたい。
こうするとバックとかミストとか余分なデータの取得が
大幅に軽減できますよね。
09:00
と思うので難しいものになります。
フェッチ系のコードと取得したデータを
ごにおるというところはできれば同じ場所に置きたいですよね。
視認性とか管理性も一緒やすくなりますからね。
これにはコンポーネントがレンダーされるまで
データを取得できないという残念な副作用もあります。
リアクターでもその辺に対して
バージョン17でサスペンスを入れてくれましたね。
それに加えてアプリの読み込みをより早くするために
コードの分割、スプリットをしようとすると
コンポーネントレンダーだけじゃなくて
レンダーが始まってしまうと
それに必要なコードの読み込みもしなくてはいけなくなります。
これはネットワーク、ウォーターフォールを
引き起こすのです。
我々はウォーターフォールの危険性について
みんな知ってますよね。
ウォーターフォールの危険性というのは
別の、これは記事ではなくて
YouTubeリンクですね。
プレゼンのリンクが貼られているので。
見たことあるか分からないですけど
後ほど開いてみようと思います。
ウォーターフォールを引き起こすのは
よろしくはないですよね。
残念ながらデータの読み込み自体は
この問題を解決しません。
実際データ読み込みのための
リアクトサスペンスでさえ解決することはできません。
サスペンスはユーザー側に
どういうアクションをするかというと
先に返してあげる。
その中の裏の方をガチャガチャ頑張る。
その他にプロミスもラップしていて
プロミスをうまいこと制御することで
データフローのところとかの
管理はしてますけど
ただコンポーネントだけ解決ではなく
テクニックでなんとかしてるって感じは
否めないのはもちろんそうですね。
サスペンスってのはコンポーネント内から
データを取得するようなデータ取得用の
ライブラリにとって変わることはできます。
そしてデータがまだキャッシュされていないなら
そうするようにデータを誘発します。
が、ウォーターフォール効果を避けたい場合
というのは、これらのコンポーネントの
コードがレンダリングされる前に
データのフェッチを開始する必要があります。
途中でやるのが大変ならば
先にやるしかないんですけど
結局はね。
レンダリング中にデータを取ってくるってのは
結構テクニカルすぎて
僕は結構怖いと思いますけどね。
続いて、より早い読み込みというところのセクションです。
これこそ私がリアクトルーターが
この問題をリミックスで
気に入っているところの多くを取り入れることで
解決していることにとてもワクワクしている
理由だそうです。
アイディアというのを取り入れることで
リアクトルーターは解決しようとしているんですね。
へー、なるほどでした。
で、りゃんっていう方はこのことについて
彼の投稿
リアクトルーターをリミックスすること
というような記事があって
そこで語られているらしいですね。
それのリンクも貼られています。
これは多分リミックスのドメインなので
リミックス公式のブログですね。
リミックシングリアクトルーター
というブログが書かれているそうなので
興味ある人は見てみてください。
この中で語っていますと
レイアウトネストルーターと
ローダーズ、データの取得ですね
ローダーズおよびアクションズ
データの書き換えですね
のおかげでコンポーネントとデータ取得を
切り離すことはできますけど
コロケーションの恩恵は受けることができますと
このデータ取得はこの場合
12:00
コンポーネントの中ではありませんが
ネストされたレイアウトルーターのおかげで
とても近い位置にはでもありますと
結局でもコロケーションの恩恵受けられるんだったら
だいぶいいんじゃないですかね
これらの機能によって
我々はレンダーしないとデータの要件が
分からないというところから
URLからデータの要件が分かるというところまで
近づいてくれますと
さらにリアクトルーターというのは
今までは
あなたの代わりにネットワークキャズムの
一部を管理してくれるようになります。
それが意味するところはローディングとエラー状態
というのを気にかける必要がある
自前の行動というのは大幅に削減できると
これは大きいですね確かにね
リアクトルーターがキャッシュの
再検証を行えるということでもあります
そしてフォームの再送信と
競合条件も
UIの開発における難題の一部である
競合条件も
解決できるのかな
さらに優れたユーザーエクスペリエンス
楽観的UIなどの
構築がかつてないほど簡単になりました
これにより実質的にネットワークキャズムを
少々狭めることができますよということですね
リミックスルーターアップスと
クライアントサイドアップスというところで
また画像が張られてるんですけど
さっきはSPAと
バックエンドフレームワークのところですね
との矢印と今の
リミックスルーターアップスの
矢印ですけどそっちのほうが矢印が
短くなってちょっとバックエンドに近づけた
って感じですね近づけたというか
ネットワークキャズムが小さくなったという
幅が狭くなったということですね
画像的に意味で幅って言ってますけど
理由というか
中身としてはさっき
申し上げた通りですね
そもそもローディングとエラー状態の
気にかける自前コードが結構
削れたりとかキャッシュの再検証
できたりとかフォームの再送信
強豪条件もバチャバチャ感じ
できるかとかそんなところですね
結構それで解決は
近づけたと思うんですけどもっと
改善できないかというのは次のセクションで
いきますとこれらの機能が
リアクトルーターで利用できるということは
コードを簡素化したい人や
アプリを高速化した人なら誰しも
にとって大きなメリットになります
リアクトルーターというのは
データの取得のためのリアクトサスペンスと
最も幸せなタッグになるでしょう
確かメタは持ってるであろう
インフラストラクチャーとコンパイラーとかルーターを
他に持ってない限りはということですね
しかし我々はもっと改善できます
一度ブラウザの読み込みを早めたとしても
最初のJavaScriptバンドルが
表示され実行されるのを待たないことには
ユーザーには何も見えません
データの読み込みや書き換えの管理を
手助けしてくれるリアクトルーターを
カッコキャッシュと言ってますけど
要はキャッシュの管理するコードの多くを
削除できますけどそれらの全コードは
まだブラウザ上にあります
さらに我々はデータ取得後のコードが
データ取得のためのコードの前に
必要なのでこれはコード分割では
なくなっているということですね
もし仮にそのコードをすべてブラウザから
サーバーに移すことができたとしたら素晴らしい
と思いませんかと
素晴らしいけどネットワークIO増えるのも
どうなのっていうのは僕はちょっと思ったりしてますけどね
まあいいや読んでいきましょう
サーバベースのやり取りやその秘密鍵を
必要とするAPIを叩く必要がある度に
15:00
サーバーレス関数を書く必要があるのは
煩わしいことではありませんかと
これは煩わしいですねおっしゃる通りです
リアクトサーバーコンポーネンツが
やってくれることを我々に約束し
我々は確かにそのデータの読み込みを
待ち望んでいますけど
リアクトサーバーコンポーネンツは書き換えに
関しては何もしてくれないですよねと
やはりコードをブラウザの外に出すことが
できればリソースを持つ必要がなくなるし
まあいいと思うんですよと
そうだリアクトサーバーコンポーネンツ
読み込みを待ち望んだりそこはやってくれるけど
書き換えはやってくれないか
失礼しました確かに
サーバーコンポーネンツは書き換えは
確かにやらないですねあくまで最初の
レンダリング読み込みのところについての
テクニックというか技術だというのは確かにそうですね
この辺はだいぶ前に
RFC読みましたけどその辺
公式が出しているRFCブログがあるので
その辺読んでいただくといいと思いますね
次のステージのところで
リミックスの公式リンクがまた張られていますと
あなたのアプリを
次のレベルに進化させようとすると
サーバー側でアプリを
レンダーしたくなるでしょうと
それはサーバーサイドレンダリングに近いところはあると思いますけど
そしてそれを実現する
ファイ前作というのがリミックスを使うことなんです
リミックスはネットワークの境界の
架け橋というのはあなたが何も考えなくて
済むように仕上げてくれますよと
そのデータ取得だったりデータの書き換えのコードを
従来のリミックスルートモジュールというのを
エクスポートされた関数に
移動させるや否やリミックスが
全てのネットワークキャズムを処理するようになりますと
はー
本当に言ってんのそれ
なんかまずリアクトサーバーコンポーネンツの
なんですかいわゆる概念も
含めたさらにそれの上位層の
実機能というのがリミックスに
入っているというように今聞こえますけど
細かいなって感じですね
今やあなたのアプリはユーザーが
JavaScriptを読み込むのを待つ必要がないので
本当に空を飛ぶことができますと
アプリはそこにありユーザーのために準備されています
そしてプログラッシブエンハンスのおかげで
裏でJavaScriptがダウンロードされている間
全てのリンクとフォームも機能しますと
はーね
そしてこれを手に入れれば今あなたは
サーバー上で動作するコードを書くことができるようになったので
データベースを直接呼び出すことや
秘密書きでAPIを叩いたりすることを
心配する必要はもうありません
ローダーやアクションは
サーバー上でしか動作しなくなるので
あなたが必要なことは何でもできるようになります
素晴らしいDXの改良ですと
とてもなんか夢のある
話なんですけど
そのためには何かあると思っています
そんな銀の弾丸みたいなお話は
この業界にはないと思っているので
何かしらの代わりの
落とし穴じゃないですけど
制約はある気がしますね
でもやろうとしていることや目的はとても素晴らしいことで
確かにフロント側で
これは望んでいたことであると思っています
僕はですけどね
アプリ全体についてという話です
リミックスがサーバー側の力を
あなたに与えるということは
必要であればアプリの処理全体を
管理することができるということを
意味しています
全ての人がそうしたいわけではもちろんないですけど
データベースや関連するサービスと
直接やり取りができるバックエンドを扱えるということは
どちらかというと
このような構成のアプリを作ることが可能になります
先ほどまでずっと見てきた画像ですね
18:00
SPAがあって矢印が伸びていて
バックエンドのところですけど
その矢印の長さが
どんどん短くなっていって
最終的には全部
フルスタックにリミックスできるよということですね
すごいのはネットワークキャズムを
完全にコントロールするというメリットを
F%リミックスを使ってもそうでなくても
全て得られるということです
つまり既存のバックエンドに満足しているのであれば
もちろんそれを使ってもまあいいよ
もちろんリミックスを使えば
割と近いところまでいけますけど
結論ですね
リアクトのタグライン
ユーザーインターフェースを構築するための
JavaScriptライブラリというタグラインですけど
これに関してリアクトは
素晴らしい仕事をしています
リアクトは一度もネットワークキャズムの管理を約束したことはありませんが
全てのウェブアプリケーションで
それが必要にはなります
ネットワークキャズムを管理するリミックスを使うことで
我々はようやくリアクトの影から
用の部分を得ることができました
素晴らしいレンダリングライブラリと
強力なネットワークキャズム管理に
より良くより早いアプリケーションを作る
より少ないバグで
より簡単なコーデ
そして楽しく作ることもできます
冒頭に言った通りですね
コードが少なければバグも少なくなる
だろうし
さらに簡単なコードかつ
短く書けるとリミックスは優れている
ということは言いたいなと思いますが
私事ですけど
これが私がウェブアプリをリミックスで
構築することに続行な理由です
あなたが今日この記事を読んでいるウェブサイトは
リミックスに書き換えた結果になります
始めた当初はそれがどんな素敵なものになるか
全く思いもよりませんでしたが
リミックスは全てを可能にしました
なぜなら基本的な機能を完成させたとき
もっと多くのことをする時間と能力があるということに
気づいたからです
詳しいことは私がサイトの再構築をしたことについて
記事を書いているのでそれも見てみてください
と言いました
リミックスは私の持っていた楽しいアイディアに
イエスと言える気持ちさせてくれた
このことがとても新鮮でした
あなたのより良いサイト作りの役に立てれば幸いです
いつもクールでー
というところでこの記事は締められておりました
ちょっとリミックスの
まだカラクリとか
公式ブログも全然僕読んでないので
なんとなくコンセプトとしては
別のクイックですね
クイックというジャバスクリプト
フレームワークがあるんですけど
あれと似てる気がしますね
クイックも初期レンダリングが
とにかくランダウが
1になると
n12まで下げることができる
ということを言っていて
カラクリしたら確かにそうなんですけど
やっていることは同じですね
ジャバスクリプトを初期で全部読み込ませるのではなくて
初期はとにかくドムだけ
その裏で必要なものを
起動期でずっととにかく
裏側で取りに行くというところですね
ということをリミックスも同じようなことを
やってるんじゃないかなと
必要なものを必要なときにバックエンドにコールして取りに行く
というところなんじゃないかなと思ってます
ただリミックスのさっき
終わりの方に書いてあった大きいところは
リアクトサーバーコンポーネンツみたいに
サーバー側でのレンダリングを
コンポーネント単位とかでやってるという話ではなくて
そもそも
ジャバスクリプトそのものを裏側で
全部バックエンド側に押し寄せることができると
21:00
かつそれをもっと進めることで
フルスタックに作ることもできる
というのが大きな違いなんだろうなと思います
ただフルスタックに作ることができるだけであって
それがベストとは言ってないし
そこは結構重要ですね
必要であればちゃんとAPI形式にする方がいいと
僕も思ったりはしてますし
途中で言いましたけどネットワークIOが増えるのは
あんまりよろしくないとは僕は思ってますね
ギガが減る問題というのは
ユーザーにとってそれはそれで別の課題ではあるので
というところでした
なかなかでも
読んでて夢のあるような話に聞こえたので
やっぱり
クイックも勉強してるんですけど
リミックスも何やかんや
触りたくなってきましたね
リアクトに不満があるわけではないし
リアクトっていうのは本当に素晴らしいライブラリーで
今も革新的な進化をずっと続けていますね
一番いいのは
リアクトっていうのはちゃんと開発者のことを
すごく考えたライブラリーである
というのが僕らとしては嬉しいと思います
ただ本当にユーザーにとっての
ベストっていうと
果たしてどうなのっていうところはあったりします
そこのバランス感覚が上手いこと優れてる
ライブラリーが今後も伸びていくんだろうな
とはもちろん思いますけど
難しいところですね
やっぱりパフォーマンスというか
速さっていうところは絶対に
ユーザー体験にマスな要件なので
そういうところにリミックスは
一律の長がリアクトよりはあるんだろうな
というのは思います
ただ開発者体験がどうなのというのは別の問題だと思うんですけど
これに関しては
その辺ちょっと読んでみようかなと思ったりしています
というわけで
今日の朝発はこの辺で以上にしたいかなと思います
今日も朝からたくさんの方が参加いただき
大変ありがとうございました
今日はプテヤノドさんと
ゴゾウゴフさんと
ケイさんと
タツヤハザカさんですね
ご参加いただきありがとうございました
また明日も
この流れでいくと明日も
もう一回リミックスのこのブログ
別のブログ読みたくなってきましたね
プロトタイピングの記事ですね
2020年の記事で
古いんですけど
とある方がそのプロトタイピングについて
自分でデザイナーとして
ずっと多くの時間を継ぎ足したいんですけど
それについての知見をお話ししたいという
ブログがあったので
そっちも読みたかったんですけど
どっちを読むか
明日の自分が決めようと思います
もし興味があれば来てみてください
ではこれで終了したいと思います
また火曜日ですね
それでは終了です
お疲れ様でした
