Jotaiはどのようにして誕生したのか、単なるRecoilの代替手段なのか？

こんにちは、Jotaiの作者です。Jotaiが生まれるまでに様々な取り組みをした歴史を短い記事にしてありますのでよろしければご覧ください。今後のJotaiの発展に期待します。

https://blog.axlight.com/posts/how-jotai-was-born/

以下、ChatGPTによる翻訳です。

---

はじめに

この投稿では、なぜ私がJotaiの開発を始めたのか、その背景にあるストーリーを共有したいと思います。JotaiはしばしばRecoilと似たような解決策と見なされますが、その開発にはもっと長い歴史があります。

React Hooks

React Hooksが最初に発表されたのは2018年10月のことでした。Reactコンポーネントの外でロジックを開発するというアイデアが気に入り、すぐに多くのライブラリがこのアプローチを採用するだろうと考えました。何か開発したいと思い、グローバル状態管理という分野を選びました。私のモチベーションは、Reduxのセレクター、当時「mapStateToProps」として知られていたものを避けることでした。私の仕事の経験では、リファレンシャル等価性（参照等価性）を理解するのが初心者には非常に難しいと感じていました。余分な再レンダリングを避けるために、reselectなどのメモ化ライブラリを使用する必要があるかもしれませんが、セレクター自体の計算が比較的軽量であれば、それは不必要に感じました。

Reactive React Redux

私の最初の目標は、セレクターを必要としないReact Redux用のReact Hooksを使用したバインディングライブラリを開発することでした。誤解のないように言うと、セレクター自体は問題ありません。私が避けたかったのは、レンダリング最適化のためだけにセレクターを使用することです。そこで私はプロキシに着目しました。プロキシを使うことで、状態オブジェクトへのアクセスを追跡し、アクセスされたプロパティが変更されたときだけ再レンダリングをトリガーできるようになりました。これにより、レンダリング最適化のためのセレクターは不要になり、自動的に再レンダリングが最適化されました。このアイデアを気に入ってくれる人もいましたが、一方で公式のReact ReduxバインディングがuseSelectorフックを提供し、それがデファクトスタンダードとなりました。最終的に、私のライブラリは「メンテナンスされていない」とマークされました。

https://github.com/dai-shi/reactive-react-redux

React Tracked

Reduxに独自のHooksライブラリができたことで、私はReduxから離れ、React Contextパターンに焦点を当てたライブラリの開発に乗り出しました。useState（またはuseReducer）とReact Contextを組み合わせた単純な解決策には、余分な再レンダリングの問題があります。このライブラリは前述のものと同じアプローチを取り、その問題を克服しました。このライブラリの最大の利点は、単純な解決策から意味論を変更しないことです。既にuseStateを使用して状態をコンテキスト経由で伝播していた場合、このライブラリを導入するのは非常に簡単で、自動的にレンダリングが最適化されます。このライブラリはReact Trackedと呼ばれています。

https://github.com/dai-shi/react-tracked

私はこのライブラリに多くの努力を注ぎ、ベンチマークを行い、ドキュメントを書き、ウェブサイトをセットアップし、多くのブログ記事を書きました。一部の人々には非常に気に入られ、実際にプロダクションでも使用されました。しかし、もっと注目を集めるには何かが欠けていました。ネガティブなフィードバックとしては、このライブラリがあまりにも魔法のように裏で動作するため、プロキシの使用をためらう人もいました。

Recoil

私は、プロキシを使用せずに、セレクターを使わないレンダリング最適化を維持する方法を模索していました。2020年5月、React EuropeのカンファレンスでRecoilが発表されました。それはまさに私が求めていたものでした。React TrackedをReact Contextで作成した理由は、Concurrent Modeと互換性を持たせるためでした。RecoilはConcurrent Modeと互換性があると言われていました。AtomモデルはObservableとは少し異なり、Reactのユースケースに焦点を当てていました。

https://www.youtube.com/watch?v=_ISAA_Jt9kI

私は、同じようなアイデアを思いつけなかったことに少しショックを受けました。基本的な技術はそれほど新しいものではありませんでした。MobXも似たようなことをしていました。Recoilが発表されたことで、私は自分のライブラリを作るのを半ば諦めました。Recoilを使えば良いと思ったのです。しかし、それでも私は考え続け、何か似たものを実験するのを止めませんでした。私がRecoilで気に入らなかったのは、Atomに文字列キーが必要なことでした。APIがしっくりこなかったのです。それがシリアライズのためだということは理解できましたが、それはRecoilが決して文字列キーを省略させないことを確信させました。そこで、私は自分のライブラリを開発することに決めました。

Jotai

Jotaiは明らかにRecoilに触発されていますが、いくつかの重要な違いがあります。文字列キーを省略することに加えて、その設計哲学は、小さなAPIサーフェスと最小限のコアに焦点を当てています。追加機能はすべてコアの外で実装されるべきです。Jotaiは2020年9月9日に最初に発表されました。その時点では、人々がそれをどう受け止めるか非常に不確かでした。私はRecoilをFluxのように捉え、Recoilに似たライブラリが多く登場するだろうと思っていました。目標はAtomモデルのアイデアを広めることでした。

https://github.com/pmndrs/jotai

最初の発表後、いくつかのポジティブなフィードバックがあり、開発を続け、v1に到達し、そしてv2に到達しました。より多くのコントリビューターが参加し、現在はグループでプロジェクトを維持しています。私たちはドキュメントとウェブサイトを持ち、最小限のコアの周りに多くの統合ライブラリがあり、これらは複数のコントリビューターによって維持されています。

現状

さまざまなバグを修正し、Jotaiは現在非常に安定しています。現在の私の焦点は、コントリビューターによってコアがよりメンテナブルになるようにすることです。コアコードは非常に複雑であり、私の課題はそれをより読みやすく、理解しやすくすることです。さらに多くの統合ライブラリがあれば良いですし、実際に増えつつあります。

Jotaiのユーザーとコントリビューターの皆さんに感謝しています。本当に感謝しています。