#Green a server function which uses an
short drift
This is a server component, in order to add interactivity you will also need a client component. The load function and all related logic will need to go in a child component that's use client, you pass in the initial 4 items as prop and go from there.
https://nextjs.org/docs/getting-started/react-essentials#client-components
opal surge
won't the client component expose the api key though?
short drift
You can create a route that proxies the data fetching for you. https://nextjs.org/docs/app/building-your-application/routing/router-handlers
opal surge
hmm so this way even if i make the whole app client side, it won't expose the api key?
short drift
You would be interacting with your own API which would then perform the call on the server for you and passing through the result. So the API key would never leave the server.
Somewhere in the docs it also recommends explicitly declaring "use server" in files that contain information that you never want to expose to the client so that it will prevent you from unknowingly doing so.
I was wrong, it's not use server, but server-only for that: https://nextjs.org/docs/getting-started/react-essentials#keeping-server-only-code-out-of-client-components-poisoning
opal surge
I see... thanks, also do i have to use some kinda function to update the contents of the yellow div? or just modifying the list(from which it maps data to html) would be enough?
short drift
Just modifying the data will be enough, it's client-side React so it will rerender automatically.
Personally I would look into swr or @tanstack/react-query here. It has a couple of advantages: (1) you'll be able to pass in your initial data and (2) it caches the data client side so if the user navigates away and comes back later the subsequent page fetches will still be there.
opal surge
next13 does the 2nd part so ig i don't want to learn a new module before i grasp nextjs as a whole
short drift
No, the data on the client side will not be cached by NextJs, only the server calls.
opal surge
Hmm, but isn't fetching a server call, so what's the use of caching client data if it's based on what the server responds with?
short drift
It's for subsequent client-side navigation. The initial data is provided by the server on the first page load, but when the user goes to page b and then returns to page a that data is on the client.
short drift
That's the intention, but by navigating away from Page A the Page component will be unmounted, so everything you have there in local state will be gone as well.
That's where the client-side caching from swr or @tanstack/react-query comes in.
But I may be getting a bit off-track here. I'd start with the original implementation as discussed and when you starting navigating the website it will make more sense and you can then decide if it makes sense for you to cache your client-side calls or not.
opal surge
Well I'm using vercel's database kv might consider caching data if retrieving data would take alot of time
wait why isn't this working?
short drift
It's not /api/route, it's /api, same convention as your page.tsx.
short drift
There are a couple of steps to take of course. Without any information it will be hard to debug. Don't forget that /api is just a route like any other, so you can also access it from the browser to see what it returns.
opal surge
There are a couple of steps to take of course. Without any information it will b...
it works perfectly
yet, when i fetch it....
here's the route.js
short drift
I don't immediately see any issues there
fetch may be struggling with the relative URL. Can you try an absolute URL?
opal surge
that works, why so?
short drift
Just the way fetch works, it expects a valid URL.
opal surge
Sed