サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
zenn.dev/dai_shi
TSKaigi 2024で短い発表をしましたが、これには元ネタというかオリジナルの記事があります。 ChatGPTに翻訳してもらいました👇 なぜZustand TypeScript実装はこんなに醜いのか ちなみに、JavaScript実装はとてもクリーンです 序論 注: この投稿はZustandライブラリのTypeScript実装に焦点を当てています。 ユーザーコードには影響しませんが、クリーンに保つべきです。 ZustandのJavaScript実装は非常に小さいですが、以下のツイートで見られます。 しかし、そのTypeScript実装はかなり複雑です。 その理由はいくつかありますが、この投稿ではそのうちの一つを探ります。 SetStateInternal型 SetStateInternal 型をもう少し詳しく見てみましょう。 (これは内部使用を意図していることを念頭に置いてください。
で、しれっとNode依存からの脱却と書きましたが、とても大変でした。 にあるように、Honoへの移行は重要だったのですが、Honoに移行した時点ではまだNodeに依存してました。Hono移行に着手してからおよそ1ヶ月、 この辛さは誰にもわかってもらえないと思って、あえて書きませんでしたが、まあ、それはそれは大変でした。ざっとPRの数を数えたら25くらいでした。 書かないと伝わらないと思い、頑張って書いてみます。 Node StreamからWeb Streamへの変更 当然、Node Streamは使えませんので。 ちなみに、最初にExpressからHonoに移行した時点では、Node Stream -> Web Stream -> Node Streamという余計な変換をすることになってました。理解が正しければ、最後の変換はHono内です。今の時点でも、Hono+Nodeを使う場合には、W
を読んで、いくつか思うところはありつつ、一点だけ書いてみたいことがありまして、書いてみます。 それは、時差についてです。仕事上の話ではなく、Twitter/Xの上での話です。 日本時間で生活しているとそれなりに不利なのです。Twitterのフォロワー数が少なかったころはあまり気にしてなかったのですが、伸ばそうと思うアナウンスをする場合は、投稿時間が重要になってきます。OSSの活動は週末にすることが多いですよね。例えば、土曜の昼にコーディングして、いいものが出来上がり、やったーと思って、すぐにツイートしても、世界の目には触れません。多くの国が夜だったり、週末は休息時間だったりするからです。アナウンスツイートは、西海岸の人が出社するくらいの時間が良いです。そうすると、東海岸、ヨーロッパ、アジアに向けて日中が続くからです。自分が投稿する場合には予約すればなんとかなるのですが、本当に「不利」なのは
それだけだと怒られそうな気もするので、一応👇 リンク集 雑多なメモ v2 API自体はv1.11.0からpre-releaseしていたので、今回の変更は古いコードを消しただけ Webサイトがリニューアルされたことの方が意味が大きいかも v2 APIはRecoil互換の決別とも言える ずっとやりたかったstate branchingはあきらめた、Reactから機能が提供されないと無理で、その見込みがないため その結果、store APIを作ることができ、zustandに近づいた store APIは乱用されそう、できるだけ使わない方が良い Jotai Labsのorg nameをjotaijsにした
を見ました。これめっちゃ面白い。再帰selectorかっこいい、ほれました。Loadableの使い方も素敵。 Jotai版を作ってみたくなりますよね、はい。作りました。 ほとんどコードの中身を理解せずに移植して、あとからコード読みました。ちなみに、移植で大変だったのは、型の付け方が微妙に違うことです。それ以外はほぼ単純な変換。ここまで互換性があったとは。 出来上がったもの コード Recoil版からそのまま使えるものはimportしてます。 import { Suspense, useEffect, useRef } from "react"; import { Atom, atom, useAtomValue, useSetAtom } from "jotai"; import { atomFamily, loadable } from "jotai/utils"; import { Q
導入 Reactive ProgrammingではSignalという概念があるらしいですが(実はもっと古くからある概念)、SolidJSが導入してReact Hooksとの差が明確になったのかと思います。 「Signal」は Solid のリアクティビティの基礎となるものです。これらには、時間とともに変化する値が含まれており、Signal の値を変更すると、それを使用しているすべてのものが自動的に更新されます。 とのことです。ObservableとかStreamとかも似たようなものですかね。 SolidJSのポイントはSignalを使ってfine-grained reactivityを実現しているところだと思います。ReactのようにVirtual DOM(とはもう呼ばないらしい、DOMじゃないので。でも、以下VDOM)を使わずに局所的にDOMを直接更新するのでパフォーマンスが良いとのこと
useEffectの新しいドキュメントが書かれている途中です。useEffectのタイミングでデータ取得を開始するのは、これまでもベストプラクティスではないと言われていたのですが、React 18のStrict Effectにより再び議論されるようになりました。 今のところ、Reactが提供しているAPIだけですんなり実現する方法はなく、3rd-partyライブラリやフレームワークを使いましょうとなっています。react-hooks-fetchはその一つにならないかと開発してます。 また、他のライブラリも開発してます。比較表を作りました。 ちなみに、以前作っていたuseEffectベースのライブラリはdeprecateしました。こちらの記事にも注釈追記しました。 かいつまんだ紹介しかしませんでしたが、こんな議論を楽しめる方がいらしたら、ぜひReact Fanオンラインコミュニティ(Slac
このページを最初にブックマークしてみませんか?
『daishiさんの記事一覧』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く