React 19 + Jotaiを試して気づいた 注意点

2024-12-15 Shinyai.js #1

Transcript

1. React 19 + Jotaiを試して気づいた 注意点 2024-12-15 Shinyai.js #1 uhyo
2. これまでのあらすじ React 19が12月にリリースされた。 Jotaiは現状最高の状態管理ライブラリだ。 （個人の感想です） 2
3. React 19 + Jotai Jotaiを使うステート管理アーキテクチャが React 19でどんな感じになるのか試してみた。 3
4. 今回作るアプリ 都道府県のチェック ボックスがあり、 選択した都道府県の 人口の合計と平均が 表示される。 （データは非同期処理 で読み込まれる） 4 https://github.com/uhyo/react-19-jotai-sample
5. ステート設計①: データ取得 5
6. ステート設計②: チェック状態 生のステートはSet<string> | undefinedとし、 別のatomでundefinedを全チェックに変換する 6
7. ステート設計③: チェックの変更 write関数のシグネチャを好きにできるため、 write-only atomに更新ロジックを載せるのが Jotai wayらしい。 7
8. ステート設計④: データ処理 普通にderived atomで表示データを 計算すればいい。 8
9. Jotai v2所感 Jotai v2では非同期atomの値の型はPromiseになる。 derived atomもその影響を受けて非同期になる。 async関数みたいな感じなので分かりやすくは ある。 9
10. デモ1 現状はリポジトリのstep1タグの状態。 Suspenseを使っているが、チェックを変えるたび にローディングが挟まる。 チェック側のサスペンドは一瞬で終わるはずだが、 FALLBACK_THROTTLE_MS (=== 300) という謎の設定に より0.3秒待たされている。 10
11. 注意点 実は、0.3秒待たされるのはReact 18 → 19で 変化した、React 19に特有の挙動！ React 18では、一瞬サスペンドが入る（ちらつ く）が、0.3秒待たされることはない。 React 19に何気なく上げたらUIのレスポンスが 悪化する可能性もあるので気を付けよう。 11
12. 注意点 とはいえ、React 18の時点でちょっとちらつく 良くない挙動になっていたので、 それを放置せずにちゃんと直していたのであれば、 React 19に上げても大丈夫だろう。 12
13. 分析 ReactはUIライブラリとして、ユーザー入力に 対して最速でフィードバックを返すことに 注力している。 なのに無駄に300ミリ秒も待たされるのは不自然。 ユーザー入力と認識されていないかも？ 13
14. 分析 ここで、setの前にawaitを挟んでいるのが 良くないかも？ awaitを無くし たい。 14
15. 分析 setの前にawaitが必要なのは、undefinedを 「全部」に変換しているから。 15
16. 方針 ステート設計を変更して、 「チェックされていない要素の集合」を持つよう にする。そうすれば、 初期状態を new Set()にできる。 16
17. 修正結果 このように、ステート更新時にawaitが必要なく なった。 17
18. デモ2 現状はリポジトリのstep2タグの状態。 目論見通り、チェックの表示がサスペンドしなく なった！ 18
19. 教訓 Jotai v2 (2023年1月リリース)ではatomにPromiseを 保存する設計になっているため、カジュアルに 「setの前にawait」しがちである。 React 19ではこのやり方が思わぬ悪影響に繋がる こともあるため、 ステート設計に注意が必要。 19
20. とはいえ ステート設計が歪んでしまうので、Jotai側で いい感じに対応できるのであれば嬉しい。 何かないか引き続き検証したい。 （下記の記事を参考に即座にPromiseをatomにsetする実装に してみたがそれではだめだった……） https://blog.axlight.com/posts/how-to-use-jotai-and-use-transition-for- mutation/ 20
21. 21 完
22. 22 完
23. こちらも合わせてご覧ください このスライド公開後に有識者と議論した結果、 より良い方法があったのでこちらも参照してください。 23 https://zenn.dev/uhyo/articles/jotai-v2-async-sometimes