Dialog with on-demand server data and RSC
Unanswered
Barbary Lion posted this in #help-forum
Barbary LionOP
I have to implement a couple of features in my app I'm struggling to find the idiomatic way of doing it with RSC. They're both similar patterns.
In the first scenario, I need a list of elements (let's call them E1) and I need to be able to select some of them, open a dialog (this is the important part, when the dialog opens, it fetches a list of other elements E2), select some of the new elements and do a server call to attach the selected E1 to the selected E2. The last request is a server action, but what about the GET request to populate the E2 list within the open dialog?
In the second scenario, I have another dialog with a search input, and typing into it will fetch some data to populate a list of results.
In both scenarios, I thought about providing the full list every time beforehand, but it seems very wasteful. I only want to do these requests when the dialogs are open, and these dialogs are open on demand client-side, with no changes or state stored in the URL (as they're transient operations).
What's the idiomatic way of doing this with RSC?
In the first scenario, I need a list of elements (let's call them E1) and I need to be able to select some of them, open a dialog (this is the important part, when the dialog opens, it fetches a list of other elements E2), select some of the new elements and do a server call to attach the selected E1 to the selected E2. The last request is a server action, but what about the GET request to populate the E2 list within the open dialog?
In the second scenario, I have another dialog with a search input, and typing into it will fetch some data to populate a list of results.
In both scenarios, I thought about providing the full list every time beforehand, but it seems very wasteful. I only want to do these requests when the dialogs are open, and these dialogs are open on demand client-side, with no changes or state stored in the URL (as they're transient operations).
What's the idiomatic way of doing this with RSC?
31 Replies
American Crow
I think you already mentioned all the options ( prefetch, query params in url) if you want to force RSC.
For me this is a clear use case of using a client side fetch.
For me this is a clear use case of using a client side fetch.
But let's wait what others (smarter) people than me think here 🙂, good question btw!
Knopper gall
Can I ask why you're hell-bent on using RSC, just before I present an answer
Barbary LionOP
i guess i feel that there's a missing part of the story here
you can use RSC for most of your fetched data, and use server actions (another novel concept) to mutate that data
but there's no clear guidelines for doing what i'm trying to do, which is a very common thing IMO
so now, if you want to do a client side fetch with good dx and even suspense, what do you do? manually, swr, react-query...? i feel there's no integrated solution for this and i was wondering if i was missing something obvious
you can use RSC for most of your fetched data, and use server actions (another novel concept) to mutate that data
but there's no clear guidelines for doing what i'm trying to do, which is a very common thing IMO
so now, if you want to do a client side fetch with good dx and even suspense, what do you do? manually, swr, react-query...? i feel there's no integrated solution for this and i was wondering if i was missing something obvious
@Barbary Lion i guess i feel that there's a missing part of the story here
you can use RSC for most of your fetched data, and use server actions (another novel concept) to mutate that data
but there's no clear guidelines for doing what i'm trying to do, which is a very common thing IMO
so now, if you want to do a client side fetch with good dx and even suspense, what do you do? manually, swr, react-query...? i feel there's no integrated solution for this and i was wondering if i was missing something obvious
Knopper gall
Yeah I get where you're coming from, I was just struggling to understand why all this needs to be RSC focused that's all, is it for caching?
Now I would actually go about this a different way, I'd be considering using server actions to query the modal data and populate it
It's not actually very well known that server actions are not limited to forms, they can be called anywhere in a client component
If you need to share the state with other users, you can use URL parameters, but it's important to ask the question "if I share the link, should the other user see exactly what I see on my screen", if the answer is yes, then URL params are the answer, if no, client-fetch is the answer (I prefer server actions, but trad API fetch is a great solution too, as you can specify cache rules)
Now I would actually go about this a different way, I'd be considering using server actions to query the modal data and populate it
It's not actually very well known that server actions are not limited to forms, they can be called anywhere in a client component
If you need to share the state with other users, you can use URL parameters, but it's important to ask the question "if I share the link, should the other user see exactly what I see on my screen", if the answer is yes, then URL params are the answer, if no, client-fetch is the answer (I prefer server actions, but trad API fetch is a great solution too, as you can specify cache rules)
American Crow
To me server actions are never a tool for getting data. I read something about them being queued 1by1 and that's why they are ACTIONS. Don't remeber all the details though. Open for discussion ofc
@American Crow To me server actions are never a tool for getting data. I read something about them being queued 1by1 and that's why they are ACTIONS. Don't remeber all the details though. Open for discussion ofc
Knopper gall
Yeah, think of server actions as things that should be the result of an interaction, not a side-effect.
I have an issue open regarding this.
https://github.com/vercel/next.js/issues/64396
I have an issue open regarding this.
https://github.com/vercel/next.js/issues/64396
It really depends on use case
Barbary LionOP
yeah, from my research, it seems that officially using server actions for get is not recomended, which makes snse
caching is one of the issues indeed, and it's an important one
also semantically it doesn't make sense to POST to just get some data
and finally, server actions (or a client side fetch) doesn't give you RSC back, which would be ideal (if it's good for a page, why can't we do the same for a part of the page?)
and indeed, coupling this logic with the URL is not ideal for two main reasons:
- it's a transient operation, there's no need for sharing this info with other users, for instance
- opening the modal must happen instantly, if it's driven by the URL, you'll notice a delay and it won't be a good experience (of course you can probably avoid this with extra side client state, but then it gets messy and not an elegant solution)
caching is one of the issues indeed, and it's an important one
also semantically it doesn't make sense to POST to just get some data
and finally, server actions (or a client side fetch) doesn't give you RSC back, which would be ideal (if it's good for a page, why can't we do the same for a part of the page?)
and indeed, coupling this logic with the URL is not ideal for two main reasons:
- it's a transient operation, there's no need for sharing this info with other users, for instance
- opening the modal must happen instantly, if it's driven by the URL, you'll notice a delay and it won't be a good experience (of course you can probably avoid this with extra side client state, but then it gets messy and not an elegant solution)
American Crow
also semantically it doesn't make sense to POST to just get some data tell that to GraphQL 
j/k gonna wait for some more input on this thread its a good quesiton as already mentionedKnopper gall
I'm interested to see how this thread pans out to be honest, there's really a number of cons to every solution I can think of, and has been presented so far
@American Crow But let's wait what others (smarter) people than me think here 🙂, good question btw!
Knopper gall
+1 for good question
American Crow
let's upvote this at the top
Knopper gall
I've just done some testing, and whilst server actions don't return RSC, they do return JSX
So you could have the modal window show on click, call the server action (which would render a skeleton with useTransition), then display the modal content, which you could populate inside the server action, imitating a RSC
So you could have the modal window show on click, call the server action (which would render a skeleton with useTransition), then display the modal content, which you could populate inside the server action, imitating a RSC
but then it's not entirely a RSC app, you still manipulate the DOM using the server action, although you could get around this by returning serialised data
@Barbary Lion I have to implement a couple of features in my app I'm struggling to find the idiomatic way of doing it with RSC. They're both similar patterns.
In the first scenario, I need a list of elements (let's call them E1) and I need to be able to select some of them, open a dialog (this is the important part, when the dialog opens, it fetches a list of other elements E2), select some of the new elements and do a server call to attach the selected E1 to the selected E2. The last request is a server action, but what about the GET request to populate the E2 list within the open dialog?
In the second scenario, I have another dialog with a search input, and typing into it will fetch some data to populate a list of results.
In both scenarios, I thought about providing the full list every time beforehand, but it seems very wasteful. I only want to do these requests when the dialogs are open, and these dialogs are open on demand client-side, with no changes or state stored in the URL (as they're transient operations).
What's the idiomatic way of doing this with RSC?
I would use parallel or intercepting routes for scenario 1.
@dialog/[selected]/page.tsx
and just basic html form with get method for scenario 2
@dialog/[selected]/page.tsx
export default async function Page({ params }) {
const elements2 = await fetchElements(params.selected)
return (
<form action={}>
…..
</form>
)
}and just basic html form with get method for scenario 2
Barbary LionOP
thanks, ray - i thought about that but as mentioned before, isn't it true that here opening the dialog won't be instant?
@Barbary Lion thanks, ray - i thought about that but as mentioned before, isn't it true that here opening the dialog won't be instant?
you could make use of
loading.tsx to make the dialog open instantlyKnopper gall
I think Ray's answer is the best.
There's actually a demo of the behaviour you're looking for in this video
https://www.youtube.com/watch?v=RKszSrtWqjA
There's actually a demo of the behaviour you're looking for in this video
https://www.youtube.com/watch?v=RKszSrtWqjA
@Ray you could make use of `loading.tsx` to make the dialog open instantly
with prefetching enable in prod build, it should open the dialog instantly
I have done that before
Barbary LionOP
cool, so i'll try this in the next days and follow up here when i have some feedback
this is a solution that i contemplated before but discarded because i wanted a modal but not a whole page with the content of the modal (think about the instagram example, where you intercep the detail page in a modal, and go to the full page on refresh) - here we wouldn't be intercepting anything, just opening the modal on demand
and i also still think that this pattern forces me to have a shareable URL when i don't actually want that, and it also forces me to have query params related to the main page behind together with the ones for the temporary modal - i find this a bit messy as well and will refresh the page behind unnecessarily
but even with these caveats, it does seem like the idiomatic way of doing it
this is a solution that i contemplated before but discarded because i wanted a modal but not a whole page with the content of the modal (think about the instagram example, where you intercep the detail page in a modal, and go to the full page on refresh) - here we wouldn't be intercepting anything, just opening the modal on demand
and i also still think that this pattern forces me to have a shareable URL when i don't actually want that, and it also forces me to have query params related to the main page behind together with the ones for the temporary modal - i find this a bit messy as well and will refresh the page behind unnecessarily
but even with these caveats, it does seem like the idiomatic way of doing it
Knopper gall
oioi
@leerob started following this thread, that's how you know it truly is a good questionAmerican Crow
That has other reasons pepeLaugh
@Knopper gall oioi `@leerob` started following this thread, that's how you know it truly __is__ a good question
no, I think its because OP pinged he
American Crow
pssst
Barbary LionOP
yeah, i'm sorry about that - i should have read the rules/guidelines before doing that, it won't happen again
Knopper gall
just a bit of humor dw
Barbary LionOP
but thanks all for the callout and for engaging in the post