React 19 の use は現場のルールが大事かも
React 19 で追加された API に use がある。でも今のところなんでも Promise をつっこめばいいわけではない感じだったりする。
いろいろと技術検証をしているんだけど、例えばクライアントで fetch するようなものを use に突っ込むと警告がコンソールに表示される。
それは、React 19 RC のドキュメントに記載がある通りだ。
こういう記述がある
To fix, you need to pass a promise from a suspense powered library or framework that supports caching for promises.
サーバーアクションを経由で受け取る Promise だと前述のドキュメントに掲載されているような警告は出ない。でも、自分で作ってみてわかったのだけど、ソースコード上どの Promise がサーバーアクション経由なのかは結構わかりづらい。
フォームなら useActionState で比較的非同期な処理を楽にいろいろできる（useFormStateじゃなくなったということはフォームに限らない用途ということかもしれない）ようになってきている。
ちなみに警告にある uncached promise でない場合どうなるかというと use でデータ取得関数なんかを書いてしまうと何度も fetch してしまう挙動をしてしまう。
少し現場よりの話をすると、 React 19 プロジェクトを引き継いだとして、それを拡張していく際にうまくコンセンサスをとらないと "use client" しているコンポーネントの fetch を使ってしまったりして警告が出るなんてケースが起きる可能性はある。
一方、ドキュメントにはこういう記述もある。
In the future we plan to ship features to make it easier to cache promises in render.
ということで、将来どうこれらの問題がきれいに片付くのか引き続きちゃんと見ていこうと思う。でもそれらがうまく処理できるようになると use と Suspense ですごくコードがすっきりしそうだという期待感がある。
これらを隠蔽するような基盤を作っていくことになるのかなあ。
かっての om から om-next の変化とかとこのごろの React の変化は重なるところがあって、最初はシンプルで始まってもユースケースの拡大とともにどうしても複雑化しないと解決しづらい問題ってのが出てくるんだと思う。シンプルであるに越したことはない、でも現実はシンプルじゃない、みたいな。
複雑化は、単に複雑化していくだけではなくて、複雑な問題をシンプルに解決するためにどうしてもパラダイムシフトのようなことが起こり、概念の変化についていけなくなる人が出る。ある程度分かった人が初期設計をやれるかどうかはほんと重要だと思う。
