タイトルが雑だし、こんな記事を書くのも変な話だけど、意外と書かれているのが少ない気がしたので書いておく。2023年以降になったらプラクティスがまた変わってるかもしれないけどそれはそのとき。
久しぶりにカスタムHooks書いていて、「Hooksの内部処理ないしは引数に渡されたコールバックでエラーがThrowされた場合とかってどうエラーハンドリングする設計がいいんだっけ？」という気持ちになったので、考えたりしていた。
と言っても、まあ有名なライブラリとか見にいったらわかるだろうと思ってGitHubを眺めにいった。「なんか非同期処理してたまにエラーが起こりがちなHooksライブラリって考えると、urqlとかSWRとかreact-queryとか、まあそういうFetcherライブラリでしょ」ということで参考にすると、どのライブラリもerrorプロパティをHooksのresultとして返していた。
↓例えばSWR
const { data, error, mutate, size, setSize, isValidating } = useSWRInfinite( (index) => `https://api.github.com/repos/${repo}/issues?per_page=${PAGE_SIZE}&page=${ index + 1 }`, fetch )
冷静に考えると、errorをどうしたいかはHooksの責務じゃないのでそれはそうという感じがする
hooks製作者としては、『error起こったらとりあえず結果として返す』というのが基本的によさそう。
Error Boundaryでいい感じになんかする
Error Boundaryまで到達させるかどうかはケースバイケースだけど、Generalなエラー処理をコンポーネント本体の外に押し付けられるので個人的にはErrorBoundaryで囲っておくのがいいと思っている。
bvaughn氏のこれは useErrorHandler があって大抵のケースでいい感じに設計されているErrorBoundaryなのでこれを使っておけばまあ大丈夫感がある。
ErrorBoundaryについて知らない人はReactの公式を読む。
そういうわけでExample
useRandom というHookを雑に書いて、なんかたまに乱数によってはエラー扱いとする横着なHooks。実際の業務でこんなHooksは書かないと思うけどExampleなのであくまで雰囲気用。
たぶん来週くらいになったら自分が忘れているはずなので一応書いた。
