Zenn
🎩

SWRとReact Queryどっち使おうか検討したメモ

2020/09/21に公開
JavaScript
React
SWR
React Query
idea

SWRとReact Query（以下RQ）をどっち使おうか眺めてて、「だいたい出来ることは一緒のはずなのになんかSWRのほうが惹かれる」ってなったのでどのへんが起因だったかのメモ

ファーストExampleに見る違い

https://swr.vercel.app/#overview

const { data, error } = useSWR('/api/user', fetcher)

https://react-query.tanstack.com/docs/overview#enough-talk-show-me-some-code-already

  const { isLoading, error, data } = useQuery('repoData', () =>
     fetch('https://api.github.com/repos/tannerlinsley/react-query').then(res =>
       res.json()
    )
 )

一見、ほとんど一緒じゃん、となるが、SWRは「キーをfetcheの実行するためのパラメータ」になっている。

一方、react-queryは「キーと実行APIは独立している」。これはイメージとしてReduxのActionなどのconstantのような印象を受ける

APIの違い

Core API

これはかなり明確に違いが出ている。RQの方はかなり豊富に返り値を用意している一方、SWRはisLoadingのようなものすら無い（正直isLoadingぐらいほしい）

Configuration

どっちもGlobal Configを持ってた

key

Arrayを渡せるのはどちらも一緒。objectについては、RQの方は渡せるらしい。SWRの場合、「objectを渡すとキャッシュ効かないよ」となっている。

これは困るケースはあるかもしれないと思う一方、useEffectのdepsと同一のルールで、実に「Reactっぽい」という感じもする

dependent query

SWRの面白いのはkeyとしてfunctionを扱える部分。これによって複数のuseSWRが依存性を持つようなことが出来る。RQの方はこれをenableフラグで行っている。

SWRの方は一見良くみえるが混乱や不必要なオーバーロードが起きるとRQの作者から助言があったが、例示まで教えてもらえなかったので正直どのような実害の話をしてるのかよくわかってない

fetcher / queryFn

どちらもkeyをfunctionを受け取ることは出来る。

ただ、RQの方は fetchTodoById(key, todoId, { preview })　となっておりやはり「keyは使わない・あくまでキャッシュのため」という思想を強く感じる。

SWRは keyをそのままURLとして使う機構によってfetcherを共通化しやすくなっている

言語

Cacheの内部構造

  • 基本どっちもContextを使ってる

Business

  • SWR: vercel社は割とnextを中心にやっていて、そりゃこの辺をやるよなという感じ。「vercelはproductionで使ってるよ」というのも多分vercel（旧now.sh）でいい感じにローディングされる機能に使ってるんじゃないかと思われる
  • https://learn.tanstack.com/p/react-query-essentials
    • react-query自体の動画講座をやっている？

DevTool

先人の比較とか

Discussion