Firebase database and swr

[DoT214]

Question : Is it a good strategy to use swr with firebase ?

[sergiodxa]

You could use the Firebase JS client as fetcher, probably with a wrapper, but I’m not sure how useful it would be 🤔

[illuminist]

Realtime database and Firestore has their own optimized caching strategy so it's better to let them handle their own data.

[danoc]

Highly recommend checking out swr-firebase. I'm playing around with it now and it seems very well done.

[shuding]

@danoc wow I didn't know about that lib, it looks truly amazing. Thank you!

[optimista]

I did some research whether to implement swr-firestore or not for an own personal project. This is what I concluded and some of the distinctive features which I found. Happy to learn more! I'm far from understanding everything.

swr-firestore

• can listen to e.g. document's get()s across screens (getting same document on other screen without swr won't update first one - see: https://www.reddit.com/r/Firebase/comments/he3qtg/firestore_hooks_library_for_react_useswr/fvz6x71/?utm_source=reddit&utm_medium=web2x&context=3)
• supports multiple order-bys, limits (easier writing of queries)
• has a pagination model
• supports React Suspense

As far as I did my research, the other features can be resolved with e.g. onSnapshot listeners of firestore realtime database which provides its own caching system, even ordinary get()s do cache, maybe without that screen update though. This made me conclude that even though it can be nice to have, the costs of implementation and upkeeping might just slightly overweigh benefits than dealing only with the raw firestore library. Still - something to keep an eye on!

UPDATE: I did run exactly into this situation https://swr.vercel.app/getting-started#example . I wanted to fetch the same firestore document in two different components on the page and at the same time I didn't want to separate logic of fetching from those components into the common container with one fetch (as it would create parent-child dependency, duplication of logic across containers etc.). At the same time I didn't want to create two requests to be billed with 2 reads from firestore. This exactly solves the problem of implementing useSWR together with firestore and I don't even have to hassle with Redux to have one common cached state object.