After using it for a long time, I have a few questions, and welcome to discuss

[wanliyunyan]

swr is an amazing lib. I like many of its features, such as Local mutation and Suspense mode. But I had several problems for using it

1. Which requests should use swr, and which requests should not use swr

   swr should be used for data that can be changed frequently , such as <Table> or <List> whose data is always updated or deleted. however,should swr be used for data that is hardly changed ?????? such as <Select> <Form>.

2. When I use swr, it becomes very difficult to find songthing in the browser,

Among so many repeated requests, it is difficult to find the request I want, Is it because my code is wrong?

const { data, error } = useSWR(
    [
      "/******",
      search?.begin ?? "",
      search?.end ?? "",
    ],
    (url, begin, end) => {
      return swrFetch(url, { begin, end });
    },
    { suspense: true }
  );

3. When many users visit my website, the server will receive too many requests, which puts a lot of pressure on the server and database

4. If the page requires a lot of calculations, should i still use swr?
   such as <Map component> <Chart component> or lots of loops

I have used swr for a long time, but I still haven't found the best practice. and you? ? ?

[anothertempore]

I think we could using swr handling all of the get requests.

The reason there are many repeating requests is that swr will do the data validation on some specific times, such as component oMount, page onFocus, etc. you can turn off the validation in the config options.

const { data } = useSWR('/url', { revalidateOnMount: false, revalidateOnFocus: false })

For best practice, I want to share my experience:

1. File structure: we can organize every request into a hook. It's convenient to reuse those requests.

- user
  - useUser.ts
  - useSerchUser.ts
- member
  - useMember.ts

// useUser.ts
const useUser = (id: string) => {
  return useSWR(`/user/${id}`)
}

2. Most of the time we need to assemble and serialize parameters for the URL, so could consider to setup another hook by wrapping useSWR to handle this.

3. As swr doesn't support post request and inspired by swr could do configurations in React context, I did some similar thing to swr to handle the non-get requests(post, delete, etc). We can organize them into hooks as well.

// MainPage
const MainPage = () => {
  return (
    <RequestConfig value={{ fetcher: fetch, suspense: true }}>
        <UserPage />
    </RequestConfig>
  )
}

// usePostRequest
const usePostRequest = (url, config) => {
  const { fetch } = useContext(RequestConfigContext)
  const [loading, setLoading] = useState(false)

  const execute = () => {
    return fetch(url, { method: 'POST', ...config }).finally(() => setLoading(false))
  }

  return { loading, execute }
}

// UserPage
const UserPage = () => {
  const {data: user} = useUser('123')
  const { loading, execute: apiAddUser } = usePostRequest('/user/add')
  const { loading, execute: apiDeleteUser } = useDeleteRequest('/user/delete')

  const addUser = async () => {
    await apiAddUser({ username: 'john' })
  }

  return (
    <button disabled={loading} onClick={addUser}>Add</button>
  )
}

But I still figuring out is that worth to do this? 🤔

[shuding]

Love 1 and 2, but I'm not that convinced by 3.

It is true that as a handy and tiny helper hook, usePostRequest simplifies some things, but it's more like a "grammar sugar". With it we don't need to create loading/error states over and over again, but it only simplifies my existing code, and doesn't provide me more power like what SWR does for GET requests (focus revalidation, for example).

We got a lot of questions about using SWR with POST requests, but I still don't know how SWR (stale-while-revalidate) can help us improving the POST experience (maybe SWR mutations can help here, but not the useSWR hook). Of course we can include a small hook like useAsync (https://usehooks.com/useAsync) in this lib and we can solve the "how can I use SWR with POST requests" problem, but I don't think that's something we should do.

Anyways, it is still very helpful and I'd love to use the usePostRequest pattern personally! And meanwhile, we should keep improving documentations/examples on explaining concepts about SWR mutations, POST requests, etc.

[sergiodxa]

@shuding I built a useMutation hook to implement the usePostRequest pattern, in case you want to try it, I think the main benefit is that the same way you can create a useTweet to fetch a single tweet you can create a useCreateTweet to abstract away how to POST to the API, this same hook could also define easily what SWR keys to revalidate on a successful request (e.g. revalidate list of tweet and single tweet) so you don't think anymore about that, your just

const [createTweet] = useCreateTweet()
// code here...
createTweet({ body: "My tweet" })

That's all, and the useMutation hook give you a safe way to define all of these actions to happen on certain events, including optimistic UI with a rollback for failure, eventually this useMutation could also implement other patterns like retry on error, or implement background sync when using optimistic UI

[wanliyunyan]

@Kexin-Li the response data for <Seclect> component will not change, and can be obtained by one request, why use swr to trigger the request multiple times.

[sergiodxa]

1. I tend to use SWR for everything, but if you know you will never want to update some value, it could make sense to fetch it once, store it in a state and share it through context.

2. That is common, it's because SWR is revalidating on focus, and if you open your devtool your focus will move between the devtools and your app, so everytime you focus again in the app it will trigger more request, you can disable it with revalidateOnFocus: false.

3. I think the best way to solve this is to cache the data.

4. I don't see a reason to do not do it, actually it makes a lot of sense to use SWR to fetch data for a graph, this way your graph will keep up-to-date, what you may want to do is to useMemo to memoize complex calculations you may do on render, so if the data haven't changed you are not recalculating everything.

[wanliyunyan]

I have another question. How to trigger revalidate after I modify.These are two different components

[sergiodxa]

If you know the key you can call mutate(key) and that will trigger a revalidation. Another option is to make your components fetching that data read from a context of the region and use it inside the key.

function Data() {
  const region = useRegion()
  const {data} = useSWR(["/api/data", region], getDataForRegion);
  // use data
}

This should create a new key per region.

[wanliyunyan]

@sergiodxa

Perhaps the smallest change is to refresh the page，i choose window.location.reload(). The workload is too great, because all pages are related to the region, if i do as you say ^_^

[nahasco]

Not the best question, but how can I cache the data?

[wanliyunyan]

Thank you everyone. My English is very poor, so some words misunderstood you, and i will not send post/delete request buy swr .Especially thank you @sergiodxa