#Is it possible to prevent a dynamically
1 messages ยท Page 1 of 1 (latest)
Maybe my composition is wrong. Because the reason for changing the url is to pass SearchParams to the ArticleContainer to render articles depending on the active tags in the DataSearch component.
so u want to stop the server side data fetching when u open a specific route ?
Essentially I want it to run only once, at the first render.
im bad at english so bare with me
At first render? like hard refresh?
so skip data fetching on soft and hard navigation?
Only solution I've been able to come up with is to set a cookie that checks wheter to run the data-fetching methods.
Exactly, @coral grove
you can check the header to differentiate those kind of navigation
i can imagine a weird implementation tho. like use redis as cache and if there is cache stop the data fetch ig (or i didnt understand the question)
I still think my composition is poor, somehow. Managing global state with url search params isn't exactly great
I just feel like the ArticleContainer should be server side rendered
This is the code to differentiate those navigation
now I do not know if this would solve your issue as a bigger picture
my guts says that you don't need this if you set it up properly
Yeah, I have the same gut feeling.
How would you solve it though?
I have a client side search component that sets state from the chosen tags:
So on every tag change my url changes (doesn't have to)
Then I need to render the server component with the articles based on the chosen tags
Id put my route processing in a layout and leave the page empty :))
idk i havent experimented with it
also whats that neat label showing server/client comp?
Okay, I though about that, but the layout doesn't have access to search params
they do on client
and if you process it in client, I THINK (experiment needed) SSR would be minimal
not client-side layout
client-side component inside a layout.tsx
did you made the server/client component label thingy btw
No, that's copy pasted from the code for this: https://app-router.vercel.app/
This one
what about this?
So let me see if I understand you correctly.
Server side Layout, client side DataSearch within Layout. But then would the ArticleContainer be server side or client side?
also client
That's just data I use for debugging my search:
also client, coz you lose the privilege to ~~Serverside ~~ static render if you don't know what the searchParam is gonna be...
Okay, I kinda wanted to preserve that privelege :\
then dynamic render page on route change is inevitable ๐
I don't need it to be statically rendered. Dynamic is fine, but I would like for it to render on server
Rather than in the client
so whats this all about?
Is it possible to prevent a dynamically rendered page from running it's data fetching methods on route change?
Well, I want the searchParams to change, which they do, but I do want to prevent re-running the data-fetching methods.
They are there only for the first page load, really. So that when someone pastes a url with search params, those things are fetched. But when you do navigation afterwards, such as by choosing a new tag in the search, then I want the data-fetching to be prevented.
Because, as I said, it's just initial data
It's a bit hard to explain, probably because it's a stupid concept
And I'm doing it wrong
ohhhhh so all the unfiltered data is already on the page.tsx?
and the searchquery on filters the unfiltered data?
so the filter is done client-side not server-side?
Yes
Essentially I want to send client side state to the server, which I know is not usually possible
Except maybe through url params
I dont think thats what you want. You just want to filter the given data from the server in the client
i.e the filtered data is the subset of the whole fetched data. not like a paginated result
Hmm, not exactly.
I have two indexes on Meilisearch, one is called "Data" and one is called "Articles".
In DataSearch I choose items from "Data", those items are then used to find items from "Articles"
So there are two searches happening, basically
How do you display the data if data-fetching is prevented upon choosing a new tag?
client-side fetching? client-side filtering?
On page load an empty "Data" search is prefetched and all "Articles" are prefetched too
When I choose a new tag two things happen:
- Through Jotai an atom with
activeTagsis updated. - The URL is updated with for example
team=rosenborg
right so its a client-side filtering from the prefetched data
Would it help if I streamed to you?
im uncomfortable with that :D
The interaction is done client-side, and I have an atom that uses tanstack-query to fetch from my api route api/searchData
yeah you could use this then
HAHA
wrap the function to prefetch data with const data = onPageReload()
so that it is only prefetched at hard refresh
Great! Where is this code from?
homebrew
what's that?
this is the implementation
I made it myself
Ah, cool
its inspired by cache() from react
I guess the notFound stuff is unecessary for me
Ofc, im just sharing how i did it, nodify it to best suits ur needs xD
Just know that on soft/navigation the header ssc-fetch-dest is not equal to document
Which.. part...?
headers().get("sec-fetch-dest") === "document";
What is this actually doing?
I should look into nextjs headers more.
Sec-Fetch-Dest
indicates the request's destination. That is the initiator of the original fetch request, which is where (and how) the fetched data will be used.
Hmm
Each route change sends a request to the server
Each request sends to the serve rhas headers attached to it
headers() is a server funtion to get headers of request
So i checked how navigation and hard refresh can differentited on the headers
Idk what sec-fetch-dest is
Soft/hard navigation doesnt send the sec-fetch-dest : "document" upon investigation
I mean i could look it up on MDN web docs but idk how Next.js uses them for soft/hard navigation xD
It really is xD
There really should be more info here:
https://nextjs.org/docs/app/building-your-application/routing/linking-and-navigating#soft-navigation
But there isn't
Anyway, you just saved me a lot of work, so thanks a lot