useQueryのkey
個々のqueryに対してuniqueである必要がある
そのkeyがcacheの中に存在するかどうかで挙動を変えている
keyとして扱えるもの
array
arrayの中身はserializeできるなら何でも良い
stringも使えるが、どのみち内部でarrayに変換されるので、arrayに統一しちゃうかmrsekut.icon
arrayの場合
要素は、primitive値でも、recordでも良い
/users/42のようなpath paramsとか
/users/42?preview=doneのようなquery paramsとかを
そのままkeyとして表現できる
code:ts
record内のkeyについては順序は問わない
code:ts
// 以下は全て同じものとして扱われる
配列の順序は問う
recordは、deep equalで比較される
stringの場合
階層の無いresourceに対して使う
実際は、内部でarrayに変換される
code:ts
useQuery('todos', ...) // queryKey === 'todos' なので、全てarrayに統一しちゃっても良い ref butotnをclickしてrefetchしたい時にどうするか ref query paramsが異なる場合は、そもそも「refetch」とは言わないmrsekut.icon
clickして、stateが変わると、自動的にfetchされる
だからこのようには書かない
code:ts
function Component() {
const { data, refetch } = useQuery('todos', fetchTodos) return <Filters onApply={() => refetch(???)} /> // ここ
}
clickした時にrefetchを呼ぶのではない
こう書けば良い
code:ts
function Component() {
return <Filters onApply={setFilters} /> // ここ
}
keyに使っている状態を変更すれば良い
featureごとにquery keyのfactoriesを作る ref なるほどmrsekut.icon
この1つ前の節で説明された階層構造もうまく反映している getStaticProps内で、とかkeyを共有することがあるので一元管理しておいたほうがいい
仮に、['a','b','c']と使っている時に、['a','x','b','c']が必要になった時に、散らばっていると修正がダルい
keyがかぶっていないことを確認できる
バラバラに書いていると、['post', title]と['post', 'detail']のようなものがあった時、たまたまtitleが'detail'のものがあれば意図せず重複してしまう
一元管理しても起きうるが、一望できるのでまだマシな気がする
featureごとに一元管理すればいい
全体の一元管理はきついので、featureごとにやるぐらいが良いだろうな
どういう風に運用するか?
何かしらのルールがあるとuniqueであることを担保しやすい
構造の意味
Filtersがあるので、構造化したほうが良い
例えば「keyが'users'で始まるものをhogehogeする」みたいな処理ができる
参考