音声書き起こし
1. オープニング
Guest
こんにちは、こんにちは
Guest
こんにちは。
Guest
それでは、今週もitインサイドやってきましょう。UIT INSIDEは、ユーザーインターフェースと、テクノロジーを愛する開発者のためのポットキャストです。
Guest
最新のweb標準や開発、フェイマークの変遷、
Guest
uyexに関することまで、様々なフロントエンドの情報をキャッチアップできるポットキャストをお送りしております。
Guest
今回はですね、私、春とゲストとして、美ょさんと、あと、花倉さんをお呼びしております。
Guest
お2人よろしくお願い
Guest
しますよろしくお願いしま
Guest
よろしくお願いします。
2. ゲスト紹介
Guest
今回はとリコイルについてのまあテーマなんですけれども、まあ、今回え。お2人をお呼びした理由は、ステート管理ライアリー
Guest
について、まあ、あるえ、蔵司が深いお2人ということで、今回お詫びいたしました。
Guest
では、まずはくらさん自己紹介をお願いしてもよろしいでしょうか。はい
Guest
はい、じゃあ初めましての方は初めまして。ピクシブ株式会社、ブイレイドハブチームで、フロントエンドエンジニアとか。レイルスンジニアをやっている花倉と申します。
Guest
趣味ではまあ、お絵描きとかdjをしているんですが、
Guest
ちょっと前まで。ウェブ製の映像編集、ソフトデリールっていうものの研究開発をす。何か趣味でやってました。でま、その流れで。フラックス、フレームワークフルールっていう
Guest
やつですね。それを作ったりしてます。
Guest
で、あま、相棒はタイプスクリプト後、リアクトと後、アドビーラストレーターで好きなものは悪い顔のキャラクターです。はい、よろしくお願いします
Guest
よろしくお願いします
Guest
お願いします。
Guest
では、えとうひょさんは、。2回目の登場ではあるんですけども、ちょっと。まあ、期間が空いてしまったので、おふさんも自己紹介をお願いしたいと思います、
Guest
よろしくお願いします。
Guest
はい、では、初めましての方の初めましてうひょうと申します。
Guest
私は、ゲストと言いつつ、このLINE株式会社のフィナンシャル開発センターというところで、まあ、金融系のサービスのフロントエンドを担当しています。
Guest
今、仕事で使ってるのは、まあ、タイプ作る人とリアクトですね。まは、くらさんと同じということで、ま、結構タイプ作る人には興味があって
Guest
ま。キータなんかで、タイプスクリプトの記事、私が書いているのを、ご覧になったことがある方も多いんじゃないかと思います。まあ、最近はちょっとキータじゃなくて、個人の
Guest
ブログの方に記事を集中させようとしたりしているんですけれども、そんなことで、まあ、私をご存知の方もいるかもしれません。
Guest
あ、結構私自身はリアクトにも興味があって、例えば、リアクトのコンパレントモードとか、そういった方も、最近は積極的に調べています。
Guest
こんなところですかね、どうぞ、よろしくお願いします、
Guest
よろしくお願いしますお願いします。じゃあ、お2人ともタイプスリフトの強い方という認識で
Guest
まちょ。ちょっと怖いですね。強いって言っちゃう。ちょっと怖いんですが、はい、
Guest
詳しいということですね。はいちょいや、よろしくお願いし
Guest
しますよろしくお願いします
Guest
よろしくお願いします。
3. Recoil の概要
Guest
今回のテーマのリコイルについてなんですけれども、
Guest
まあ、まずリコイのまあ、内容っていうのはえ、先月ぐらいですかね。ちょうど1ヶ月前ぐらいにまあ公表されて、その当時は
Guest
バズった感じで。まあ、割とそのfacebookが作り始めた新しいステート管理ライアリーっていうことで、こうリラックと比較されつつ、
Guest
注目されたライブです。で、ま、そのけその内容については、
Guest
うさんが割ともう詳しく調べられていて、ログにもまとめられているっていうところです。
Guest
で、まずそのリコイルの振り返りっていうのをおさんにお願いしたいと思うんですけども、ちょっと軽くどんなものか説明してもらえますか。
Guest
はい、わかりました、リコ入りですね、本当に今からちょうど1ヶ月前くらいに出まして
Guest
ま。リコでどこが作ったかというと、まあ、facebookが作ったリアクト向けのステート管理、ライブラリーなわけですけれども、
Guest
確か、リアクトのヨーロッパの何かのカンファレンスで、最初発表されたんでしたっけね。
Guest
ああ、そうなるほど
Guest
ええ。それでは今facebookが出したってことで、ま。acebookは、リア友作ってる会社ですから、さすがにみんな驚いたんですけど、も
Guest
ま、実際にまリアクトの公式のステート管理ライブとか、そういう位置付けではないわけですね。
Guest
あくまで、facebookの何かのプロダクト開発のチームが、まあ、自分たちのために作った実験的なステート管理、ライブラリ
Guest
ということで、まあ公表されたということです。
Guest
はい、なるほど、
Guest
はい、それでま技術的にどういう特徴があるかというと、まあ先程例に挙げられたリラックスとかとま、大きな違いがあるわけではないんですよね。
Guest
というのも、ステート管理ライブラリって、大体、今、グローバルなステート管理が目的じゃないですか。
Guest
はい、そうです
Guest
あ、つまり、複数のまあ離れたところにあるコンポーネントでま同じステートを共有したい
Guest
で、そういうことをするときにま、親のコンポーネントでステトどんと持って、そっからプロプス、バケツリレーとか、あるいは、コンテキスト
Guest
でデータを渡すっていうことをすれば、まあできるんですけども。それだとまたくさんサイレンダリングが発生して、パフォーマンス的に問題がある
Guest
ので、もっと効率的にサイレンダリングを行いたいなっていうのが、いろんなステート管理ライブの動機だと思うんです。
Guest
はい、
Guest
それでですねま、リラックスとかあるいは今回のリコイルもま、それに対して
Guest
ま。リアクトのコンポーネントツリーとは、別のところにステートの親玉みたいなのを置いておいて、そこにコンポーネントが直接サブスクライブするという方式をとっています。
Guest
それでですね、例えば、リラックスと比較した時のリコールの大きな特徴っていうのは、まあ、親となるステートが1つにまとまってないってことだと思うんですよ。
Guest
リラックスの場合だと、たくさんリデューサーっていうのがあって、それをまとめて、1つのストアが上にこう。できると思うんですけど、
Guest
リコイルはそういうまおっきなストアっていうのがなくて、まちっちゃいこのステート。これ、リコイルではアトムっていうんですけど、
Guest
こういう後をたくさん並べておいて、コンポーネントがそこに直接サブスクライブするっていう特徴があります。
Guest
うん、うん、
Guest
またですね。アムを直接サブスクライブするだけじゃなくて、アトムから別の値を計算したりとか、あるいは複数のアトムの値をまとめるとか、
Guest
そういうことをできるセレクターっていう概念があって、ま、これもリダクスのセレクターとはちょっと違ってま。コンポーネントは、セレクターに対して、サブスクライブできる
Guest
という風になってます。
Guest
はいはいはい、
Guest
この辺りがリコールの特徴ですかね。あと、もう1つだけ言わせていただけるとすれば、APIが結構特徴的だなという風に思います。
Guest
というのもま、具体的な細かいAPIは、リコーデの公式ドキュメントとか、あるいは手前ミスですけど、私のブログ記事なんか読んでもらえればいいんですけれども、
Guest
結構リコイルのアムを使うというフックがあるんですけども、それが原始的なというか、まあ、ほとんどユーズステートと同じAPIで、
Guest
まあ、そのユーズセットと同じペアを使って、アトムをどうアップデートするか、使うコンポーネント側の自由ですよ。みたいな、
Guest
かなりま提供されるAPIとしては、原始的なものになってる、これが、リコイルのとても大きな特徴だと思います。
Guest
はいはい、
Guest
ありがとうございますあれですよね、あの、僕もそのブログム記事で読んだりとか。あと、あの社内でも1度リコルで勉強会
Guest
をしたんですけれども、ま、そこでも結構その原始的というか、ほんとにその基本的な機能
Guest
だけを提供しているっていうところがま注目されていてま
Guest
でも、そのユーズステートとも、ほんと非常によく似た使い方を。リコではできる、はいっていうところ
Guest
ですよね、ありがとうございます。なんか、そのりこえる、ぶっちゃけどんな感じでした。と見てみて、その使いたいどで言うとどんな感じですかね。
Guest
あ、私はあ、これ大好きって思いましたね。最初見た時にもうそれこそおっしゃってた。この原始的っていう点が非常に素晴らしいなと思って
Guest
というのも、はい、自分結構まあり物のステート管理ライブラリーっていうのがあんまり好きじゃなかったんですよ。
Guest
例えば、おりゃあそう。例えば、リラックスにしても、あのリデューサーはいいけど、このアクションとかいう概念いらないでしょみたいに思って、
Guest
はいはい、そうですね、
Guest
まあ、うん。リラックスを裏で使いつつ、アクションを隠蔽した俺をリステート会員ライブだね。みたいなの作ってたりしたんですけど、まあでもそういうことをするなら、リコイルでいいじゃんってリコイルを見てから思うようになりました。
Guest
はい、なるほど、そうそうですね、わかりますアクションは無駄ですね、いや、だいぶだいだいぶわかります
Guest
あ、確かにそうよくい
Guest
考えるとそりリラックスって、そのステートの管理するっていう機能と、アクション、そのアクションを提供するっていう2つ。まあ、おっきな機能があって、
Guest
で、リコイルはその中でも、そのステートの管理に絞ったスリムなライブがいいっていうところが特徴ですよね。
Guest
いや、もうなんかすごいこれでもうよくわかったこれでもう人にりこの説明ができます。それはよかった。
Guest
はい、
4. 実利用から作られた Fleur
Guest
リコイルの。まあ、内容っていうのはすごいよく分かったと思うんですけど、今回、あの花倉さんをお呼びした理由の1つが自己紹介でも述べられたと思うんですけども、フルードルという、ステート管理ライブやりを開発されているという
Guest
ところがあったりします。前情報によると、デリールと一緒に使うっていうことを。まあ元にして、そういう大規模なシングル、ペイデアプリケーションでもよく使えるような。まあ、フレームワークになっているっていう
Guest
か、えことを読みました。はい、じゃあ、まずちょっとフルールの特徴などがあれば、ちょっと聞きたいんですけど、はい、どんな特徴があったりしますか。
Guest
はい、そうですね、今、えーとはささんが言っていただいた通り、フルールは。デリールっていう何かまー、簡単に言うと、エアユテエとか、アフターエフェクとか。
Guest
ああいうタイプの映像編集ソフトを作る時に必要になって作ったえ、プレームワークですね。はい、
Guest
僕の勤めてるピクシブのブロイドハブでのリラックスの開発チケとか。
Guest
と、その他。フラキシブルを使ってるピクシブスケッチっていうプロダクトとか。はい、そういうところでの開発知見を何か僕が勝手にまとめてま。何かこれがあれば、大体のアプリケーションは作れるよねっていうのをまとめたのが、フルールっていうやつです。
Guest
はい、
Guest
そうですね、特徴的なところとしては、リラックスとかに比べて、タイプスクリプトがあることを前提に作られた。
Guest
フレームワークなので、高度の書き心地とか、型推論の当たり方とかは。リラックスよりも遥かに。めちゃくちゃいいです。
Guest
もうなんか素晴らしい
Guest
ついえいえつ。追加のライブラリとかなくても、なんか一通り。なんかリラックスでどうせみんなこれ突っ込むんでしょっていうやつが入ってて、なんかそ
Guest
ここら辺に対して、ちゃんと型推論も当たるし、なんか、型推論のために余計なコード書かなくていいっていうのは、1番大事にして
Guest
作ったところですね。はい、
Guest
あとは、そうですね、あの、reダックスっていうあまあリダックとかって呼ばれて、非常にあの口だと紛らしいんですけど、reダックっていう、
Guest
ディレクトリーの設計パターンとかを基本的に使ってくださいっていうことで、ドキュメントでもしていたりして、まあ、そうですね、なんか
Guest
ちなんか、中規模以上のアプリだったら、作るときに、なんか必要なものはもう全て揃ってるみたいな。
Guest
そうですね、設計パターンまで含めて大体入っているっていうのが、まあフルールのあの特徴です。とても使いやすい感じになっています
Guest
で、で、逆にちょっとフルールの弱いところとしては、小規模なアプリに対しては。リコイルとかモブxよりもちょっとあのこ
Guest
すごく。あの1個の処理に対して書かないといけないことが多いので、まあ、ちょっとそういう小回りがききづらいところは、ちょっと苦手ポイントではあります。はい、という感じですね、
Guest
あ、ありがとうございます。そうですね、結構そのデリールもあの、そのそれこそあアフターリを
Guest
作るっていう、すごい壮大なもう大規模なアプリケーションっていうところから生まれたっていうところ。そうなんですけれど、も、ま、それでも
Guest
ま結構そのほんとにその社内のそういう実理を
Guest
大規模な治療をけえ、元にしたアプリ。ライブっていうところはすごい心強いところかなと
Guest
ありがたいことに。あの、ピクシブコミックっていうサービスの一部ではなんだ。なんか、本番でフルールが使われているらしいという、なんかおうことです。
Guest
じゃあ、実際に使われて
Guest
はい、なんかね、確か、ネクストジェースと組み合わせた運用だった気がすしますね、ちょっとチーム外なんかでは、あまり詳しくないんですけど、
Guest
はいはい、なんかそんな感じで使っていただいているという話を聞いております。
Guest
いや、それはすごい心強いですね、フルールすごい軽くしかないんですけど、ちょっと見てみてまして。はい、あの
Guest
ストアにあの、今ジェスの採用して作ったっていう結構そのストアってすごい。なんか、ストア
Guest
管理ラリっていうぐらいなので、すごいコアなところではあるとは思うんですけれども、そこにこのマージsを採用ししたっていうのは、
Guest
あ、結構そのプールにあったものだったからですかね。
Guest
そうですね、一応フルールはリデューサーストアとクラススタイルストアっていう2つのスタイルのストアがあって、リデューサーストアではもう今ジ以外使わないでねみたいな感じで設計されていますね。
Guest
で、ま、今ジーを導入した理由としては、まあ、もうなんか
Guest
みつつうじゃんみたいな。なんか、イミダブルジェースがマジかで悩むのはもうなんかそういう時代じゃないし、なんか、
Guest
あのストアのその変更を加えるときに、なんかマージュースが入ってないがために、そのあのドットドットドットステートみたいなのをなんか書いて、コードを煩雑にするのもなんか
Guest
ち違うじゃんっていう。なんかうん、うん、うん、まあまあまあ使うでしょみたいな。読みでなんか入ってるっていう感じですね。
Guest
で、逆にあの、どうしてもそのマージと組み合わせると、都合が悪いシーンっていうのも、多少あってま何かす。それこそ、映像編集ソフトだと、なんか、そのエンジンのインスタンスを直接いじらないといけないとか、
Guest
なんか、3gsとかと組み合わせた時に、なんか3gsちょっとさんに持たせないと、
Guest
あの設計の都合が悪いんだよね。みたいなことがある場合には、なんかクラススタイルストアを使って、なんかマージsをえ
Guest
使わない。なんか、ステート管理もできるっていう感じですね。はい、
Guest
うん、うん、
Guest
そうですね、結構あれですね、僕もインタジーとマジならっていう、そういう結構
Guest
自宅になった時とかは、大体マsいいなっていう思ったりとか
Guest
する。まあ、そういうところにあの、なんていうんですかね。そのユーザーがこうき、あの決める必要のないもうあらかじめあのバンドルされてるっていう
Guest
というところは、もう結構あのあれですね。あの、こうわざわざユーザーが
Guest
それぞれ決める必要がないっていう。はい、メリットがありつつもま、ただそういうあのすごいあのカリカリの。そういう
Guest
要望みたいなのには、ちょっと答えづらかったっていうところがあったあとですかね。
Guest
か、カリカリの要望
Guest
カリカリ、あ、あのあれですか。いい言い方が悪いあの、すごいあの、
Guest
はいそ、そうですね、まあまあなんか結構
Guest
hululはライバイっていうより、結構フレームワーク人として作っているので。やっぱどうしてもなんか細かいアクション。なんか、細かい処理
Guest
がいっぱい増えてくると、ちょっと。なんか、やっぱ直接ステートをいじるとか、なんか、ユーズステートするとかよりはこりが
Guest
悪くなっちゃうよね。というのは、まあ、ちょっと健労性を考えるんだったら、まあ、ちょっと仕方ないかな、というとこで捨てているというとこですね。
Guest
うん、なるほど、なるほど、そうですね、あの、これあの完全に僕思いつきではあるんですけど、はい、あの
Guest
ステート管理の部分だけ、例えばリコールを使うみたいな。はいことっていうのはかの可能なんですかね。そもそも、
Guest
うんと多分フルールでは無理です。
Guest
ちょ、ちょっとあの、そうですね、というのも、リコイルは結構そのリアクトのフクがあるということを前提で作られているので。ですが。
Guest
そうですね、はい、確かに確かにフルあのフルールは、フルール単体だと、なんかリアクトであることには依存していなくて。
Guest
逆に、リコイルをバックエンドにしようとすると、リアクトであることを
Guest
前提とした。なんか、もうなんか、根っから書き換えないといけないので、結構フルールをそのままリコイルバックエンドにしようっていうのは、ちょっと
Guest
無理って感じですね。
Guest
あま、それはそうですね、よく考えたらはいまでもなかった
Guest
や、僕もやってみるまで分かんなかったので、
Guest
はい、そうですね、までもあれですかね。そのあのリコイルに限らず、そういう
Guest
リラックス的な、そういうシングル、あの1つのステートをこうなんてすかね。から、あの必要なところを取っていくみたいな考え方以外にも、こういう
Guest
あのはいまだえリコとかモブエみたいなこう、細かいやつを組み立てて、必要なステートをはい、組み立てるみたいな。はい、そういう
Guest
考えっていうのはま、結構あれですよね、その
Guest
そうですね、なんか結構使えるかもはい、使えると思います。ただ、それをフルールという名前でやることは多分ないですね。
Guest
ああ、はい、なんか別のライブラリで書くことはあるかもしれないです。
Guest
お、ほうほうほう、それは興味
Guest
まあ、ちょ、ちょっとまだ研究中なのであれなんですが。はい、そういう感じですね。
Guest
はい、お、お待ちいただけると、
Guest
今後はい、もし何かあったらはださいはい、やっていきましょうね。はいはいで、リコイル
5. Recoil 私ならこう使う
Guest
のあの話に戻りまして、リコイルは結構あの、その
Guest
説明でもあった通り、すごい電子的なAPIということでした。で、
Guest
あのまリアクトを使うこと前提っていう制約自体はまああるものの、それ以外のそういう提供する機能っていうのは、ほんとにシンプルで。
Guest
で、あの、ほんとにそのスケートの管理だけっていうところが特徴ですよね。はい、ではいということはすごい
Guest
あの拡張性みたいなのもあると私は思っていて、例えば。なんか、そのリコイルって、
Guest
アクションのあの方法みたいなのが全然考えられてなくて、ユーザーが考えない、考える必要がある
Guest
ところではあるんですよね。ま、逆に言うと、それはユーザーは何でも使ってもいいっていうところで、ま。例えば、そのリコイルを
Guest
こうリコイルをつか、直接使わずにリコイルをベースとした。なんか、もっとこう
Guest
メタライラ的な。そういうリラックスで言うと、リラックスサンクみたいな。そういうこう、リラリコイルの上に乗っかるような、そういう
Guest
ステート管理ライブやりみたいなのもま、今後あるかもしれないと思っているんですね。で、あ、そのライブやりには限らなくてもいいんですけども、
Guest
あの、もしよかったら、そのリコイルをもし今使うとしたら、
Guest
ま、どういうところにこう向いてるかとか、どういう使い方ができるかなっていうところをちょっとえ聞いてみたいなと思っております。
Guest
これ、あの、それぞれ3人にちょっと聞いてみたいと思うんですけど、もはい、私あ、じゃあ私からちょっと。
Guest
まあそうなリコイルをま使う使い道みたいなのっていうところの話は言うと、僕リコイルで、
Guest
最もあの足りないところは、そのアクションが全く、その
Guest
ユーザーの管理に委ねられているっていうところが、あの、まだ自由度があるなと思。
Guest
リコールでの説明で、ちょっとあの気づいたところで言うと、あのセレクセレクター
Guest
に、あの、そのゲッターゲッターというか、まあ、セレクターそのアムをまとめ上げるセレクターにそのゲットを宣言、できるだけではなくて、セットを宣言できるっていうところっていう説明があって、ま、そこ
Guest
結構その1つのそのセレクターに、そのゲットとセットが同居してるっていうところが結構あのな、混乱を招きそうなところかなとは
Guest
持っていて、はいでは、逆になんかその今だと、そのセレクターとか、アトムとかゲットしか考えられてないけれども、
Guest
例えばせセット専用のセレクターみたいなのを
Guest
新しくベッド作ってあげてま。そこを通してのみこう、ドラムを変更できるようにするみたいな。はい、形みたいな
Guest
使い方っていうのがすごいあのシンプルかなと思ってます。なんか、あんまりあの伝わ
Guest
てるかどうかちょっとわからないですけど、要するに、そのはい、セレクターが2種類あって、そのゲット専用のセレクターとセット専用のセレクターみたいなのを
Guest
を作ってみるのも面白いんじゃないかな。と。はいで、そのセット専用のセレクターがいわゆるアクションの代わりになるみたいな。
Guest
はい、なるほど
Guest
てい
Guest
わかります、わかります
Guest
いや、そこの説明で伝わってれば嬉しい結構そういうそのわざわざセットっていう
Guest
機能をセレクターにもつけたことは、なんか、どうせなら、使ってもみてもいいんじゃないかっていう。僕はそこのあの活用して、ま
Guest
あわよくば、それをこうラッピングしたライブラリーみたいのも、まああってもいいんじゃないかなと思いました。はい
Guest
っていうところですね。はい、じゃはくさんは、なんかリコイル使ってみようと思いましたか。
Guest
そもそも、ぶっちゃけ。イエスか農家で言えば、割とのよりって感じですね。
Guest
あ、一応ちょっと色々調べてはみたんですけど、結構ちょっと今のまんまだと、ユースケースが非常にちょっとせ
Guest
狭いや、あの、あれですね。ちょっと、僕の想像力が及んでいないっていうところもあるんですけど、
Guest
ちょ
Guest
とそうですね、リコイルを素で使うことは、まあまずないだろうな、という感じではありますね。たリコイルただつか、どうしても使いたくなるとしたら、なんかほんとになんか
Guest
でかい。なんか、サイトのほんとに1ページだけ
Guest
ほあ、マジで1ページだけのなんかページで、ただ、ちょっとそのページでなんか色々操作をしないといけない。なんか、複雑さがあってみたいな。
Guest
そうですね。な、なんかそれこそサービスのか、ちょっと複雑目の管理画面とか、なんか、そういうところでリラックス入れるほどじゃないけど、
Guest
なんか、ステート管理が欲しいなっていうシーンだったら、なんかリコイル使うのは全然ありだとは思っています。
Guest
なるほど、
Guest
うん、はい、そうですね、ゲットする時だけだったよな。足にちゃんとアシク使えるっていうのが、なんか非常にあのいいですね。
Guest
あの、リラックスとかだと、結構そのアシンカーウェイ
Guest
と、あの、非同期アクションって、なんか、リラックスサンクとか、リラックスサーガとか入れないと対応できなかったので、結構なんか
Guest
ちょっと気軽に使うには。あの、腰が重い感じだったんですけど、その点リコイルはなんかちゃんとゲットする時になんか
Guest
あ、非同期処理が使えるので。まあ、なんかAPIとか気軽に叩けるし、まあ、なんかそうですね。なんか、リラックスほどでもないけど、なんかとりあえず入れとくかっていうし、ではあり
Guest
という感じですね。で、そうですね、リコイルをライブラリン使うのはありだと思っていて、
Guest
で、1回ち。そのリコイルを調べるために、ちょっと軽くライブラリーを作ってみたんですけど、
Guest
まふるるっぽいやつですね。ま、フルルっぽいやつを作ってみたんですけど、セレクターをのゲット
Guest
ゲットでは、アトムにセットできないんですね。
Guest
こ、これがフル今のフルーのAPIと何何がえっ、
Guest
食い合わないかって言うと、フルールには。そのオペレーション層っていう。なんか、APIと非同期処理をして、アクションを起こしたりする層があるんですが、
Guest
はいはい、
Guest
そのセレクターのゲゲットをした時に、
Guest
アトムに対して状態の更新ができないので、APIから引っ張ってきたデータをローカルでキャッシュするみたいなことができないんですね。
Guest
ああ、なるほど、
Guest
うんはい。なので、多分そのフルールで言うと、このオペレーションは、多分セレセットセレクターを使っ
Guest
てやらないといけないんだけど、セットセレクターが、
Guest
プロ。プロ水をスローできたかどうかがちょっと覚えていなくて、うん、ちょっとそこら辺考えると、フルールの考え方のまんまでで、同じようなライブラリをつ
Guest
来るのは、ちょちょっとち。多分違うんだろうな、というところまではわかっているっていう感じですね。で、やっぱアントセレクターちょっとあの、
Guest
やっぱ個個人で管理すると、キーがめちゃくちゃになったり、そのセレクターからのセレクターへなんか依存したりとかが全然できてしまうので、
Guest
やっぱフレーム枠作るんだったらそうですね。そこらへん、なんかどういう単位で、アクションアクションとか、オペレーションするかとかは、
Guest
ちょっと考えていかないといけないかな、というところですね。
Guest
確かに、キーの管理が今、自分もものすごく悩ましいなと思ってるんですよ。特に大きくなればなるほど、これだけはい、管理したもんかって、
Guest
やっぱユニーク製の担保をしなきゃいけないわけですよね。キーを定義するときに、
Guest
そうですね、あれ、大変ですね、
Guest
いや、ものすごい大変だなと思っていて、やりこう。大好きになりましたけど、その点はどうにかならなかったのかなって正直思います。
Guest
うん、ま、あとはいえ、そこら辺は結構そうですね。なんかでかい
Guest
でかいアプリケーションの全態の状態管理をさせようと思うと、ネックになるんですけど、なんか、ちょっと複雑なコンポーネントを局所的に状態管理したいう上では。なんかまあ、そんなに問題ならないところはあって、
Guest
ちょっとそうですね、結構難しいんですよね。そのライブ
Guest
ライブラリーとか、フレームワークを作るにしても、でかいアプリをターゲットにするのか、その局所的な複雑さをターゲットにするのかによって、結構APIの設計
Guest
が変わってくる感じがあって、ほうほうで、名前でなんかでかい
Guest
アプリ向けに作るんだったら、名前、空間の管理とか、そのreダックパターンのディレクトリと、なんかその名前。キーの名前、空間を一致させて、なんか自動的に作るみたいなやつがある
Guest
手もあるんですけど、なんか小さい小さい、
Guest
なんか、梱包ね、局所的な複雑さとかに向けるんだったら、なんかキ適当でもいいじゃん。なんか、ssrするわけでもないし、みたいな
Guest
考え方もあるので、結構なんかま、そこら辺柔軟にしてくれたのはなんかいいところもあるし、悪いところあるし、なんとも言えねえっていう感じですね。
Guest
なるほど、なるほど
Guest
はい、そうですね、ちょっとキーの管理はまあでかいやつめけだったら、なんかちゃんとフレームワーク側で担保してあげたいやつですね。
Guest
ま、確かにこれはあのライブやりがそのメタライブやりが、管理する前提でのものかもしれない
Guest
そうですね。うん、
Guest
まあ、ちょ、ちょっとどういう設計しそうです。そうなったのかまでは、ちょっとあんまり詳しくはわからないんですけど、まあ、
Guest
ssrとか考え出すとそうですね。なんか、キーを勝手に付けてしまう
Guest
いうのは、結構でかい話になってしまうので、あのフックくらいなんか、呼び出し順序とかが決定的なら、なんかキーを自動的に作るみたいなことも多分できたと思うんですけど、結構その
Guest
アトムとかセレクターって、あの、普通にモジュールとしてインポートされたり、エクスポートされたりするんで、なんか自動的に決める方法がな。多分、
Guest
多分結構無茶しないと難しいんだろうな、というのはありますね。
Guest
ま、そうですね、シンプルさに寄せるんだったら、今の形が多分ベストなんだろうな。応用は応用はできるので、という感じですね。はい
Guest
はいはいあ、ありがとうございます。そうですよね、そうですね、キーをなんかそういうあの残す
Guest
キーをそのユーザーに書かせる理由みたいな。僕もちょっと気になってて、ま。そこを確かにそういうあの、
Guest
あのリコイルが中で持ってるっていうその勝手に作って持つっていう手段もあった中で、あえて、そういうキーを
Guest
ユーザーに欠かせるっていうのは、まあ、そういうシンプルさをと、まず、第1に優先した
Guest
ところかもしれない
Guest
そうですね。ちょっと神の味噌汁という感じなのですが、
Guest
はいままやりようはい、いくらかあるという感じですね。うんうん
Guest
やみささんなんか、あのアイアとかこんな使い方してみたいみたいなのあったりしますか。
Guest
あ、そうですね、私は今とてもこうなんか後を隠蔽することにすごい可能性を感じていて、
Guest
はい
Guest
っていうのもあっていうのは。まあ、実際にグローバルのステートが入ってる場所だったんですけど、
Guest
ま、リコールのAPI使うと、その後を直接サブスクライブしてま。コンポーネントが自由に読んだり、書いたりできてしまうと。
Guest
でも、社内でちょっと勉強会した時に、それって、複数人の開発の時が大変だよね、みたいな話が出ていたんですよね。
Guest
アトムそのものに、なんかロジックとか何も付随していなくて、完全に使う側に委ねられてしまっている
Guest
から、あっという間にカオスな状況になってしまうんじゃないか。なので、そこで、まあ、カスタムフックとうまく組み合わせれば、
Guest
うまくいくんじゃないかっていうのが、自分がちょっと思っていることで、
Guest
まあ、私が今考えている設計パターンは、こうアトムとまそのアトムを使うためのカスタムフックを同じモジュールに書いて、
Guest
カスタム服だけエクスポートします。みたいな、
Guest
そんな感じのま。これは、リコイルをラップして、別の生徒会員ライブラで使うとかいう話じゃなくて、ま割とリコイルを生で使うに近い話ですけど、も、
Guest
はい、
Guest
そういう風にも直接アトムを直でコンポーネンとか触るのやめて、全部カスタムフックで
Guest
触るようにすればいいんじゃないかな。ってのがちょっと思っているところで
Guest
は、い
Guest
ま、そうするとまユーザーからしたら、なんか便利なグローバルなステートを持ったカスタムフックがありますよ。みたいな感じのAPIに見えるわけですよね。
Guest
はい、
Guest
そうなんか、生の後も露出するんじゃなくて、全部カスタムフックを、まあ、グローバルなステートを持ったカスタムフックを作るための便利な手段として、なんかリコイルが
Guest
使えるんじゃないかなって、今はちょっと思っています。
Guest
なるほど、フックフックでアムをラップする。なるほど、なるほど、
Guest
これもすごいあれですよね。あ、あのリアクトフクらしい考え方っていうか、まさにリアクトク大活躍
Guest
そうですね、もう、リアクトフックといえば、カプセルか隠蔽が全てみたいな感じで思っているので。
Guest
はい、
Guest
そのカスタムフックのやり方に対して、まあ、グローバルなステートっていうピースを足してくれるのがリコレなのかなと。ちょっと思うところはあります。
Guest
うん、うん、うん、そうですね、あの、僕のさっき言ってた意見もまあか、勝手には
Guest
あの近いアイデアっていうのを持っていて、そういうステートを提供する側が、そのみに入るところを
Guest
自由に制御することができる。ええ、アトムをまそのまま出すこともできるけれども、むしろそれをこう
Guest
うまいことをラップして、うん、そういう
Guest
あのゲットゲットをラップしたものであったりとか、あと、僕のアイデアだと、そのセットをまあ、セレクターで通してのみ提供するみたいな。そういう
Guest
私だったら、そのセットの部分をカスタムフックを通して提供するかなみたいな、ちょっと思いました。
Guest
ああ、はいはいはいはい、
Guest
なんか生のこのアップデート関数は露出させないで、1増やす関数だけ露出するカスタムフックを通じてみたいな。
Guest
おははいすると、まあ絶対に位置ずつしか増えないステートがまあできるわけじゃないですか。
Guest
はい、
Guest
なんかそういう感じの、まあ、隠蔽っていうんですかね。みたいなことをやっていくのがいいんじゃないかなって、個人的には思ってますね。
Guest
そうですよね、結構え割とおそのほんとにリコ入りの素直な
Guest
活用方法みたいなそう。あの、
Guest
無理にそういうあの別ライバリーを用意するみたいな話ではなくて、ほんとにそのリコールの活用方法の1つっていう、すごいすごいデを使いそうな
Guest
そう感じのそう
Guest
なんすよ。すぐに電話っていうか、今つく担当しているプロダクトにちょっとリコイル入れてしまいました。すに
Guest
早いな、なるほど、
Guest
すごいや、プロダクション1番乗りを目指したいくらいですね。ほんとは、それはさすがに怪しいですけど、
Guest
いや、ご報告をお待ちしております。いや、ぜひ聞いてみたい。その話は
Guest
はい、うまくいけばぜひ
Guest
ぜひ、また後、ほどきお聞かせください。はい
Guest
はいはい、お待ちしております。もう、リラックスを1度入れてしまったプロダクトにリコールを差し込むとこはなかなかないので、
Guest
それは確かに
Guest
確かに
Guest
はいはい、そうですね。あと、リコイルはssr対応は個人的に気になってますね。なんかや、やる気はありそうというのはどこかで見たんですが、
Guest
そうですね、もうどうなんですか。
Guest
なんか、ネクストジュースと一緒に使ってみて、動いたって報告と動かなかったって報告が両方あってよくわかんないんですけど、
Guest
ああなるあな、なんか確か。まだ
Guest
エクスペリメンタルなAPIを叩いて、なんかステットを取るみたいな感じだった気がするので。あ、
Guest
ちょっとおよく覚えてないんですけど、なんかそうですねえ、ssr対応はまななんかできれば欲しいという感じはしますね。
Guest
そうですね、
Guest
うん、なんかうん、あのし、あのははからっていうか、あのaki見た見盛りだとそんなに対応難しくないかなっていう
Guest
感じはしたんですけど、なんか困難な点とかああったりするんですかね。
Guest
そうですね、
Guest
と、リコイルでssrをしようとすると、まずリアクトが。あの、これはリアクトサスペンスの問題なんですけど、え、
Guest
あ、すいません、これは、ネクストジェスとかじゃなくて、素。なんか、ssrをしようとしている時のケースです。
Guest
サスペンスの問題として、まあ、なんかあのレンダリングが完了したかどうかって確かまだちゃんとわかれなかったはずで、
Guest
なんかそう。サーバー上でAPIを叩いてサスペンスされたけど、リアクトドムレンダトストリングはなんか終わってるから返すねみたいな感じで、
Guest
なんかなっちゃうとかそういうことがあるんで。結構素リアクトを使っている場合だと、
Guest
リコイル。うん、そうですね。で、そのリコイルので生成された状態を。1回全部ジェイソン出して、あと、
Guest
クライアント側でまたその状態を復元するみたいな処理一連の処理ができないとそうあのサーバーサイドレンダリングの結構コアな部分では使えないっていう感じになりますね。
Guest
あ、そっかそうですね、あれですねあの、あのサーバーサイドレンダリング、レンダリングするところまでしか考えてなかった。それを、そっか、クライアントに
Guest
状態を送らないと。はい、それは確かにそうですね。うん、
Guest
そうですね、なんかそこらへんの。なんか、一連の流れがリコでできると、結構
Guest
結構なんか、ちゃんとした状態管理ライブラリーのとしては、なんか文句なしっていう感じになるかなという感じですね。
Guest
ま、ネクストそうですね、はい、ネクストとかを使ってると、ゲトシャルプロップスで全部終わっちゃうので。いやとはいえ、なんかその
Guest
ネクストジュースでも、なんかリコイルバックエンドにしようとすると、やっぱりそういうことはできないと。そうですね、という感じですね。
Guest
なるほど、
Guest
そうですね、じゃあまりこええと、ネクストに限らず、そういうサーバーサイドになり、その逆ト全般でサーバーサイドリンダリングの対応っていうのは、
Guest
まあ、あのまだそういうできたっていう報告とできなかったっていう報告があるのか。
Guest
そうなんですね、大変ですね、
Guest
まあまあまだで出たばかりのライブラインなので、これから
Guest
あ、そうですよ。そうですよ、そうですまた
Guest
まだ1ヶ月ですもんね、もう、みんなだいぶリコールの話しなくなってきたんで、1年くらい経ってたかと思いましたよ。
Guest
まあ、これからやってくれるとは思いますね。
Guest
え、あ、単純にあれですよねああ、あの新しく出たから飛びついてこう、新しい新しい物好き
Guest
が集まったっていう感じはしたけれども、実はちゃんとこう。あの、ほんとにそういうなんか、この
Guest
飛び道具的なライブラリではなくて、すごい今後の根幹をなす可能性のあるライブやりで、多分
Guest
なんかもっとあれですね。その話題、話題にはなってないっていうこと、あの、その話題
Guest
がなくなったって、はい、多分みんなこうちゃんと着々と実量は進むっていう雰囲気はしますね。でも、
Guest
そうですね、はい、個人的にもリコール大好きになったので、ちゃんとプロダクション実績とか作っていきたいなとは思ってます。
Guest
そうですね、じく実際に使って出していきたい。
Guest
そうですね、調子悪い
Guest
ありますはい、そうですねふ、フルールもなんか結構フルールもそうですね、結構ちょっと
Guest
APIがまだリアクトサスペンス向きじゃなかったりとか、古臭いところあるんで、なんか、リコイルをうまく取り入れて、なんかいい感じのライブライとか、フレーマークとか作れるんだったら、あのやっていきたいなっていう気持ちはあります。
Guest
うん、ぜひぜひ楽しみにしております。はい、では、何か他に話したいこととかはありますかね。
Guest
あ、そういえば、なんかうひょさんが、リコイルで副作用をどうしようみたいな話をしていたのがちょっと気になっているのですが、
Guest
はい、
Guest
なんかどどうですど、どうですっていうのもあれなんですけど、なんか、そのAPIの通信とか、もう、なんか、普通にセレクターで頑張ってやっちゃっていいみたいな
Guest
感じですかね。
Guest
ああまあ、通信の結果がプロミスとしてきたときに、
Guest
まあ、それをリコイルのま非同期サポートに載せるのはま、とてもありだなと思います。ま、これから、リアクトのコンパレントモードとかも出てくる中で、
Guest
はい、例えば、APIを叩くところとか、個人的には無理にセレクターのセットを噛ませるとか、そういうことまではしなくていいかな。
Guest
まあ、適当に別に叩けばいいんじゃないかなとは思いますね。
Guest
はあ、なるほど、別別に叩くっていうのは、なんかその
Guest
例えば、そのコンポーネントの中で、なんだろう。このイベントハントラーの
Guest
中で、なんかAPIを呼んで、その結果をなんかセレクターのセットとかに載せるみたいな、そういう感じにすればいいみたいな感じですかね。
Guest
もうそうっすね、例えば、ちょっとま、実際に試して言ってるわけじゃないんですけど、
Guest
あ、それこそコンカレントモール念頭に置くならまあAPI叩きますプロミスをもらいます
Guest
プロミスをまともにツッコミますくらいがま。多分1番単純な形かなと思っていて、多分もしかして、それくらいでもいけるんじゃないかなとは
Guest
ちょっと思うんです。
Guest
はい、なるほど、なるほど、はい、わかりました、ありがとうございますなんか考えます、
Guest
ちょっと私もまだちゃんと考えたわけじゃないので、そこはぜひ色々研究していきたいところではありますね。
Guest
そうですね、やっていきたいですね、
Guest
はい、コイル本体は副作用がどうのとか、多分まだ全然行っていないので、はい、研究する余地は多分とてもあるところなんだと思います。
Guest
はい、
Guest
ありがとうございますえ、というわけでえ、今回はリコルをテーマに2人にお話を伺いました。
6. クロージング
Guest
私達UITのメンバーが所属するえ、LINE株式会社では、え、このようなフロントイングに関する議論を行っております。
Guest
こ、こういった感じのリコイルのテーマというところとかは。まあ、社内勉強会でも、まあえ
Guest
え話した成果でもあります。今後もあいてにされては。このような感じで、社内社、外問わずどんどん情報を発信していきたいと思います。
Guest
またえ、twitterでのハッシュタグはシャープUIT INSIDE、エピソードのご意見やご感想、リクエストなど、ぜひぜひご気軽にツイートしてください。
Guest
それでは、2人はくらさん、えおさん、ありがとうございました、
Guest
ありがとうございました、
Guest
ありがとうございました。
