ep.123『Recoil Relayの登場とState managementからData-flow graphへの進化』 | UIT INSIDE

2022/06/17 に公開4777 views

このエピソードについて

Recoil から最近登場したライブラリ recoil-relay とライブラリ公開の真意について、@spring-raining と @uhyo が話しました。

Recoilについて

ep.49 ReThink state managements - Recoil から見える未来 https://uit-inside.linecorp.com/episode/49

recoil-relayでできること

リリースブログ: https://recoiljs.org/blog/2022/06/02/recoil-relay-0.1.0-release
Recoilと統合されたGraphQLクライアント
- GraphQLのクライアントとしてはApolloが有名だが、Meta公式はRelayというライブラリを提供している
spring-raining: recoil-relay自体は小さなライブラリで、コードリーディングをすると色々と発見があった

recoil-relayのAPIの特徴

1つのqueryやmutationがRecoilでいうselectorとなり、selectorを通してアクセスすることで裏にGraphQLがあることを意識せずに扱える
- 内部的には、selectorに対応するatom familyが作られてそれにatom effectsを設定する形でreactivityを実現している
queryとmutationを別々のselector以外にも、queryとmutationをペアにしてwritable selectorにすることもできる。このselectorを更新すると、ローカルのキャッシュも更新される
Recoilの特徴でもあるselector内での非同期処理を活用している

Recoilを他のライブラリと組み合わせる可能性

同じMeta社によるライブラリのRelayと組み合わせられられているが、他にもいろいろなライブラリと組み合わせて使うことができそう
Data fetching系のライブラリとの統合
- ライブラリ間とのコミュニケーションとしての役割
- State managementからData-flow graphへ
atom effectの登場

Recoilの登場以降の動向

Recoilは意外と歴史が長く、登場から2年が経った
これまでの主なアップデート
- v0.1.1 Atom effects
- v0.4 Transactions
- v0.6 Concurrent rendering/transitionのサポート

Refs

LINE 新卒採用 2023
- https://linecorp.com/ja/career/newgrads/engineering/
キャリア採用はこちらから
- https://linecorp.com/ja/career/position/475
BGM&SE
- 魔王魂/騒音のない世界/OtoLogic

採用について

使用素材・クレジット

BGM&SE

音声書き起こし

1. オープニング 00:00

@spring_raining 00:04
こんにちは、UITの玉田です。毎週、フロントエンドの情報を発信して、キャスト UIT INSIDE、今回も始めたいと思います。今回はですね、リコイルリレーを前日発表されたものですね、それについて、ちょっと取り上げていこうと思います。ではえ、よろしくお願いします

@uhyo_ 00:25
よろしくお願いします。

2. Recoilについて 00:32

@spring_raining 00:33
はいでえ、今回取り上げるリコイルリレーというライブなんですけれども。まあ、以前以前と言ってももう結構前なんですけれどもえ、リコイルというライブラリを取り上げたこと置いてるでしょうか。ま、それを組み合わせるというか、聞こえると一緒に動く。ライブやりがえ、リコイルの公式から出たという

@spring_raining 00:55
ことで、まあ結構出てから色々ありましたし、今回そのリコイル自体についても、ちょっと振り返ってみようかなという趣旨なんですけれども。そうですね、じゃあ、聞こえるについて軽く振り返りますか。はい、そうですね、あの、確か第49回ですね。

@spring_raining 01:19
UIT INSIDEではえ、出来たてほやほやのリコールについて取り上げたんですけれども、結構業務とかでは使われてますか。

@uhyo_ 01:29
はい、私が担当しているLINE証券というプロダクトではですね。もう、リコイルが0.0.いくつとか、そういうバージョンの時からもうプロダクションに投入していて、プロダクション利用はかなり早い。もう、日本だと、多分1桁とか事例がそれくらいの時からもう使っていると思います。

@spring_raining 01:47
そうですね、もう出た当初からかなり注目してましたよね。

@uhyo_ 01:52
そうですね、自分的にはもう最初見た時からあ、このAPIいいなと思って結構愛用するようになりましたね。

@spring_raining 02:00
そうですよね、あのま、リコイルのなんて言うんすか。詳細とかについては、エピソード49をあの、もうかなりまとまってるので、聞いてもらうとして、これが出てから、実はもう2年ぐらい経ってるんですよね。そうです、あの、そうですよね、何かこう使っていく上でよかった点とかあったりしますか。

@uhyo_ 02:25
そうですね、やっぱり、リコイルのAPIってのが、すごくローレベルな感じがするんですよね。つまり、はいはいはい、ベースとなるAPIが提供されていて、それを組み合わせて、自分なりのステート管理ができるっていう、それがリコの結構強いところかなと思ってましてまで、私みたいに結構あれ、これと設計するのが好きな人にとっては。

@uhyo_ 02:49
まあ、ステート管理をこう支給に収めるみたいな感じで、かなり使い勝手がいいかなという風に思っています。

@uhyo_ 02:59
その分だけなんか、まあ、ロレベルのAPIなもんだから、なんか変な使い方をしてしまうと、まあ、いわゆるステート管理の秩序っていうのがですね。なくなってしまうとか、そういう危険性も秘めている。ライブラリではあるので、まあ、うまく設計を工夫しながら注意して使っていくといいんじゃないかな、という風に思ってます。うちのプロダクトでも、今だから、リコールの設計っていうのは、結構頑張ってるところですね。

@spring_raining 03:24
おお、いいですね、結構そうですね、出た当初はまだまだリラックスをバリバリ使ってる感じだったと思うので、結構割と自由度が高いのっていうところの不安みたいなのが出た。当初はあったかと思うんですけど。うんけど、まあなんやかんやであれですよね、ちゃんと使われていますよね。

@uhyo_ 03:46
うん、そうですね、2年も経ったっていうことで、結構みんなそれぞれのベストプラクティスっていうんですかね。そういうのができてきたんじゃないかな、という風にはちょっと思ってます。

@spring_raining 03:57
じゃあ、まあそこのなんて言うんすか。リコイルのデストプラクティスとかについては、後半で詳しく聞いてみたいなというところです。はい、では、リコイルリレー事態について取り上げますね。リコリレーなんですけれども、まずまリレーってなんですか。っていう話なんですけれども、リレーというのはあれですね。いわゆるgrfquelクライアント

3. recoil-relayでできること 04:07

@spring_raining 04:25
になります。で、結構あのグラフキューベルクライアントで言うと、例えばポロクライアントみたいなのが有名かなと思うんですけれどもあれですね。メタャ的にはやっぱりリエというえ、ライブラリをえ押していて、まそのリレーのライブラリをリコイルのステートマネジメントに統合するためのライブラリという位置付けです。はい、そうですよね、あの、私自身は

@spring_raining 04:54
リレー全然使ったことなくても、あの大変申し訳ないんですけど、あの、これ出てからリレーのエピアについて調べました。ま、ただ、リリースブログリリース記事に書いてある分に関しては、もう全然あれですね。違和感なく読めるというか、そんなにアプロと大差ない感じはありますね。なるほど、

@spring_raining 05:18
多分その何て言うんすかね。リレイ自体について話すというよりは、あのリコルと組み合わせる方法とかにフォーカスした方がいいかなっていう気がするので。まあ、その点で見ていくと、ラ自体はすごくコンパクトなんですね。うん、うん、どれぐらいですかね。分量的には、ファイルも確か5つつぐらいで、それも数100行前後ましかもかなり

@spring_raining 05:47
コメントとかが充実してたので、割と読みやすいかなという印象を受けました。結構なんですかね、こういう割と自由度が高いっていうのが、まあ、メリットでもあるんですけれども、どうすればいいのかわからないっていう面では、まあ、結構難しいところでもあるので、自分でこうベストプラクティクス見つけるっていうところ、

@spring_raining 06:14
もうまあ、なかなか難しいという方にとっては、割とリレー自体というよりは、そのリコイルの実装設計の参考になりそうだなっていう感じを受けました。

@uhyo_ 06:28
あ、なるほど、リコリレーをコードリンリングすることによっては、リコ入れて、こういう風に使えばいいのかとか、そういった方面の学びも得られそうな感じなんですか。

@spring_raining 06:40
そうそうそう、ほんとにあの割とあのなどどういった感じで、そのアトムとか、セレクターとか使えればいいのか、みたいな、そういったところがすごい個人的にはめちゃくちゃ参考になりました。

@uhyo_ 06:54
なるほど、あ、じゃあ結構自分すいません。コードまでは読んでないんですけど、なんか、リコルに深くインテグレートしているというよりは、リコールのAPIの上に載せられるような感じで提供されている

@spring_raining 07:06
そうです。まさしく、そうなんですよ、

@spring_raining 07:09
もちろん、なんて言うんですかね。このリコイリリリーを出すために、リコール自体にペアを追加したみたいな事例も、もしかしたらあるかもしれないんですけども、ドキュメントに書いてないapを使ってるとか、そういったことは全然ないです。

@uhyo_ 07:22
なるほど、それは本当にまリコイルをまどうやって使っていくかを考える。すごい参考になりそうですね。

@spring_raining 07:29
いや、そうなんですよ、まじゃ、具体的にどういったAPIが使えるかっていうところについて。あの、まあ、私なりに調べた点で見ますと、基本となるものは、セレクターになりますね。その聞こえるって、そのアトムとセレクターがあると思うんですけれども、そのグラフケールの

4. recoil-relayのAPIの特徴 07:33

@spring_raining 07:52
1つのクエリーを宣言することで、ま、そのクエリーに対するセレクターが1つできるみたいな感じですね。で、そのクレディーのまあ、呼び出し、結果がまセレクターに含まれるみたいな感じです。で、割と説明が合ってるのか

@spring_raining 08:12
怪しいんですけれども、セレクターってなんていうんですかね。何か、他のアトムを参照した結果を返すみたいな説明はされることが多いんですけども、これに関しては、あのセレクターの中にアファミリーで動的に作られるアトムの結果を返すみたいなライブ的にはなっていて、で、まあ、そのアトムってどこからから変えないといけないっていうところはあるんですけども、そのアトムファミリー

@spring_raining 08:40
に対してアトムフェクツですね。あ、それを設定して、まあ、例えばグラフェルのサブスクリプションみたいなのを機能をつけるみたいな。ざっくり言うと、そんな感じかなという、

@uhyo_ 08:53
なるほど、なるほど、

@spring_raining 08:55
ところですね。

@uhyo_ 08:56
はい、そう。リコールって、アントセレクターっていうのがあるんですよね。まあ、どっちもそう。このサブスクライをして、中から状態みたいなものを取り出せるのは変わらないんだけど。あとは、自分で内部の状態を持っていて、セレクターはなんかよそからよ、その頭とかから計算して取ってくるみたいな。そういう区別なんですかね。そしたら、

@spring_raining 09:17
そうですね、なんで割とあの、最初リコ入れって、そういう最初にアトムを宣言してま、それをなんかこういい感じ。セレクターで抽象化して返すみたいなイメージであってて、ま。それはそれで正しい面なんですけれども、結構こういったなんてすかね。アトムファミリーで、しかも外から参照できない。そのセレクター

@spring_raining 09:44
を呼び出して、初めて、あとファミリーを作るみたいな使い方もできるんだなっていう割とそういった使い方もできるんだっていうなる。なるほど、見がありました。

@uhyo_ 09:53
確かにニコ用を使ってして、でも、あんまりアトファミリーとか、頭にフェクトとか、その辺までがっつり使ってる人はなかなかいないかもしれないですね。そうですよね、ま、そういったところのえ、実装例を示してくれるのは助かるし、あと、あれですね。まあ、自分でそういった複雑なとこ触らなくても、そこがまあ、ライブラリとしてラップされているってのは、そのそれで嬉しさを感じます。

@spring_raining 10:15
あ、確かに確かにうん、そうなんですよね、ほんとに外から見る分には後も1つも出てこないんで。うん、うん、ここはうまくラップされてるんだなっていうとこです。はい、

@uhyo_ 10:27
確かにリコイル本体でも、なんかセレクターが機動機処理をして、どっかからデータを取ってくるみたいな。そういうサンプルもあった気がするんですよね。あ、そうですね、これは結構このえ、リコイルリレーで作られるセレクターっていうのも類似してるな、という風に思いました。リコイル的には、こういうふうに、セレクターを単なる変換機としてじゃなくて、こうひとりとかも交えたある種の、まあ、もとは違うデータソースとして活用していこうみたいな、そういう思惑もきっとあるんでしょうね、

@spring_raining 10:54
確かに確かにそうですよね、前回リコールについて取り上げた時もなんか話した気がするんですけども、そのセレクターがひきが特徴というか、うまく使ってくるみたいな設計を感じますね。

@uhyo_ 11:07
そうですね、個人的にはまだそこまでセフを完璧に使いこなせてるわけじゃなくて、今後もちょっと色々やってみたいなと思ってるところではあるんですけど、

@spring_raining 11:17
そうですね。いや、もう是非設計した結果を共有してもらえるとね、みんな幸せになると思います。で、そうですね、もう1つ気づきの点で言うと、以前その取り上げた時に、そのセレクターに書き込めるみたいなセレクターがそのなんていうんですか。読み取り専用だけじゃなくて、セット方面

@spring_raining 11:40
にもあの設定できるみたいな話をしたんですけれども、リコレもセレクターにスッターを設定する使い方を活用していて、なんでリコレのグラフキューセレクターっていうAPIで作られたセレクターには、その書き込み方向のあの編集もapも用意されてて、うんま、それがそのままグラqlでいうニューテーションのま、処理が走るみたいな。

@uhyo_ 12:06
なるほど、

@spring_raining 12:07
そのグラフケールって、その書き込みのAPIを呼び出した時に、そのサーバーサイドというか、そのAPIの本当を待たずに、そのキャッシュを更新するっていう機能があるんですけども、キャッシュ機能も、まあ、そのセレクターの中でやってくれるみたいな。結構アポロだと、割と手で気がちなところとかもうまいことやってて、ま。これはま。どちらかというと、リレーの機能かもしれないんですけども、こういった

@spring_raining 12:36
り、このイェの活用の仕方があるんだなっていう。

@uhyo_ 12:39
なるほど、なかなか直感的で面白いですね。それも

@spring_raining 12:44
そうなんですよ、やっぱあれですねぎりのピア設計した人、こういったことを考えて作ったんだなっていう。

@uhyo_ 12:51
きっとそうでしょうね。あり、セレクターに対してセト可能にしたってのは、多分この辺の用まで見据えてますよね。きっと、

@spring_raining 13:00
うん、そうなんでしょうね、うん、結構まリレーのライブを使ってます。っていう方、あんまりいないからっていう気はするんですけど、も、ま、ただ今回あの話したような内容って、全然特にリレーとは関係なくて、他の

5. Recoilを他のライブラリと組み合わせる可能性 13:05

@spring_raining 13:21
ライアリ。例えば、まあ、そのグラフのアポロクライアントとかと組み合わせたりとか、他のなんて言うか、まあ、フェッチ系のライアリーと組み合わせられる感覚をいけたんですね。うん、うん、あの結構まあ割とそこ悩みポイントではあると思うので、ま、例えば、あの、もし業務でなんて言うんすかね。このリコイル単体じゃだけじゃなくて、何かと組み合わせて使ってますか。あったりする場合、

@spring_raining 13:49
どういったライブライトを組み合わせると、面白そうだったりしますかね。

@uhyo_ 13:54
そうですね、まあ、とりあえずリレーが行けるんだから、他のデータフェッチングライブも大体行けるかなっていう風には思っていまして、例えば結構これってなんでしょう。あ、このライブラリカのコミュニケーションっていうんですか。そこに、まあ、リコイルの気候のリコイルの、まあ、データグラフっていうんですかね。ま、あれを

@uhyo_ 14:20
使えるようにしようっていう方向性が打ち出されたのが結構大きいかなと思ってまして。実は自分このリコルレが出た時に、あやった予言当たったって思ったんですよ。おおはい、どういうことかというと、まさに以前のUIT INSIDEの何かの会かは、倉さんと一緒に撮った会だった。

@spring_raining 14:41
はい、そうですね。で、

@uhyo_ 14:42
なんかなんかリコールになんかデータフェッチングライブのデータ載せたらいいんじゃない。って確か言った気がするんですよね。

@spring_raining 14:49
あ、はい、まさしく覚えてたりしますなんかあれですえ、いや、ただあれですね、その小の度にも書いてありますね。臭いようですね、はいはいはい、多分そんな話をしたような

@uhyo_ 15:05
そうだから、ほんとになんかその通りの方向にコリコイルが進んでいくって、ああ、自分の考えたこと間違ってなかったなという風に思って、ちょっと嬉しかったところではあるんですけど。というのも、このリコイルの上にこのリレーとか、そういったもののデータが乗るっていうことは、なんて言うんでしょう。ライブラリカのコミュニケーションですね。そこをスムーズにしてくれる可能性があると思ってます。というのも、

@uhyo_ 15:35
最近のリアクト向けのAPIって、なんだかんだで、全部腹クじゃないですか。はい、そうすると、まその腹空からなんか供給されるデータって応募にして、服のカルがあったりするんですよね。で、そうですね、まあ、それを。まあ、例えばライブラビカを連携させたかったら、その服の帰りを別のライブの引きすることとか、そういうことも結構やってると思うんですけど、

@uhyo_ 15:59
前々からこれがあんまり効率的じゃないなっていう風に思ってまして。で、服の帰りっていうことは、コンポーネントがサイレンダリングされないと、その新しい帰りが手に入らないんですよね。あの、本来必要ないのに、ライブラリカのコミュニケーションのためだけに、コンポーネントが余計にサイレンダリング

@uhyo_ 16:19
させられちゃう必要があるんじゃないかっていう風なあ。そんなことを考えていて、だから、フックの会じゃなくて、リコールにそのデータを載せることによって、なんか、コンポーネントのサイレンダリングを返さずに、ライブラリカのコミュニケーションができるんじゃないか。みたいなことをそう確か前言ったんですよ。で、リコイルリレーって、まさにその方向性なんですよね。多分、リレーも私も正直あんまりAPI知らないんですけど、多分、福から

@uhyo_ 16:45
そのクエリのデータ入ってきたりすると思うんですけど、それがじゃなくて、マリコの上に乗っているから、それをまコンポーネントに実際に繋げるところはま、ユーザーが自分でやるし、もしかしたらコンポーネントに繋げるんじゃなくて、そのグラフィクルセレクターのデータを他のセレクターにまつげてもいいかもしれないま、そういう風に1つなんか拡張したというか、

@uhyo_ 17:09
活用可能性を増やしたっていう。そこに理解のま意義っていうんですかね。そういう方向性を示したことが大きいんじゃないかなと思ってまして。だから、他のライブライト組み合わせる可能性っていうとこに話を思います。と、とりあえず、これからもリコのデータグラフに対して、データを供給するライブはまあたくさん出せると思います。

@uhyo_ 17:29
リコルもそうだし、他のデータ、フェッチングライブもまあ、そうですね。なので、そのデータを活用する先がま、コンポネントにレナリングするんじゃなくて、他のライブで入力する、つまり、リコイルからデータを受け取ってないかするようなライブラリーっていうのも、このリコレエコシステムじゃないですけど、ここに組み込むことができるんじゃないかな、という風に思ってます。

@spring_raining 17:51
確かにそっかあれですよ。私、あの取ってくるところしか考えてなかったんですけど、そうですよね、確かによく考えたら、そこからなんか派生する。副作用とか、なんか、別のステートとかが完全にそのフックから独立するっていう。うん

@spring_raining 18:12
ところはうん、そうですよね、まあ、ある意味あのリラックス時代にはできていた。まあ、結構割とぐちゃぐちゃになりがちなんですけども。そうですね、そこがフックのみのに依存したステートだと、できてなかったっていうところは

@spring_raining 18:35
そこはできますね。結構やまこれもあれですね、割とつか独創性というか、利用者のアイデアが問われるところでもあるんですけれども。

@uhyo_ 18:46
そうですね。うん、私が思うに。このリコイルは、なんか、リアクトのコンポネントツの外に、なんか、新しい英語システムを作ろうとしてるんじゃないかっていう風な思いがありまして、さっきもちょっと話に出てきた後のエフェクトっていうのもありまして、

@uhyo_ 19:01
これって、要するに、リアクトのユ説、フェクトのアム版みたいな理解で大体合ってるかなと思うんですけど、このの遊説フクトっていうのがフックだから、まあ、コンポーネントに縛られていたんですけど、あのエフェクトは後に対してアタッチされるから、まあ、コンポネントツリーには直接関わりないま、コンポーネントツリーの外に配置されたものになってるんですよね。だから、コンポーネントツリーのライフサイクルから独立して

@uhyo_ 19:29
そう。まさにリコイルリレーのリストに使えたりとか、そういうことができてるので。なんか、どうしてもリアクトのナムのapaを使うと、まリアクトのコンポネントツリーの中の話しかできなかったんですけど、リコイルがか、こういう。まあ、アのエフェクトとか、そういうエコシステムを作ることによって、もう少しコンプレート数に縛られない自由度の高い

@uhyo_ 19:54
ま、コシステムになったんじゃないかな、というのが、このリコリの登場を見て思いましたね。

@spring_raining 19:59
そうですね、まさしく、そういうなんか新しい世界ができたみたいな、うんうんところはありますよね。もう、なんか、もう1つ、そのステートのステートツリーとでも言うんですかね。なんか、そういったのは

@uhyo_ 20:12
そうですね、リコで言うと、なんかよくデータグラフとか言われてますね。そうあ、はいはいはいはいあ、あれですね、もうリコイルはなんかステート管理ライブなら、脱却してなんて言うんでしょう。データフローライブラリじゃないですけど、ま、データの流れをつかされるような、そういうライブラリになったのかもしれないな、という風に思いました。

@uhyo_ 20:35
自分、たまによく、なんか、リラックスのリデューサーだけが欲しいなんて言ったりするんですけど、リラックスのなんか、アクションとかデスパシとか、あの辺は結構良かったと思ってるので、なんか、あの辺だけうまく抜き出したようなものが何か欲しいなって思ったんですけど、多分、このリコイルのデータグラフがそれになる可能性も結構あるかなっていう風に思ってましても、なんかリコイルで単なるステート管理じゃなくて、こうデータの

@uhyo_ 21:01
流れって言うんですかね。そこを管理できるようにすると、なんというか、リコイルの活用の幅が広がるというか、もっと色々できそうだな、という風に思いました。

参加者 3 21:12
なるほど、

@spring_raining 21:13
そうですね、あの、やっぱりtはアトムエフェクですよね。なんか、それができたことによって、その単なるステートだけだったステートの管理だけだったものが、アクション的な、そういうま、色んなデータの副作用も含めた処理の流れ。

参加者 3 21:37
うん、そうですね、できてきた

@uhyo_ 21:39
このアイフェクトが入ったのも結構早いんですね、段階が0.1.1ですか。

@spring_raining 21:47
あ、そうですね、はい、

@uhyo_ 21:48
意外と早い段階からもリコールにこのまとめる人が導入されていてたので、多分、リコはそういった方向性を最初から考えていたんですよね。

@uhyo_ 22:00
そうだから、リコの作者はなかなかやる気だなというか、なんか未来が見えてるなという風に思いました。

@spring_raining 22:07
すごいですよね、ほんとに

@uhyo_ 22:09
あ、こういうライブラリー作れるようになりたいですね。

@spring_raining 22:11
うん、まさしく、実装が後でこういう設計になるんだっていうのが、絶対もう既に考えがあったっていう感じですよね。

@uhyo_ 22:21
いや、そうだと思いますね、これはあまりにうまくできてるというか、こういうまあ、リコールシステムっていうんですかね。これになんかもうちょっと色々やっていきたいし、盛り上げたいなと個人的には思ってますね。何か面白い活用を考えてみたいところです。

@spring_raining 22:39
いや、そうですよね、うん、これも前回の話もあったかもしれない。そのリコイルベースの1個ィストみたいな、うん、うん。そういった活用方法を考えるみたいなところから、

参加者 3 22:54
そう

@spring_raining 22:55
提示されていますね。うん、

@uhyo_ 22:57
そうですね、結構絶対に色々応用はできると思うので、かなり夢があるなと思いました。

@uhyo_ 23:05
イコールリレーによって、その方向性っていうんですかね。これがかなり明確に示されたのが、個人的にはなんか良かったというか、ある意味転換点になったんじゃないかな、という風には思います。

@spring_raining 23:17
結構あれですよね、色々その独創性を問われるところではあるので、リコリレーという、ほんとにこれはもうある意味サンプルコードみたいな。

@uhyo_ 23:28
そうですね、これは

@spring_raining 23:30
あるので。

@uhyo_ 23:32
いや、お前らリコイルをこういう風に使ってくれよっていう。まあ、メッセージですね。きっと

@spring_raining 23:36
うん、いや、なかなかほんとにどういう活用方法があるかっていうのは、多分今が1番入りやすいというか、こうもしなんていうんですかね。リコールにをベースとした何かのりをossを公開したいみたいなところがあれば、多分今がかなりいいですし、

@spring_raining 23:58
こうリコルリレーが出たことで、多分みんなこういう活用方法があるんだみたいな。リコイルがま。再評価というか、評価が高まってる時期だと思うので、もう

@uhyo_ 24:10
そうですね、これを聞いた読者の方もあ、そうなのかと思ってもらってよかったら、もし、なんかリコールを使って何か作ってみていただきたいですね。あ、私もなんか考えてみようと思います

@spring_raining 24:22
ぜひ、私もなんかあれですね、他の人の設計を見たいですね。うん、うん、うん、いろんな答えが出てきそうな気がします。

@uhyo_ 24:32
そうですね、ちょっと思ったのが、リアクトのステートは、なんか何種類かあるみたいな記事は以前ありましたね。そうしか、UITサでも出ていたよしこさんが書いた記事だったか。はい、あって、これなんか従来。ステートカライブに載ってるソートデータフェッチングライバーのキャッシュに乗ってるソが、なんか別々に存在しているみたいな話だったと思うんですけど、

@uhyo_ 24:57
あ、それもこのリクリレーの登場によって、ある意味なんか統合されたというか、統一された感じがするんですよね。うん、うん、なので、まそのあたりになんて言うんでしょう。大統一理論じゃないですけど、そういったことも、多分、リコイルのエコシステムを使えば、持ち込むことができるはずで、個人的にはその辺にもちょっと興味がありますね。

@spring_raining 25:19
はいはいはい、まさしく、コンポーネントツリーからステートが脱却して、データフローの中に組み込まれるみたいな。うん、うん。いや、そういう発展の仕方がすごい見てみたいですね。うん、あの、まあちょっと脱線するんですけれども、まあ結構その2年前に出たっていう話も

6. Recoilの登場以降の動向 25:33

@spring_raining 25:40
あった通り、結構まリコイルって色々と変わってきてるなっていう話を最後にしてみようかなと思ってました。結構私もそうだったんですけど、当初は実務で使うのに不安を感じていたみたいな方も結構いらっしゃるのかなと思っててま。そういったところに対してこうなんて言うんすかね。初期から使っているユーザーとしてこう、安心できる言葉みたいなのが

@spring_raining 26:08
あるといいかな、というところなんですけど、そうですね、あのまりアトムヘクもそうなんですけれども、まあ結構大きめの変更で言うと、例えば、バージョン0.4で、あのトランザクションっていうところができたりとか、うん気のエピアができたりとか。あと、シッとあのコンカレントレンナリングに対応してる

@spring_raining 26:32
たりとか、そういった着実に進化していると思うんですけども、実際感覚として周りでリコールを使ってますよ。みたいなのってよく聞きますかね。

@uhyo_ 26:44
正直、よく聞くかというと、そこまで聞く感じではないんですよね。残念なことに、うんにプロダクションで使ってます。みたいなことになると、まあ聞かないわけではないんですけど、そんなもうめちゃくちゃ普及して、あっちでもこっちでもリコールが使われてます。みたいな、そういう状況までは、残念ながらなってないな、という気はします。ただ、ほんとに出たばっかりの頃は、国内の採用事例1桁とかで、

@uhyo_ 27:11
なんか誰も使ってないみたいな状況もあったので、それに比べると、なんか徐々にまあ、普及が進んできたところじゃないかな、という風には見えますね。私もほんとに初期から使ってますけど、特に何かれたりすることもなく、ちゃんとまあ動いてくれてますので。あ、確かまだ1.0にはリコイルはなってなかったと思うんですけど、かなり

@uhyo_ 27:34
安心して信頼感が受けるライブにはなってるかなと思います。うん、うん、まあステット管理とかだけだったら、まあ責務が単純だから、まあそうそう壊れないし、まあ壊れても結構すぐ分かるはずなんですよ。だから、

参加者 3 27:50
なんか

@uhyo_ 27:51
バージョン低いライブだから、すごい目に見えないところにこそっと壊れてたら怖いとか、そういうことは、正直あんまり心配しなくてもいいんじゃないかな、という風に思っていま

@spring_raining 28:02
あ、あ、なるほど、私もなんて言うんですかね。そのライアの品質に対する心配は全くしてなくて、結構なんて言うんすかね。活用できるかどうかに対する不安がなんか変な使い方をしてないかみたいな不安がうん、うん、あったぐらいではあるんですけど、そうですよね、あの、全然そのなんていうのかね。ステート管理自体に対する不信感みたいなのは全然ないです。

@uhyo_ 28:26
あ、それはよくよくできているや、ほんとに最初からよくできできてましたね。これではそうですね、活用のことで言うと、まどんどん機能が増えていってるでありますので、それをま全部活用して完璧に使いこなすっていうのは、多分相当に難しいことかなと思っていて、こうちょっとずつ

@uhyo_ 28:48
会えていくじゃないですけど、まあ、できることを増やしていった方がいいのかなと思います。正直なこと言うと、うん、私もまだアトムとかトランザクションとか、その辺をま、実務の行動に投入しているわけではなくて、結構ベシックなステート管理として、まだ使っていたので、ほんとはだんだんこう。アドネーフェクトをうまく

@uhyo_ 29:09
使ったコードをプロダクションに混ぜ込んでいくとか、そういったことをやった方がいいと思うんですけど。そうですね、今回これまで話してきた通りま。英語システムとしてかなりよくできているので、アメフェクトとか、その辺のものを使っても、ちゃんとやればきっといいものというか、綺麗な設計なものができるだろうな、という風には、そこは結構信頼がありますね。うん、うん、

@spring_raining 29:34
まあ、ただし、正直そのほんとのなんていうんですかね。そのエフェクトを使わない、純粋なステープ、マネジメントのライブラリとしても、全然使えるところではありますし。そうですね、ま、むしろ目はそこかもしれない。あ、

@uhyo_ 29:50
そうですね、ほんとに出たばっかりの頃はまあそういう状態でしたし、その頃から結構epi自体はかなり良かったので、はい、もちろん、単なるステト管理としても、他のライブに全然指を取っていないですね。リコイルのうんまとめる人もそうだけど、ほんとにロレベルで、最低限のAPIを提供するのは、リコはうまいですね。本当に工夫しいがあるというか、自分的にはかなり好きなライブライブ。

@spring_raining 30:16
そうですね、うんという利用者からの心強い

@uhyo_ 30:22
ね。ただ、そのアナフェクトをどう設計に組み込むとか、その辺りはまだまだ知見があんまりついてないんじゃないかな、という。正直思いますのでしまとめフェットとかうち使ってるんだよ。みたいな方がこれを聞いていたらですね。どんどんそれを発信していただけるとこう、リコレコシステムの発展にすごく貢献するのかなっていう風に思います。私も、ちょっとこのアドレィクトとか、その辺り、

@uhyo_ 30:48
どうやったら使いこなせるかとか、もうちょっと考えてみようかなと今回思いました。

@spring_raining 30:53
いや、もういろんな人の知見を見たいです。いや、むしろUIT INSIDEに出てほしいです。

@uhyo_ 31:01
はい、それはもうご連絡をお待ちしています。

@spring_raining 31:04
はい、なんかあれですね。ハッシュ、タグワイティアンダー、スコアインサイトについてもらいます。と拾います。すごい唐突に宣伝が挟まれましたけど、はいぜひあのめっちゃ見てるので、ぜひ活用してます。という方がいらしたら、おっしゃってください。今回はえさんにえ、リコイルリエと、最近のリコイルのえ、エコシステムについて聞いてきました。

7. クロージング 31:22

@spring_raining 31:33
第2のフロントエンド組織UITでは、このような技術的なキャッチアップを日々行っております。 UIT INSIDE以外にも、毎週の社内勉強会で、フロントインドの情報交換を行っています。今後も、UITサイトを通して、このような情報を外部に発信していけたらと思います。最後に、

@spring_raining 31:52
現在LINE株式会社では、新卒、中途採用ともに大募集しています。このポットキャストを聞いて、ランに興味を持たれましたら、小納と1番下にある巨人ページから、ぜひアクセスしてください。それではひろさんありがとうございました、

@uhyo_ 32:07
ありがとうございました。