RFC: SWR in Explorer

[vacekj]

@bard @gravityblast @bhargavaparoksham

Currently we are using a mix of SWR and manual data fetching in Explorer.

Why data fetching lib in general:

• caching
• reusable hooks
• err, data, loading pattern for free
• stale-while-revalidate
• request dedupe
• refresh on back to page
• optimistic UI
• pagination and scroll recovery

Why SWR:

• simpler than React Query while having everything we need
• we can easily switch to RQ if we ever need to
• it's already in the codebase

Why not SWR:

• less features than React Query, but we don't need them currently

https://tanstack.com/query/v4/docs/react/comparison Comparison between SWR and React Query

Why not other libraries?

• Popular library has better support and more mindshare ( not always better tho )
• swr is stable, used by vercel and well-tested in production

As this is a dependency of Explorer voyage, unless anyone has arguments against, I would love to expedite this from a week to ASAP™.

[bard]

Came away with the same impression. react-query has a lot, I've used it in the past, and would advocate for it in a greenfield project. But most of that seems marginal here. So +1 from me for SWR.

But if there's an intention of switching to server-side rendering down the road, I'd give this a read: https://tkdodo.eu/blog/you-might-not-need-react-query

[vacekj]

There's def an intention to switch to SSR for the critical paths down the road, maybe even as part of explorer voyage. Good article, as I understand it, RSC + app directory and its caching mechanisms would cover a lot of what we're getting from SWR or RQ, but not all, e.g. I don't think RSC provides for optimistic UI just yet without manual intervention, auto refetch on switching tabs might also need to be implemented manually, which I expect to be a great feature to update matching stats upon going back to a project page. Generally, I would wait a bit more (months) for the app router and related tech to really stabilize, personally feel like Vercel et al rushed the release a bit.

The end state I envision is that we fetch the truly static data server-side via RSC, like the project name, description, round metadata etc, and seed the dynamic data from the server, but handle refetching etc. using RQ or SWR.

[bard]

(FYI we had settled on using Github issues so as to piggyback on the issue state to track RFC status. Let's keep this one here but also let's bring it up in the next meeting if we have found reasons to switch.)

[vacekj]

Force of habit, used to use discussions for discussions, I'll remember to use issues in the future.

[gravityblast]

+1 from me for SWR as well, let's do it gradually in different tickets/prs so we can have simple review and testing sessions, and maybe add more tests when needed

[bhargavaparoksham]

+1 for SWR. @vacekj are you planning to implement other features like caching etc as well in the current revamp that you are planning?

[vacekj]

If you mean caching of fetch requests to indexer and graph and others, then we get that for free from SWR. JV

…

On 17. 8. 2023 10:46 +0200, eagle ***@***.***>, wrote: +1 for SWR. @vacekj are you planning to implement other features like caching etc as well in the current revamp that you are planning? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[vacekj]

Consensus achieved on SWR, closing.