00:06
6月7日、9月9時4分をまいりました。
今日の東京は意外といい天気ですね。
曇りも晴れていい感じです。
おはようございます。ゆめみのキースの川畑です。
では本日も朝活を始めていきたいと思います。
今回ですね、何読もうかなとちょっと悩んだんですけど、
タイトルにあると、Solid.jsっていうのがちょっと前にわずったというか、
State of JavaScriptのサーベイの中に
Solid.jsっていうのがいきなりドーンとJavaScriptのフレームワークで
1位を取ってきてて、突然すぎてなんだこの子っていうのが
僕の感想でもあったんですけど、
まだ全然触ってなかったので、
今日はちょっと改めて見てみようかなと思います。
実際、手を動かして触るっていうわけではなくて、
ドキュメントをバーッと読んでみようかなと思っています。
というところで、早速やっていきたいかなと思います。
ヘリンさんですかね、読み方。
立てたらよかったらいいと思いますけど、
ご参加いただきありがとうございます。
Solid.jsの公式ドキュメントを今からバーッと読んでいこうかなと思っていました。
公式タイトルは上からバッと舐めていく感じなので、
もし見たことある方は釈迦に説法って感じになるかもしれないですけどね。
早速やっていきたいかなと思います。
Solid.jsですね。
トップページの文言読むと、
ユーザーインターフェースを構築するための
シンプルでパフォーマンスと良いリアクティビティっていうところで
作られているライブラリーだそうですね。
4つぐらいいきなりメリットがあるよう話をしていて、
1つ目が高いパフォーマンス性ですね。
UIのスピードとメモリ使用率のベンチマークで
常にトップを維持していますというところです。
ここは本当そうですね。
ここだとグラフ出てくるんですけど、
本当にVanilla.jsとほとんど遜色のないスピード感を出すというところが
すげえなと思ってますね。
2つ目にパワフルっていうところをメリットにしますと、
組み合わせ可能なReactive Primitiveと
JSXの柔軟性の融合をしているということだそうですね。
ここだと出てくると思いますけど。
続いて、実用本位っていうことを強調してますね。
機能的で調整されたAPIっていうのが
開発を楽しくすごくシンプルにしますよって言ってますね。
最後に生産的ですと。
人間工学に基づいた使い勝手の良さで
シンプルなものから複雑なものまで
結構簡単に作ることができますよって言ってます。
皆さん、いろんなフレームワークそうですけど、
まず手軽さとか簡単っていうワードを結構皆さん使うので、
導入は簡単なんですけど、
実際に開発が始まったときに
どこまで開発者に寄り添ってくれるかって結構重要なので、
割と今僕の中であまり簡単に作れますよっていうワードは
不運ぐらいしか聞いてないんですよね。
タイプスクリプトのサポートもしてますし、
このライブラリの年数としては
03:01
5年以上ずっと開発を続けられるというのは結構高いですね。
GitHub Storeはもう18Kを超えているので、
割と注目されてきているというか、
本当にすごいなと思いますね。
自分もJavaScriptのライブラリ作ったことあって、
NPMで公開してるんですけど、
1Kダウンロードされるだけで本当にすごいし、
そもそもGitHub Storeで18K使うのが凄ましいですね。
最初にちょっとソースコードが出てきますね。
main.tsxっていうソースコードがあるんですけど、
これのソースコードは何かというと、
よくあるUseStateを使ったカウンターアプリの
簡単なソースコードが見せてくれてますね。
見せてますけど、行数にして実に14行という
すごく短い行数ですね。
かつめちゃくちゃリアクト感があります。
すごく似てますね。
リアクトでいうとこのUseStateってやつが、
SolidJSだとCreateSignalっていうような
関数になってますね。
同じようにリアクトと同じような復活というものが
実装されてますね。
コメントがありますけど、
お馴染みで特にモダンですよって話をしてて、
Solidっていうのは特にリアクトと
Knockoutという巨人の肩の上に乗っかっています。
あ、そうなんですね。
Knockoutも参考にしてるんですね。
懐かしいですね、KnockoutJS。
もしあなたがリアクトフックスを使って
開発したことがあるならば、
Solidはとても自然に感じられるはずです。
実際Solidのモデルはフックスのルールを持たない
よりシンプルなものになっています。
すべてのコンポーネントは一度だけ実行されて、
依存関係が更新されるために何度も実行されるのは
フックとバインディングだけだと言ってますね。
なるほどですね。
Solidは一方向性のデータフローで
リードライトの分離をしています。
あと、普遍のインターフェースとか、
普遍性を持っているんですね。
リアクトと同じような哲学も十分備えています。
しかし仮想ドームを使わない、
全く異なる実装になっていますというところが
一つの特徴になっているというところですね。
これについて詳細のほうのドキュメントが
あっているんですけど、
それはめちゃめちゃ長いので
これは後で読む予定だったので
ちょうどばっ飛ばしますね。
続いて、きめ細かいReactiveにより
少ない労力でより多くのことを実現できるよ
という話ですね。
Solidというのはユーザーランドのコードから
JSXViewへの効率的なReactive Primitiveで
構築されています。
とにかく、根幹の思想として
Reactiveというところが重要なんですね。
これによって、ドムのバインディングレベルでも
何をいつ更新するかを完全に制御することができます。
コストのかかる仮想ドムを超えて
Solidは必要以上の作業を行いません
というところでしたね。
Svelteもそうですけど、
仮想ドムって結構オーバーヘッドが高いという話を
いろんな方がされていて
そこなんだろうなと思いますね。
もちろん仮想ドムのメリットも全然あるし
SPを作る分には
仮想ドムって大きいアプリであればあれほど
06:01
メリットを恩恵受けやすいですからね。
ただ、やっぱりパフォーマンスというところを
より注目したときに
仮想ドムを選択しなかったということだと思います。
続いてパフォーマンス重視の話ですね。
クライアントとサーバーの両方とも
というふうにタイトル付いてますけど
決め細かいReactivityのアプローチの強みというのは
注目すべきベンチマークの全てで発揮されています。
パフォーマンスを重視しない場合でも
複雑なDXのコストは必要ありません。
クリエイトのパフォーマンスの向上は
ただ手に入るものと考えてください。
頑張らなくても早くなるということです。
おお、すごいこと言ってるな。
一応ここでグラフが出ていて
各ライブラリと
ライブラリ同士の比較ですね。
データの比較がグラフとしてが表示されていて
クライアントプラスサーバーのベンチマークというのがありますね。
これ単位はタイムなんで時間ですね。
何を表示するかというのは具体的なところは
別の記事とかともになっているのであれですけれども
やっていることは
2つですね。JSのフレームワークのベンチマークと
ISOMOPHIC UIベンチマークと2つ分かれていまして
これ多分初期レンダリングの時間かなと思いますね。
いや、勘でしゃべるのよくないですね。
The JS Framework Benchmark compares browser performance
across a wide range of tests.
Lower is better.
数字が小さければ小さいほどベターですよと言ってますけど
とりあえずブラウザーパフォーマンスというのを比較しているそうですね。
データを見ていっているんですけど
1つ目、Vanilla JSを1としてみます。
ここを多分基準に置くんですね。
そうした場合、SolidJSのバージョン1だと1.05なんで
ほぼVanilla JSと同じようなパフォーマンスを出しているということですね。
これ多分何かしらのアプリケーションを作って
そこに対するパフォーマンスベンチマークを取っているんだと思いますけど
実にVanillaを1とした時にSolidJSは1.05なので
ほぼ大差ないっていう
誤差の範囲でしかないっていうのがすごいですね。
続いてInfernoですね。懐かしいな。
Infernoのバージョン7.4.8だと1.2ぐらいの数字が出ると。
まあまあかなり早いなっていう感じですね。
続いてSvelteの3.37.9が来ます。第4位ですね。
これが1.27でさっきのInfernoとほぼ誤差みたいな範囲ですけど
ただやっぱりSolidと0.2以上離れているっていうのが
どれぐらいの秒数になるのかわからないですけど
多分ミリ秒単位でこの辺を計算しているはずなんで
割と差が出ているなっていう気がしますね。
続いてP-REACTですね。P-REACTが第5位で
これバージョンも10.5なんで最新の方ですね。
これが1.42で次がVue.jsです。Vueの3.0.6ですね。
バージョン3で比較しています。それでも1.54なので
もうだいぶSolidと離れましたね。
続いてP-REACTのバージョン17ですね。
09:02
ちょっと最新ではないですね。
こちらが1.93でAngularですね。
Angularの12も1.93でほぼ同値っていう。
Angular意外とパフォーマンス出るんだな。
もうちょっと遅いと思ってたんですけどね。
やっぱり世界はEmber.jsと比較するの好きなんだな。
バージョン3.22なんで割と最新の方ではある。
これが2.21でもう2倍以上って感じですね。
というのが比較です。
Solid.jsが圧倒的に速いよっていうのは確かに見えましたね。
このパフォーマンス重視ってところも別の記事が書かれていて
記事の全文のリンクが貼ってあるんですが
これはMediumでなおかつ全文英語なので
長いな。
長いので時間があれば戻っていきたいと思います。
続いていきますね。
とにかく全ての機能を搭載してますよっていうのが
次のお話だそうですね。
Solid.jsは一般的に期待されているライブラリの機能を
全てサポートしますと。
DXを向上するための側面を拡張しています。
例えばFragments、PortalsとかContext、Suspends。
Suspends入ってんの?
Error BoundariesとLazy Componentsですね。
Async、Concurrent RenderingとかImplicit Delegation、SSR&Hydrationとか
Directive、ストリーミングとか。
ほんとすごいですね。
Solid.jsほとんど全て含まれてるんだ。
それでいってそれだけのパフォーマンスを出し切れるっていうのは
なかなかすごい話ですね。
なるほどなるほど。
ちゃんとSolid.jsっていうのはMITライセンスなので
自由に使ってくださいねっていうOSSへの貢献もちゃんとやってますというところです。
一応トップページの記事ばーっと読んだ感じですね。
続いてGet Startedの話を読んでいこうと思います。
このGet Startedの下の方に確かLearn Solid.jsっていうのが確かあったので
それを読んでいこうかなと思います。
Get Startedは単純なNPMでインストールして
ディレクターのところでランデブしてくださいっていうようないつもの感じですね。
で、Solidを学ぶっていう章に入っていきますけど
Solidはアプリケーションの構成要素として機能する
合成可能な小さなピースが全てになります。
これらの部品は主に多くの浅いトップレベルAPIを構成する関数になります。
関数ですよねと。
幸いなことにこれらのほとんどについて知らなくても始めることもできますよと。
自由に使える構成要素には主にコンポーネントとReactivePrimitiveの2種類があります。
コンポーネントはいわゆるPropsObjectを受け取って
ネイティブのDOM要素や他のコンポーネントを含むJSX要素を返す関数です。
これはPascalケースのJSX要素として表現できます。
一般的なReactのコンポーネントの話だと思いますね。
ただPropsObjectなのでPropsObjectじゃなきゃダメなのかっていうのはちょっと気になりますけど。
続いてコンポーネントですね。
コンポーネントはそれ自体がステートフルではなくインスタンスを持たないという点で軽量です。
12:04
代わりにDOM要素やReactivePrimitiveのファクトリー関数としてできる。
ファクトリー関数という概念でいくのね。
なるほどです。
続いてSolidのきめ細かいReactivityはシグナル、メモ、エフェクトの3つのシンプルなPrimitiveで構築されています。
いわゆる復活の話だと思いますね。
これらが一緒になってViewを最新の状態に保つための自動追跡同期エンジンというのが形成されていますよ。
Reactiveな計算というのは同期的に実行されるシンプルな関数でラップされた式の形をしています。
例えばReactでUseStateみたいなやつがさっき言いましたね。
CreateSignalという関数があるんですけど。
CreateSignalという関数でもちろん戻り値はUseStateと同じで配列の1つ目にGetter、2つ目にSetterという感じですね。
ちょっとUseStateと違うのは、UseStateの場合はGetterではなくて厳密に言うと変数ですよね。値が返ってきます。
値が返ってきたものを変数で受け取って、2つ目がSetterですよね。
例えばUseStateのカウンターアプリとしては初期値0としましょう。
そうすると受け取りは多分カウンターとセットカウンターみたいなので受け取ると思うんですよね。
これがReactのUseStateなんですけど。
SolidJSのCreateSignalは本当にさっき言った通りSetterとGetterが返ってきます。
なので最初のほうのカウンターというものも関数になるんですね。
これしかもSetterなので値が見たかったらカウンターという関数を実行しなきゃいけないというのがちょっと特殊ですね。
次にSolidについて考えていこうということですね。
ソリッドの設計にはウェブサイトやアプリケーションを構築する上でどのような原則や価値観が最適なのかといういくつもの意見が込められています。
ソリッドの背後にある哲学を知っていればソリッドを習得し使うことが容易になるでしょうというところでバーッと来てますけど4つですね。
1つ目が宣言型のデータになります。
宣言型データとはデータの動作の記述を宣言に結びつけるということですね。
データの動作のすべての側面を一つの場所にパッケージ化することで簡単に構成できますよということですね。
意外と宣言型なんですね。
続いて消えるコンポーネント。
更新を考慮せずにコンポーネントを構造化するというのはちょっと難しいです。
ソリッドの更新はコンポーネントから完全に独立しています。
コンポーネント関数は一度呼び出されると消滅してしまいます。
コンポーネントは行動整理するために存在し他の用途はあまりありません。
なるほど。だから一度しか実行されないって言ってるんですね。
もう消滅するんですね。
変更あったらまたガッと実行するのかな。
続いて3番目ですね。
15:01
リードライトの分離という話ですけど、正確な制御と予測可能性がより良いシステムを作ります。
それはその通りですよね。
一方通行のフローを強制するための真の普遍性というのは必要ありませんが、
どの使用者が書き込んでいいかもしくはいけないかを意図して意識的に決定する能力があれば良い。
そういうルールは作ってますけど、別に普遍性である必要性はないというふうに考えてるんですね。
最後4つ目ですね。
シンプルはイージーに勝る。
なるほどですね。
きめ細やかなリアクティビティのために苦労して得た教訓です。
イメージ的で一貫性のある規約というのは、より多くの努力が必要な場合でもそれだけの価値があります。
目的は基盤となる最小限のツールを提供することですよということでした。
なるほどね。
すごく思想がはっきりしていて面白いですね。
続いての思想でウェブコンポーネントについて触れてますね。
ソリッドというのはウェブコンポーネントを第一級市民として持ちたいという願望を持って生まれました。
時とともにその設計は進化し目標も変わりました。
しかしソリッドは依然としてウェブコンポーネントを作成するための優れた方法になります。
ソリッドエレメントというのがあって、それを使うとソリッドの関数コンポーネントを比率してラップして小さくてパフォーマンスの高いウェブコンポーネントを作成できます。
ソリッドアプリの内部ではソリッドエレメントというものがソリッドのコンテキストAPIを活用して
ソリッドのポータルというのがシャドウドームの隔離されたスタイルをサポートします。
ちゃんとウェブコンポーネントの機能についてもサポートするような機能がソリッドの中にも含まれている。
ソリッドエレメントがコンテキストAPIを活用できてポータルというものがシャドウドームの隔離されたスタイルをサポートします。
この辺だそうですね。
全然書いてないしわかんないですけど中身そんな感じになってるんですね。
割とウェブコンポーネントに強い願望があって生まれたんですねソリッドっていうのは。
その発端とか全然知らなかったのでへーと思ってます。
まずウェブコンポーネントそのものははっきりと使えるかというと全然使い物にはならないと思っていて
あれでアプリケーションを作るのは結構厳しいんですけども
あれのおかげでいろいろプラットフォームとか売れマークをかき年を超えることができるっていう可能性ももちろんあるので
そこは結構魅力だと思ってるんですけどソリッドはそこに結構重きを置いてるらしいですね。
続いてですねサーバーレンダリングの端が来ました。
ソリッドは真のアイソモフィックな開発を可能にする動的なサーバーサイドレンダリングソリューションというのを備えてます。
ソリッドのリソースプリミティブを使用することで非同期データのリクエストが簡単にできて
さらに重要なことにクライアントとブラウザーの間で自動的にシリアライズおよび同期をされますと。
18:00
そんなまあ驚くことは今のところないかな。
ソリッドっていうのはサーバー上での非同期レンダリングとストリームレンダリングをサポートしているため
コードを一方的に記述してそれをサーバー上で実行できます。
つまりレンダーアズユーフェッチっていうところやコード分割ですね。
スプリッティングなどの機能がソリッドでも機能するということになります。
詳細についてサーバーサイドのほうのガイドっていうのもちゃんとドキュメントあるのでそれを見てくださいということでした。
非同期レンダリングとストリームレンダリングサポートしてるんですね。
勝手な感じでしゃべると、ということはRXが使えるってことなのかな。
ちょっとよくわかってないんですけどね。
今のところストアとかステード関連らへんの話が全然出てこないのでその辺がこの後出てきたら嬉しいなと思ってますけど。
続いてコンパイルなしっていうのが次ですね。
JSXが嫌い?クエスチョンってなっててどういうこと?
式をラップするのを手動で作業したりパフォーマンスが低下したりバンドルサイズが大きくなっても構いないですかっていう問いが投げられてますね。
そんなことはもちろん嫌ですけどね。
最初にJSXが嫌いだっていう人に対して皮肉的な問いを投げたところですね。
JSXが嫌いって言うならば式をラップするのを手動で作業したりパフォーマンスが下がったりバンドルサイズがでかくなる可能性あるんだけどそれでいいの?っていう問いですね。
代わりにタグ付きテンプレートリテラルやハイパースクリプトでコンパイルされない環境でそういったアプリを作成することも一応我々としてはできるらしいですね。
スカイパックっていうものがあるんですけどスカイパックを使ってブラウザーから直接実行することもできますよという。
スカイパック知らんかった。
同じようにこれ本当にそのhtmlの中でcdnからライブラリを読み込んでアプリケーションを実行することももちろんできますよと言ってますね。
ちなみにこれらをタイプスクリプトで動作させるには対応するDOMエクステンションズライブラリが必要であることも覚えておいてねってことです。
タグ付きのテンプレートリテラルっていうのはリットDOMエクスプレッションズで使用できてハイパースクリプトっていうのはハイパーDOMエクスプレッションズで使用できますと言ってました。
それぞれGitHubのリポジトリのリンクが貼ってあるんでその辺を使えば一応実現はできますねって話をしてました。
以上がlearnですね。
Solid.jsの学習というところのターンでした。
続いてですね、もうちょっと深掘りしていくんですけど、深掘りというかざっと舐めていく感じですね。
基本的なリアクティビティっていう章に入っていっております。
時間を許す限りに行きたいと思います。
ぼちぼちで多分時間がなくなってくるんで。
基本のリアクティビティっていわゆる基本的な機能の羅列になるのでそれを一個一個読んでいこうかなと思いますね。
一つ目ですけど何度も出てきたCreateSignalですね。
リアクトでいうUseStateの関数になります。
説明読んでいきますね。
これは時間の経過とともに変化する単一な値を追跡するために使用される最も基本的なリアクティブプリミティブです。
21:04
CreateSignal関数はGetterとセッターの2つの関数を配列として返します。
先ほど説明した通りですね。
UseStateは値とセッターを返しますけど。
SolidJSのCreateSignalっていうのはGetterとセッターという2つの関数を返すってところです。
Getterはシグナルの現在の値を返します。
追跡スコープ内、クリエイトエフェクト、クリエイトエフェクトってのは後ほど出てきますね。
UseEffectのSolid版と思ってください。
クリエイトエフェクトに渡される関数やJSX式で使用される関数など追跡スコープ内で呼び出された場合は
シグナルが更新されると呼び出し側のコンテキストも再実行されるようになりますということですね。
セッターっていうのはシグナルを更新します。
唯一の引数としてシグナルの新しい値かそれとも前回の値を新しい値にマップする関数を受け取ります。
値そのものかそれを変更するための関数も引数に受け取ることができます。
セッターはもちろん更新された値も返してくれますよってことでした。
使い方に関してはそのまんまですね。
Getterの方は単純に名前をカッコを付けて実行してください。
セッターの方もセットの関数で値に引数を渡すという感じです。
引数の方に関数を渡す場合は引数の関数の中の引数にはpreviousみたいな値があって
nextの値と更新してそれをリターンしてくれればいいですよっていう感じですね。
よくやるやり方ですね。
続いてシグナルに関数を格納したい場合は関数の形式を使用する場合は
それは今言った通りですね。
続いてオプションズですが
クリエイトシグナルのオプションズの話ですね。
solidのいくつかのプリミティブは省略可能な最後の引数として
オプションズオブジェクトっていうのを受け取れますということですね。
クリエイトシグナルのオプションズオブジェクトには
イコールズオプションをすることができます。
何言ってるのって感じですけど
例えばクリエイトシグナルで括弧のイニシャルバリューっていう変数を渡してあげて
第2引数にオブジェクトのキーにイコールズで
trueもしくはfalseっていうのを指定できるっていう感じですね。
デフォルトではシグナルのセッターが呼び出されたとき
新しい値が古い値と実際に異なる場合にのみ依存関係というのが再実行されます。
イコールズをfalseに設定することで
セッターが呼ばれた後に依存関係を常に再実行できるようになります。
また独自の透過関数を渡すことももちろんできますよということでした。
さっきのイコールズの後ろにtrue、falseを渡すんですけど
そこに関数を指定してあげても別にいいですよと。
その関数がレスポンスにちゃんとブーリーアンチを返すのであれば
24:00
それも指定できますよって感じですね。
最後の値と等しいと見なされた場合は更新発生しなくて
ちゃんと差分があれば更新が発生しますよという感じですね。
今のがcreate signal、use state的なものでした。
続いてcreate effectですね。
これはいわゆるuse effectと同じようなものですけど
こちらは依存関係を自動的に追跡して
それらが変更された各レンダリングの後に実行される新しい計算を作成します。
REFを使用したり他の副作用を管理するのに結構理想的だよということですね。
それ以降にはちゃんとREFっていうのも実装されてるんですね。
使い方はuse effectと結構似てますね。
create effectで関数があってその中でわちゃわちゃやってねっていうことはそうですね。
いわゆる副作用的な扱いでいいと思います。
このeffect関数っていうのはそのeffect関数の前回実行時に返された値で呼び出されますと。
内部的に持ってるっぽいですね。前回の値を。
この値はオプションの第2引数として初期化ができます。
これは追加のクロージャーを作成せずに差分を取る場合に便利ですよってことですね。
例の方は単純な値を更新するっていうもので使ってるので
例の方のcreate effect関数の第2引数には0が指定されてますね。
その値で初期化するっていうような感じだと思いますね。
なのでuse effectの場合って第2引数ってどれを変更検知の対象にするかっていうのを確か配列で指定したと思うんですけど
solid.jsのcreate effect関数にはそういう概念はないよってことでした。
第2引数は基本的に初期化するための値を指定するっていう感じですね。
ここもちょっとやっぱりリアクトと違いますね。
30分きたんですけど僕がちょっと朝遅れたので35分までやっていきたいと思います。
もちろんお時間ある方は絶対抜けていただいて大丈夫です。
この35分までちょっと突っ走って、続き明日かな、ちょっと読んでいこうかなと思います。
続いてですね、create all memoです。
use memoみたいなやつだと思いますね、これも。
こちらはですね、実行された行動の依存関係が更新されるために度に値を再計算する読み取り専用の派生シグナルっていうのを作成します。
派生シグナルを作成する。
いわゆるメモ化なんですね。
使い方としては同じようにcreate memoで括弧の中にその関数を指定してあげるよってことですね。
戻り値の中にgetterが返されますと。
そのgetterの関数を実行して値を読み取れるようにしますよって感じするんですね。
セッターは今回ないですね。
明らかにメモ化するだけなのでそれはセッターをする必要はあんまないと思ってますから。
27:00
今回のそのメモ関数ってやつは、このメモ関数も前回実行時に返された値で呼び出されますと、基本的には。
この値はオプションの代入式数として同じように初期化できますと。
これも計算量を減らすのに便利ですよねって感じでした。
結構シンプルですね。なるほどね。
このメモ関数ってのはセッターを呼び出すことによって他のシグナルを変更してはいけませんと。
それは純粋でなければいけませんよっていうところは注意してくださいってことでしたね。
これによって読み込まれた依存関係に応じてメモの実行順序をでも最適化することもできますと言ってますね。
なるほど。だいぶシンプルですね。
リアクトニズメモもだいぶシンプルであるんですけど、結構使いどころとか条件とかを加味した上で使ってくださいみたいなところがあると思うんですけど、
その思想に近い面はなくはないですが、
他のセッターを呼び出すことによって、いわゆるクリエイトシグナルの他のシグナルを変更しちゃいけないよってことですよね。
なるほど。クリエイトメモの中でセッターを呼び出してシグナルの変更するのはNGだっていうのが今回のルールっぽいですね。
というところでした。あくまでメモ化したいときのためだけに使ってないっていうところっぽいですね。
続いて、クリエイトリソースっていうフックスですね。これはちょっと新しい。
こちらはですね、非同期リクエストの結果をシグナルするシグナルを作成します。
日本語が多く崩壊しそうだな。
非同期のリクエストのレスポンスの値をシグナルとして保持することができるということですね。
クリエイトリソース関数っていうのは非同期のフェッチャー関数っていうのを引数に受け取って、
そのフェッチャーが実行結果完了したときに結果のデータで更新されるシグナルを返します。
いわゆるセッターとゲッターが変えるって感じですね。
クリエイトリソースを使用するには2つの方法があって、
1つ目はフェッチャー関数を唯一の引数として渡すか、
または最初の引数としてソースシグナルを渡すことができます。
ソースシグナルはそれが変更されるためにフェッチャーを再トリガーし、
その値がフェッチャーに渡されるようになります。
これどうやって見てるの?
単純にフェッチャーを渡すか、1つ目の引数にシグナルを渡して、
2つ目の引数にフェッチャーを渡すと。
なるほどですね。
戻り値のところですね。戻り値のところの値を見てみますと、
もちろん配列で2つ受け取って、
1つ目の戻り値っていうのがいわゆるゲッターですね。
データが返ってきます。
2つ目の方はオブジェクトになってミューテートとリフェッチっていう、
これも関数だろうな多分。
っていうのが2つ目の引数にオブジェクトとして返されますね。
これらのスニーベッドではフェッチャーは関数フェッチデータです。
なんか日本語が変だな。
30:00
どちらの場合もフェッチデータっていう関数があって、
これは今回ソースコードですね。
サンプルのソースコードがフェッチャーとしてフェッチデータっていう関数が
渡されているっていうふうな前提でいてください。
そのフェッチャーとなる関数ですね。
フェッチデータっていう関数が解決を終えるまでは、
ゲッタのデータっていうものの値はアンディファインドになります。
1つ目のケースっていうのは、
シンプルにフェッチャーをクリエイトリソース関数に渡しただけのパターンですね。
この場合はフェッチデータっていうのはすぐに実行されます。
2つ目の方がシグナルとフェッチャー2つを渡したパターンですね。
2つ目の場合では、
ソースシグナルっていうのがフォルスまたはヌルまたはアンディファインドみたいな、
いわゆるフォルシーの値以外の値を持つとすぐにフェッチデータが呼び出されます。
また、ソースシグナルの値が変更されるたびに再度呼び出されて、
常にフェッチデータっていうふうに大規制として渡されますよという感じですね。
どちらの方法でもMUTATEっていうレスポンスの中の関数があって、
それを呼び出すことでデータシグナルっていうのを直接更新することができるようになります。
名前の通りMUTATEなんですね。
他のシグナルセッターと同じように動作するっていう感じですね、このMUTATEっていうものが。
またリフェッチ関数を呼び出すことでフェッチャーを再度実行できて、
リフェッチ括弧インフォみたいなように追加の引数を渡すことで、
フェッチャーにも追加情報を提供することができますということですね。
デフォルトのフェッチャーは引数の値っていうのは基本的に渡されたシグナルの値が渡されるはずですけど、
加えて何か値を渡したいときにはリフェッチの関数の引数に値を渡してあげてくださいという感じですね。
ダラダラーと読んでいったんですけど、
気づいたら36分になってしまったので、
ここで今日の朝活はちょっと終了にしたいかなと思います。
続きはですねライフサイクルの話が来るので、
次回はSolidJSのライフサイクルの話から続き勉強していきたいかなと思っていますので、
もしご興味ある方はお付き合いいただけると嬉しいなと思います。
では今日の朝活はこちらで以上にしたいかなと思います。
ご参加いただいた皆さん本当にありがとうございました。
では今日も一日頑張っていきましょう。
お疲れ様です。
