Reactでの、Suspense以後の設計に不慣れな方に向けて、Suspenseの活用法をjotaiを通じて解説します。
タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
Reactでの、Suspense以後の設計に不慣れな方に向けて、Suspenseの活用法をjotaiを通じて解説します。
ここ2年ほど、すっかりフロントエンド開発者になっている藤田です。以前、Reactフロントエンドの状態管理ライブラリRecoilについて記事を書きました。 Recoilで快適フロントエンド開発 Recoil Syncでさらに快適フロントエンド開発 その後どうなったかというと、実はRecoilからJotaiに乗り換えていて、半年ほど経ちましたので、Jotaiについて書きたいと思います。 サイトの一行目から「Recoilにインスパイアされた」と言ってるとおり、Recoilの良いところを受け継ぎ、不便なところを無くしたような状態管理ライブラリです。 Jotaiの基本 基本はRecoilとほとんど同じで、React.useStateを便利にしたような感覚で非常に簡単に使えます。3ステップで見てみましょう。 1. Providerで囲む アプリケーション全体を<Provider>で囲みます。 impo
TOPフォーカスZustand、Jotai、Valtioの作者はなぜReact状態管理OSSを3つ開発したのか【フォーカス】 React状態管理ライブラリ開発者 加藤 大志（Daishi Kato） OSS開発者。React状態管理ライブラリ「Zustand」（v3以降）「Jotai」「Valtio」の作者。大手電機メーカーでのリサーチャーを経て、フリーランスエンジニアとして国内外の複数の企業でソフトウェア開発に携わる。OSS活動では主にJavaScriptやReactに関連したライブラリ開発に携わり、現在は特にReactフレームワーク「Waku」に注力。 GitHub X:@dai_shi Zustand Jotai Valtio React開発においてSPA（Single Page Application）を効率的に構築するために、アプリケーション全体の状態をどう管理するか――。すなわ
2025年のReact状態管理、正直どれがいいの？ - Zustand, Jotai, Redux, Recoil, Valtio, XState, TanStack Query をざっくり解説ReactreduxjotaizustandTanStackQuery 「Redux使ってるけど、もっと軽いの無いのかな...」 「Recoilって今でも現役なの？」 「ZustandとJotai、どっちがいいんだろう...」 Reactの状態管理ライブラリ、みなさんも選択に悩んだことありませんか？確かに2025年の今、選択肢の多さに頭を抱えてしまいますよね。Redux、Zustand、Jotai、Recoil、Valtio、XState、TanStack Query...それぞれに「これがウリ！」というポイントがあって、どれを選べばいいのか正直迷っちゃいます。 特にReact 18の登場で状況が更
この記事は一休.com Advent Calendar 2024の23日目の記事です。 一休レストランのフロントエンドアーキテクトを担当してる恩田(@takashi_onda)です。 はじめに 先日の JSConf JP 2024 で「React への依存を最小にするフロントエンドの設計」という内容で登壇しました。 speakerdeck.com 発表では駆け足になってしまった、React への依存をしていない Vanilla JS 部分をどのように構成しているのかを、Dependency 管理とテストの文脈でご紹介したいと思います。 Dependency とは Dependency Injection の Dependency です。 タイトルも「Jotai を使った DI とテスト技法」とした方が伝わりやすいとは思います。 ですが、厳密には injection していないので、あえて
こんにちは、Webアプリケーションエンジニアの鈴木です。 私が開発を担当しているtebiki現場分析では、今年の2月から6月にかけて大きな品質改善（リアーキテクチャ）を行いました。 リアーキテクチャの内容は、フォームの状態管理ライブラリを React Hook Form から Jotai に移行するというものです。 当記事では React Hook Form に対してどのような課題を抱えていたのか Jotai をどのように使い、どんなアプローチでそれを解決したのか などを紹介させていただきます。 React Hook Form で苦しんだ経験を持つ方にとって何か参考になれば幸いです！ はじめに その昔、tebiki現場分析の記録作成画面は "ユーザーが入力した値を保存するだけ" のシンプルなものでした。 入力できる形式には「自由入力」「数値」「画像」「日時/日付」などバリエーションはありま
最近知り合いのエンジニアから「Jotai」という状態管理ライブラリがRecoil より軽くてつかいやすいよ！と教えてもらったので早速「Jotai」をさわってみみました 🐣Jotaiとは？ パッケージ名は日本語の「状態」から名付けられた Recoil にインスパイアされたatomモデルを採用しReactの状態管理を行える atom依存関係に基づいてレンダリングが最適化されるためReactコンテキストの余分な再レンダリングの問題を解決し、メモ化技術の必要性を排除している ミニマルなAPIを提供している TypeScriptで開発されている 📝使い方 *https://jotai.org/ より引用 import { atom, useAtom } from 'jotai' // Create your atoms and derivatives const textAtom = atom(
https://layerx.connpass.com/event/348773/
こんにちは、Jotaiの作者です。Jotaiが生まれるまでに様々な取り組みをした歴史を短い記事にしてありますのでよろしければご覧ください。今後のJotaiの発展に期待します。 以下、ChatGPTによる翻訳です。 はじめに この投稿では、なぜ私がJotaiの開発を始めたのか、その背景にあるストーリーを共有したいと思います。JotaiはしばしばRecoilと似たような解決策と見なされますが、その開発にはもっと長い歴史があります。 React Hooks React Hooksが最初に発表されたのは2018年10月のことでした。Reactコンポーネントの外でロジックを開発するというアイデアが気に入り、すぐに多くのライブラリがこのアプローチを採用するだろうと考えました。何か開発したいと思い、グローバル状態管理という分野を選びました。私のモチベーションは、Reduxのセレクター、当時「mapSta
2024-12-15 Shinyai.js #1
この記事は株式会社カオナビ Advent Calendar 2024の23日目の記事です。 Jotai は、Reactで使えるステート管理ライブラリとしては、現状筆者が最も好んでいるものです。その理由は単純で、ステート管理アーキテクチャとして優れていると思うからです。Recoilが現役のころは同じ理由でRecoilを好んでいました。 Jotaiは2023年1月にv2がリリースされました。非同期処理の扱いがv2はそれより前と異なっており、簡単に言うとJotaiのコアから非同期処理（Promise）に対する特別扱いが排除されました。これにより、コアのAPIをReactから切り離すことができたとされています。JotaiはReactから使われることが多いとはいえ、以下のスライドでもJotaiが「Reactに依存しないライブラリ」として評価されていることからも分かるように、このような特徴は技術の普及
JotaiとRecoilは似てます。一方で、細かい違いは多くあります。決定的な違いを一つ挙げるとすれば、stringをkeyにしているRecoilに対して、Jotaiはatomのobject referenceをkeyにしています。表面的にはstring keyを指定しなくて良い手軽さが売りになっています。 よくある比較： // Recoil const greeting = atom({ key: 'greeting', default: 'hello' }); // Jotai const greeting = atom('hello'); では、表面的ではない違いは何でしょうか。もう一つのポイントは内部実装に Map ではなく WeakMap を使っていることです。つまり、atomのreferenceが無くなればJotaiのstoreからもそのうち消えるということです。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こんにちは、Watanabe Jin(@Sictu_study)です。 2025年に入ってReact界隈に衝撃が走りました。これまでメンテナンスが全然されていなかった状態管理ライブラリ『Recoil』のプロジェクトが凍結されました。 2023年にMeta社のレイオフをきっかけにメンテナンスが半年以上されなくなっていたところに、React19が登場して対応できなくなった結果完全にRecoilはなくなりました。 Recoilは使いやすくMeta社が開発していたこともあり多くのプロジェクトで採用されていたため、代替に乗り換える必要が
Fully compatible with React 18 and the upcoming use hook. Now with a store interface that can be used outside of React. Jotai takes an atomic approach to global React state management. Build state by combining atoms and renders are automatically optimized based on atom dependency. This solves the extra re-render issue of React context, eliminates the need for memoization, and provides a similar de
2月3日、LogRocketが「TypeScriptの状態管理ソリューションを比較する」と題した記事を公開しました。この記事は海外で非常に好評を博しており、日本のエンジニアにも有益な情報となると考え、概要を紹介します。 2月3日、LogRocketが「TypeScriptの状態管理ソリューションを比較する」（Comparing TypeScript state management solutions）と題した記事を公開しました。 この記事は海外で非常に好評を博しており、日本のエンジニアにも有益な情報となると考え、概要を紹介します（詳しくは元記事をご覧ください）。 この記事では、フロントエンド開発における状態管理に焦点を当て、特にReact、React Native、Vue、およびAngularなどと合わせて使用するTypeScriptライブラリについて詳しく紹介されています。 Redux
Jotaiのテスト方法に関する記事があんまりないので書きました。 公式ドキュメントにもテストに関するページはあるのですが、わりとあっさりしていて実際テストしようと思うと手探り感が強いです。 この記事では、公式の内容に加えて、Reactに依存せず必要なatomのみをテストする方法をまとめます。 環境＆バージョン viteのテンプレでReactのアプリを作って、JotaiとVitestを入れます。すべてテンプレのデフォルトまたは執筆時の最新版です。そのほかlinter等（biome, eslint）は好きに調整してください ※ 後述しますが、テストのやり方によってはここまでフルセットに色々入れる必要はないこともあります。ここに書いたのこの記事で書かれているテストを動かすための全部入り構成です。 { "dependencies": { "jotai": "^2.10.0", "react": "
昨日、たまたまRecoilのリポジトリが元日にアーカイブされていたのを知って、ツイートしたらすごい反響になってました。 せっかくなので、私が過去に書いたJotai関連のZenn記事をリストアップしてみようと思います。新しい順に載せますので、もし時系列を追いたい場合は下の方から見てください。あまり内容のある記事を書いていませんが、もしこれがきっかけで何か参考になれば幸いです。
導入 Reactive ProgrammingではSignalという概念があるらしいですが（実はもっと古くからある概念）、SolidJSが導入してReact Hooksとの差が明確になったのかと思います。 「Signal」は Solid のリアクティビティの基礎となるものです。これらには、時間とともに変化する値が含まれており、Signal の値を変更すると、それを使用しているすべてのものが自動的に更新されます。 とのことです。ObservableとかStreamとかも似たようなものですかね。 SolidJSのポイントはSignalを使ってfine-grained reactivityを実現しているところだと思います。ReactのようにVirtual DOM（とはもう呼ばないらしい、DOMじゃないので。でも、以下VDOM）を使わずに局所的にDOMを直接更新するのでパフォーマンスが良いとのこと
Introduction If someone has already looked into package.json in the jotai library, they may find "exports" field. https://github.com/pmndrs/jotai/blob/v1.6.4/package.json#L18-L31 "exports": { "./package.json": "./package.json", ".": { "types": "./index.d.ts", "module": "./esm/index.js", "import": "./esm/index.mjs", "default": "./index.js" }, "./utils": { "types": "./utils.d.ts", "module": "./esm/u
それだけだと怒られそうな気もするので、一応👇 リンク集 雑多なメモ v2 API自体はv1.11.0からpre-releaseしていたので、今回の変更は古いコードを消しただけ Webサイトがリニューアルされたことの方が意味が大きいかも v2 APIはRecoil互換の決別とも言える ずっとやりたかったstate branchingはあきらめた、Reactから機能が提供されないと無理で、その見込みがないため その結果、store APIを作ることができ、zustandに近づいた store APIは乱用されそう、できるだけ使わない方が良い Jotai Labsのorg nameをjotaijsにした
Waku/Jotaiの統合を探索する実験プロジェクトです。 以下、箇条書きで： この実験がしたかったからWakuの開発を始めたのですが、もう2年も経ってしまいました WakuもJoitaもまだリリースされていないバージョンを使っています 基本atomはクライアント側のステートです サーバ側でクライアントのatomを読むことができます クライアントのatomに変更があればサーバで再度レンダリングします サーバオンリーのatomを書くこともできます サーバ側のJotai storeはリクエスト毎に消えます（ステートレス）
こんにちは．株式会社ゆめみの Keeth こと桑原です． 今回は Jotai という React 用の超軽量な状態管理ライブラリを触ってみたので勉強ログとしてまとめました．軽く使ってみた感触としては非常にシンプルで分かりやすく，導入も簡単でした． ただ，既に Jotai リリース後ある程度時間が経っており，Google で検索していただくとわかるかと思いますが，Jotai に関する記事もいくつかありますので，二番煎じな内容もありますことをご了承頂ければと思います． ※一応自分が手を動かしたコードのリポジトリも載せておきます 👇 https://github.com/kkeeth/my-jotai-demo TL;DR とにかく軽量で簡単 Redux が冗長に感じ，もっとライトなものを探している人にオススメ 軽量な分ルールが少ないのでカオスにならないように注意 Jotai の概要 触ってみ
Reactの状態管理ライブラリであるRecoil, Jotaiは宣言的かつシンプルにデータフローグラフを構築するライブラリです。 原始的な機能の集合体であり、直感的に状態管理を実装できる反面、潜在的に壊れやすいコード(Reactの哲学と反するコード)もかけてしまいます。
こんにちは！ 株式会社カンリーでカンリー福利厚生の開発チームに所属しているaoyyです。 カンリー福利厚生ではフロントエンドの状態管理ライブラリとしてRecoilを使用していましたが、最近Jotaiに移行しました。 折角なので移行時の諸々をまとめていこうと思います！ 背景 Recoilは元々2023年4月からアップデートがなかったのですが、2025年1月に正式に開発停止となりました。そのため、Reactのバージョンアップに対応されない、今後バグが見つかった際に修正が入らないなど問題となる可能性がありました。（実際React19では正常に動作しません） チーム内ではある程度容易に移行可能かつ今後も開発継続が見込まれるJotaiに早めに置き換えしたいという話があがっていました。 その中でも今回は初回ということもあり、影響範囲の少ない管理画面側の移行を行うこととなりました！ RecoilとJot
発生した事象 Jotai の atomFamily へ Recoil の atomFamily から移行した際、特定の条件下でコンポーネントが無限に再レンダリングされる問題が発生しました。 具体的には、以下のように atomFamily の引数としてオブジェクトリテラルを直接渡していたところ、該当のコンポーネントが再レンダリングされ続ける状態となりました。 import {atomFamily} from 'jotai/utils'; import {atom} from 'jotai'; type PagerParameters = { displayType: 'pc' | 'sp'; contentsId: ContentType; maxNumberPerPage: number; }; export const pagerState = atomFamily((parameter
概要 Jotai, primitive and flexible state management for React Jotai は Recoil からインスピレーションを受けて開発されたグローバルステート管理ライブラリです。コア API が厳選されており良い意味で少なくて機能もシンプルなので Recoil を利用した事がある人であれば直ぐに理解できるでしょうし、そうでない人でも useState に近い使用感なので比較的直ぐに理解して使えるようになると思います。 他のグローバルステート管理ライブラリと共通する Context や useState だと起きやすい以下の問題を解決します。 props のバケツリレーによる依存関係や影響範囲の複雑化 多数の Provider を管理することによる複雑化 これらの影響による過剰なメモ化による再描画対策 Recoil と比較した特徴としては T
ゆめみでフロントエンドエンジニアをしているゆーけんです🐈 新卒一発目でアサインされた案件で、Jotaiで状態管理されているプロジェクトをZustandで作り直すというパワー系リファクタを経験したので記事に書きます。 開発したプロダクト 一覧画面 新規作成画面 編集画面 がある以下の画像のような管理画面を、先輩と2人で0から開発しました。 一覧画面 新規作成画面 詳細画面 フォームの値をリアルタイムでプレビューに表示するため、フォームの値をJavaScriptで管理する必要があります。 コンテンツの値を状態管理したい コンテンツは新規作成、削除される コンテンツのプロパティ入力フォームに様々なバリデーションを実装したい これらの条件はJotaiのatomFamilyを使うことで柔軟に設計できそうだったので、はじめはJotaiを使って設計・実装しました。 Jotaiで実装する 設計 コンテン
株式会社パルケの手を動かすCTO、みつるです。 この記事は先日ツイートしたものを加筆修正したものとなります。 少し前まで、Reactの状態管理ツールはZustandがファーストチョイスでした。 今は考えが変わってJotaiがファーストチョイスとなっています。 以前、状態管理ツールの沼にハマって試行錯誤した経緯はこちらの記事に書きました。 この後、状態管理ツールに対する考えに変化があり、今は私にとってJotaiがファーストチョイスとなっています。 状態管理ツールの責務が軽減された TanStack Queryを積極的に使い始めてから、サーバーと同期するようなトランザクションデータはTanStack Queryのキャッシュ任せになりました。 そうすると、状態管理ツールが担っていた役割がどんどん少なくなっていきました。 結果として残ったのは、コンポーネントのPropsで受け渡しをするには面倒な、
はじめに 筆者は普段 React や Next.js においてグローバルステートを扱う際はContext APIかJotaiを使っていました。 理由としては、Context APIはReact標準で、JotaiはuseStateライクな書き方・使い方で学習コストが低いからです。 他方、Zustandは store という概念があって（Jotaiにもありますが使用は必須ではない）、それをベースにした処理になります。そういった点で少し学習コストを感じて距離を置いていたのですが最近軽めの新規プロジェクトがあったので良い機会だと思ってZustandを使ってみました。 結果としては Zustandの store ベースの処理が責務分離やシンプルさの観点から中〜大規模にも対応しやすそうで、さらにDXも良さそうという印象です。 しかしもちろんJotaiが使いづらいとかいうことは決してなく、小〜中規模で、
はじめに この記事はJotai公式ドキュメントのbottom-up approachというワードをきっかけに、Reactの状態管理におけるトップダウンとボトムアップとは何なのかを整理したいという個人的な思いで書いています。 Jotai takes a bottom-up approach to React state management with an atomic model inspired by Recoil. トップダウン型について そもそもトップダウンという言葉はどこで登場するのか Reactの公式ドキュメントではtop-downという言葉が以下のように登場します。 このデータフローは一般的には “トップダウン” もしくは “単一方向” データフローと呼ばれます。いかなる state も必ず特定のコンポーネントが所有し、state から生ずる全てのデータまたは UI は、ツリー
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 状態管理は、2025年の今なおReactアプリ開発における最も頭を悩ませる要素のひとつです。アプリが大規模化し、UIがますます動的になるにつれ、開発者は状態の同期、過剰な再レンダリングの回避、ボイラープレートの削減などの課題に日々立ち向かっています。最近の調査では、React開発者が同期問題、パフォーマンス、そしてReduxのようなソリューションの複雑さを上位の痛点として挙げていました。React標準のContext APIやHooksは基本的なユースケースをカバーしますが、「中規模以上」のアプリや複雑な状態管理には十分でないと感じるチ
今回は React アプリケーションの状態管理ライブラリの中でも人気の高い "Jotai" の使い方を記事にしたいと思います。豊富な機能の中から本記事では以下の機能について記載しています。 atom, useAtom, useSetAtom, useAtomValue atomWithReset, atomWithLocation ( searchParams ) Read Only Atom, Write Only Atom Atom Creator 記事内に掲載しているソースコードは Github でも確認できます。 Jotai とは 🤔 Jotai は @dai_shi さんが作った React アプリケーションのための状態管理ライブラリです。軽量で使いやすく主に次のような特徴があります。 Atom（アトム）と呼ばれる小さな単位で状態を管理できる 使い方が直感的で、学習コストが低い
この記事は公式DocのComparisonページの翻訳（下訳にDeepLを利用）と筆者のコメントが付いた内容になっています。原文と翻訳部分は引用表記しています。 https://github.com/pmndrs/jotai/blob/v1.5.2/docs/basics/comparison.mdx がソースです。 ご存知Reduxが登場せずに、急にZustandが出てきて何それ？となるかもしれません。ひとまず見ていきましょう。 JotaiとZustandの違いは？ How is Jotai different from Zustand? ライブラリ名 Name Jotai means "state" in Japanese. Zustand means "state" in German. Jotaiは日本語で"状態"、Zustandはドイツ語で"状態"という意味です。 そうなんです、
はじめに 先日、Reactの状態管理ライブラリとして知られていたRecoilのリポジトリがアーカイブされたことが話題になりました。 This repository has been archived by the owner on Jan 2, 2025. It is now read-only. これまでRecoilを利用していた開発者も多く、戸惑った方もいるかもしれません。その中で、RecoilからJotaiへ移行したという事例も見かけるようになりました。 私自身も今回、Jotaiを使ってみたのでその基本的な使い方をまとめてみました。 また、Jotai特有の派生状態( Derived Atom )の活用例も紹介しているので参考になったら嬉しいです。 Jotaiはどんなことができるのか JotaiとはReact向けの状態管理ライブラリです。 主に以下のようなことが可能です。 グローバルな
SPA はリロードすると state が消えてしまうので永続化したい状態ってのが結構あります 生の React だと カスタム hook や useEffect 内で localStorage にアクセスして保存させたえい、Recoil でも effect を使って永続化するコードを書く必要がありました jotai を使うと localStorage に保存するための API が用意されていて永続化がめちゃくちゃ簡単だったのでメモに残しておきます 環境 React 18.2.0 Next.js 13.2.4 jotai 2.0.3 TypeScript 5.0.2 atomWithStorage で直接 localStorage に state を保存できる！ atomWithStorage(key, initialValue, storage) key (required): a uni
2.状態管理ライブラリとJotai JotaiはReactの状態管理ライブラリの1つです。 Reactでは規模が大きいアプリケーションを開発する際に、多くの状態管理が必要になり、結果的に状態の制御が難しくなって開発効率が低下してしまうことがあります。 この問題を解決するのが、Reactの状態管理ライブラリです。 状態管理ライブラリでは、一般的に次のことができるものがほとんどです。 グローバルに状態を管理する Propsのバケツリレーを少なくする 不要な再レンダリングを防止する 2.1.Jotaiの特徴 Jotaiは以下の特徴を持っています。 シンプルかつ柔軟に開発することできる 軽量なAPI TypeScriptで開発されている 初学者にとって最もJotaiが便利だと感じる場面は「グローバルステートとして状態をシンプルに管理できる」という点にあると思います。 JotaiはReduxやRec
よく誤解されるのですが、atomはステートの定義であって、atomオブジェクト自身は値を持ちません。ObservableやSignalとの違いはそこにあるかもしれません。 atomが単なる定義だとするとどういうメリットがあるでしょうか。再利用性が高くなります。以前作った簡単な例がこちら： 複数のProvider配下で、atomはそれぞれ別の値を持ちます。 ちなみに、Jotai v2によってstoreの存在が明確になったので、説明はしやすくなりました。atomの値はstoreで保持されます。storeはざっくりatomとその値のWeakMapです。
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
を見ました。これめっちゃ面白い。再帰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
React アプリケーションで利用できる状態管理ライブラリである Jotai ですが、筆者も技術的な特性がフィットする一部のプロジェクトで利用しています。 Jotai v2 からは非同期処理がより柔軟に扱えるようになったことで、データフェッチやバックエンドでのバリデーションなどを伴う複雑な state であっても Promise<T>を返すだけの通常の atom として記述できるようになりました。 一方で、React コンポーネントで atom の値を読み込む useAtomValue は、atom が Prromise を返すと Suspend します。この Promise は内部的には解決済みで一瞬で返ってくるはずが、React 19 では0.3秒待たされてしまう… それに対処するのが "async sometimes" パターンです（詳細は下記の uhyo さんの記事を参考にしてくだ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く