How would you manage data fetched from the server that needs to be mutated on the client side?

[djmin43]

Problem

I am creating a simple discussion board with bunch of posts and a 'like' feature like youtube or facebook. I am using Nextjs app dir for the framework and RTK Query for data-fetching and data-caching from the server.

I want to fetch the data of a post from the server using 'fetch' because I want to build the page ahead of the time. At the same time, I want to mutate some information of the post data, such as mutating the count of 'like.' (with optimistic update preferrably)

How would you architect or manage this use case in the most elegant way possible? Let's assume I am working with a single api call that includes post content and the count of likes.

Possible ways to solve

1. Forget about RTK Query, use Nextjs all the way with 'fetch' and 'server action'.

• This is the most 'Nextjs' way possible to solve the issue.
• The drawback would be I don't take advantage of the feature-fullness of RTK and RTK Query.
• I don't think optimistic update is possible in this case unless I move the like button and logic to the 'use client' land.

2. Fetch data from the server for the initial data, then fetch the same data on the client with RTK Query.

• This should solve most of my problems: SEO, fast initial render, and RTK Query client-side state management.
• I am not sure calling the same api call twice is what I want.

3. Fetch data from the server, then store the data in redux store.

• I personally wouldn't do this because this doesn't guarantee the data in the client-side is truthful.

Notes

• Of course I checked out this RTK Query page with Nextjs. The document itself was pretty helpful, but I couldn't find the answer I wanted. If I missed the point, please let me know. https://redux-toolkit.js.org/usage/nextjs
• In the 'old' Nextjs pages land, I could fetch data with getServerSideProps, initialize the state, and could re-hydrate on render. I can't seem to think of the most 'elegant' way to handle 'fetch from the server and mutate on the client' in Nextjs + RTK Query combo.

Please feel free to give any suggestions or feedback. I am sure this is not RTK Query only problem, but rather the new wave of RSC and Nextjs app dir problem. I understand where they are heading, but I just don't want to give up the power of RTK Query or other client-side libraries, really.

Cheers.

[robahtou]

I'm in the middle of something similar to the stated problem. We are using the latest next.js with redux but we are questioning if RSC adds more complexity to how the mental model of redux operates. In other words, you can make it work just like you can hammer a square into a circle.

This boils down to:

1. caching
   What is your caching strategy? You can cache on the client and/or the server
2. fetching
   What is your fetching strategy? You can fetch on the client and/or the server

In your RSC, fetch your data from the db and pass it to your components to render on the server. If you can get calculate the 'like' in the server you'd want to do that there, and pass the final 'state' to the components to render them completely.

Assuming that that is not what you want and you want the 'like' to be dynamic, then that component will necessarily need to be a client component that get's it initial 'like' data from the server and then proceeds to periodically fetch data on the client to update the 'like' value. But this negates your 'single api call' to do both. Which is alright, since you'd want to split up the logic/calls for fetching posts and fetching likes.

Fetch the 'post' data on the server and render your <Post data> components on the server. The <Post data> component contains a client-component <Likes> that dynamically & periodically pings the server for any updates. You can cache the initial 'post' data and set a revalidation interval. The same for the <Likes> component fetch api. The initial 'post' data will be cached on the server, and the 'likes' data would etiher have a short lived cached, no cache, or some other revalidate cache logic on the client.

If you have to use a state management library, and you fetch data from the server to store in a redux store, you're going to be wrestling a bit until you find a pattern that works for you, and well, mostly just works (hydration issues). In general, I think this is a progressively hard problem: fetch the data in the server and store it on the client. I'd start with useContext to get a feel for how components are connected and reacting to each other. But as soon as ComponetA state in page /accounts can be updated by ComponentB on page /accounts/1234asdf, you'll have to reach for something else, like redux, and now you've entered into uncharted territory where the server fetching data and client component state management mental model diverge: syncing data since there is no state on the server.
React initially renders a component and then runs 'useEffects'. If you fetch the data on the server and pass it to a client component, the client component then has to 'dispatch' the data at the top of the component (sync). In the client component you'll have a 'isLoading' state waiting until the redux store is populated (assuming the component down the tree will be calling redux for their state) before you can proceed to render. And in that case, there is no pre-rendering the component on the server.

I haven't found a pattern that I like but I do have something working for now. The concepts of rendering components on the server and storing state on the client are appear orthogonal from thirty thousand feet. But on closer inspection, there is overlap and there are solutions to it but like I said initially, you can make it work just like you can hammer a square into a circle.

N.B. useOptimistic is client-only, so if you want to use that you have to compromise