はてなブックマーク

英語で書いた記事の日本語版です。 こんにちは。 AI支援コーディングは素晴らしいものです。これは間違いないです。ただ、OSSへのコントリビュートという文脈になると、話は少し複雑になります。 問題点 自分のOSSプロジェクトにPRが届くと、私はそれを見て判断する必要があります。その時点では、そのPRにどれくらいAI支援が使われたのかはわかりません。 極端な例で考えてみます。もしPRが100% AI生成だったとすると、コントリビューターがやるべき確認作業を、私がレビューとしてやることになります。必要であれば、さらに修正をお願いすることにもなります。これはかなり無駄に感じます。 それなら、私が直接AIに頼めばよいはずです。というか、最初からそうしたほうがもっと良いです。そうすれば、文脈も全部わかっていますし、どのAIを使っているか、何を依頼したか、どうコントロールすべきかも自分で把握できます。そ

Waku/Jotaiの統合を探索する実験プロジェクトです。 以下、箇条書きで： この実験がしたかったからWakuの開発を始めたのですが、もう2年も経ってしまいました WakuもJotaiもまだリリースされていないバージョンを使っています 基本atomはクライアント側のステートです サーバ側でクライアントのatomを読むことができます クライアントのatomに変更があればサーバで再度レンダリングします サーバオンリーのatomを書くこともできます サーバ側のJotai storeはリクエスト毎に消えます（ステートレス）

こんにちは、Wakuの作者です。RSCのためのReactフレームワークであるWakuですが、SPAもサポートしたいと思っています。RSCとSPAに関して思ったことを雑多ですが記事にしたので、よろしければご覧ください。 以下、ChatGPTによる翻訳です。 はじめに RSCはReact Server Componentの略ですが、この投稿では以下の2つの主要な要素を含む広義のアーキテクチャとしてRSCを使用します。 コア機能：Reactコンポーネントやその他の値をシリアライズおよびデシリアライズする能力。 コア機能に基づくベストプラクティス：まだ探索の余地があると感じています。 SPA（Single Page Application）は、静的ファイルとしてデプロイされることが多いです。別のサーバーが存在する場合もありますが、それは通常SPA自体を提供するためのものではありません。この文脈では

昨日、たまたまRecoilのリポジトリが元日にアーカイブされていたのを知って、ツイートしたらすごい反響になってました。 せっかくなので、私が過去に書いたJotai関連のZenn記事をリストアップしてみようと思います。新しい順に載せますので、もし時系列を追いたい場合は下の方から見てください。あまり内容のある記事を書いていませんが、もしこれがきっかけで何か参考になれば幸いです。

この度、新たにReact Tokyoというコミュニティを立ち上げました。 少し過去を振り返ると、以前からコミュニティ活動に似た取り組みは続けてきました。当初は、2015年あたりからMeteorというフレームワークを使ったアプリ開発を推進してました。MeteorがReactを採用し始めたこともあり、徐々にUI部分はReact中心にシフトしていきました。2017年からは、Meteorに限らずJSフレームワーク全般を扱うようになり、特に後半はReactやTypeScriptを中心にしていきました。2020年2月までは、オフラインのイベントとしてほぼ毎週開催していましたが、比較的クローズドな集まりでした。2020年春からオンラインイベントに切り替えましたが、思うように人が集まらず、運営に苦労しました。オンラインでよりオープンな場を目指し、2021年からReact Fanという名称に変更し、いくつか

こんにちは、Jotaiの作者です。Jotaiが生まれるまでに様々な取り組みをした歴史を短い記事にしてありますのでよろしければご覧ください。今後のJotaiの発展に期待します。 以下、ChatGPTによる翻訳です。 はじめに この投稿では、なぜ私がJotaiの開発を始めたのか、その背景にあるストーリーを共有したいと思います。JotaiはしばしばRecoilと似たような解決策と見なされますが、その開発にはもっと長い歴史があります。 React Hooks React Hooksが最初に発表されたのは2018年10月のことでした。Reactコンポーネントの外でロジックを開発するというアイデアが気に入り、すぐに多くのライブラリがこのアプローチを採用するだろうと考えました。何か開発したいと思い、グローバル状態管理という分野を選びました。私のモチベーションは、Reduxのセレクター、当時「mapSta

個人的にはJotaiの方が大規模開発に向いているのではないかと思うのですが、現状だと大規模開発にはZustandの方が優勢のようです。 質問は「大規模」ではなく「複雑」なので、正確性に欠けますが。 個人的に大規模に向かないと思った一つの理由はSlicingの対応です。もともと、Slicingの仕組みはZustandには備わっておらず、コミュニティによって発展した使い方です。JSの場合はそれほど困らないのですが、TSの場合は型づけが複雑でドキュメントになってはいるものの、自分ではあまり使う気になりません。また、Slicingする場合は、各Sliceが独立するようにNamespacingするのが一般的だと思いますが、それもできません。 Namespacingはだいぶ以前に求められてきた機能ですが、仕組みが複雑になりがちなのと、実現方法が複数あることから、Zustand本体では対応しないことにし

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の活動は週末にすることが多いですよね。例えば、土曜の昼にコーディングして、いいものが出来上がり、やったーと思って、すぐにツイートしても、世界の目には触れません。多くの国が夜だったり、週末は休息時間だったりするからです。アナウンスツイートは、西海岸の人が出社するくらいの時間が良いです。そうすると、東海岸、ヨーロッパ、アジアに向けて日中が続くからです。自分が投稿する場合には予約すればなんとかなるのですが、本当に「不利」なのは

const atom = (initialValue) => ({ init: initialValue }); const atomStateMap = new WeakMap(); const getAtomState = (atom) => { let atomState = atomStateMap.get(atom); if (!atomState) { atomState = { value: atom.init, listeners: new Set() }; atomStateMap.set(atom, atomState); } return atomState; }; const useAtom = (atom) => { const atomState = getAtomState(atom); const [value, setValue] = useState(a

それだけだと怒られそうな気もするので、一応👇 リンク集 雑多なメモ 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