Using SWR in routeRules without cookie

[andrewspy]

I'm new to SWR routeRules, it is possible to use SWR strategy without 'set-cookie' header in the response on cached request, so that it doesn't override the current request's cookie?

[pi0]

Hi dear @andrewspy. When you enable any of caching strategies, (incoming) headers are totally ignored and req.headers is an empty object.

But not in response. Why you are setting set-cookie in a cached handled that requires to be removed?

[andrewspy]

Hi @pi0. In my context, I'm using nuxt3 with firebase hosting / cloud functions, where special __session cookie is permitted to pass through to the cloud functions to take advantages of the CDN (https://firebase.google.com/docs/hosting/manage-cache#using_cookies).

I was using SSR previously and it works flawlessly, just wanted to explore SWR, but didn't know req.headers are ignored completely in SWR. I suppose SSR is better suited for my use case.

Thanks for the explanation.

[pi0]

Perfect thanks for explaining. Since with cached behavior we expect users get same response, i think we are good. Feel free to raise an issue for firebase preset btw if you feel it is something worth to consider supporting.

[andrewspy]

For context, I'm actually using __session for theme (i.e. light/dark) and i18n for optimum SSR experience. Not sure if others have a similar use case. For now, I'll stick with SSR.

Thanks!

[awacode21]

I have the use case of an e-commerce website were I want to handle specific routes like the home or others with swr: true. But within the header there is the basket and the login button which relate to user data. When using swr these parts are no longer working as based on Session cookie. Do you have an idea how to make that work with swr, or is there absolute no way? We would like to use it for performance reason. With SSR still have long Server response time even if we optimized nearly everything. With Swr we get dream values

[milelazar]

@awacode21 have you find a solution? I have exactly the same problem. With swr enabled, cookie is cleared/regenerated and user will loose cart and other specific data

[Tofandel]

@awacode21 What I do in my app, is simply to have it not try to load the cart in SSR so only do your stateful useFetch in a if (import.meta.client) . Handle the case that you won't have cart data until after hydration and that's it.

const prs = [];
// We won't have reactivity issues since on the frontend those variables become ref straight away
// and on the backend reactivity does not matter
let cart = undefined;
let wishlist = undefined;
if (import.meta.client) {
  const {fetchWishlist, data: wishlistData } = useWishlist();
  const {fetchCart, data: cartData} = useCart();
  cart = cartData;
  wishlist = wishlistData;
  prs.push(fetchCart(), fetchWishlist());
  onMounted(() => {
    document.dispatchEvent(new Event('hydrated'));
  });
}

await Promise.all(prs);


const cartLineItemsCount = computed(() => cart?.value?.itemsCount ?? 0);

SWR and user state do not mix. It would be a security issue to let them mix. Otherwise when a user visits, his cart and other information would get cached for other users to see.

So either make the request on mounted or stick with SSR.

If your whole interface/data changes if user is logged in, don't use SWR, if it's only a small part of your UI, then you can use SWR with the caveat above.