Next.js Discord

Discord Forum

refresh page server server side

Answered
PepeW posted this in #help-forum
Open in Discord
Avatar
I have the following situation:

// page.tsx
export default async function CartDeliveryPage() {
  const cart = await getCart()
  return (
    <>
      {cart.items.map((item, index) => (
        <ChooseDelivery item={item} />
      )}
    </>
  )
}

// ChooseDelivery.tsx
export default async function ChooseDelivery({item}) {
  await updateDeliveryMode({ shippingMethod: item.shippingMethod })
  return (
    ...
  )
}


Basically I fist get the cart, then for each item in my cart I update the delivery mode.
The problem is that after I update each delivery mode, I want to trigger a getCart() again to get the updated cart containing now the delivery modes.

What would be a clean way to handle this situation ?
Answered by Eric Burel
in a backend for frontend paradigm you need to aggregate data before hand, so getCart should have the info
View full answer

45 Replies

Avatar
up
Avatar
not enough info here but maybe router.refresh()
supposing what you want is a client-side update
this will download an up to date RSC payload
could be easier to use client-side state too
Avatar
Both my page and my component are server components so I would like to keep everything in server components if possible
Avatar
use a server action for the update then
btw what are you doing actually?
didn't notice that the update was a side effect of your RSC
is there a reason for that?
Avatar
The thing is that updateDeliveryMode() returns nothing.

So I need to getCart() again or as you suggested do a revalidatePath("/cart/delivery").
Of course the revalidatePath seems to be the cleaner option but unfortunately it doesn't trigger the getCart() after the updateDeliveryMode()
Avatar
We don't get why you run updateDeliveryMode() while rendering your component
normally this is for side effects that do not have any effect on the render so no need for a refresh
eg increase a view count in a blog
just move the updateDeliveryMode side effet upper
Avatar
I run updateDeliveryMode() so my cart get the delivery modes inside of it and when my page is rendered I can display all the delivery modes but more importantly the default ones (thanks to the updateDeliveryMode())
Avatar
you shouldn't get data from them
sorry for recommending that too
I mean, maybe for the side effect
yeah I was double checking Lee Rob blog and he uses an action for counting views
in a slightly similar fashion
I remember talking about this issue of fetching data requested by a child component when RSCs were released but sadly lost track of it... anyway moving the update items within cart in the parent component like you recommended is the way to go
Avatar
I don' t get why we use a server action. We are already in a server component
revalidatePath() only works in server actions ?
Avatar
if it has a side effect then it's a server action indeed, if it just fetches data it doesn't
basically server actions = POST http verb
not a server action = GET
GET should not have side effects ideally
POST should not be used to get data ideally (POST cannot properly cache stuff at infra level)
though I might oversimplify
but do you use revalidatePath here?
Avatar
Ok I get it.

And last thing, does revalidatePath() rerender the server component like a router.refresh() would do it client side ?
Not now but I will following your suggestions
Avatar
ok ok becasue that would have been weird to have revalidatePath
the code is still weird to be fair, having updateDeliveryMode called for each item this way sounds off unless I am missing something
Avatar
Ideally updateDeliveryMode should return the cart
And even better my backend should handle all of that
But I agree that's weird.
I'll have a discussion with my backend team
Avatar
in a backend for frontend paradigm you need to aggregate data before hand, so getCart should have the info
Answer
Avatar
Yep
if you need to fight the backend people ^^
Avatar
Anyway thank you guys
Avatar
sorry to hijack the thread, but I have been researching this topic for a couple of days now and I have to wonder:

Wouldn't the extra "hop" in the request chain (browser -> Next -> API -> Next -> browser) add some performance overhead to every request?