bro like how can you directly get data from your db. Like it is possible in next js but doesn't means that you should do that

Because the only correct way to fetch data in next js is using fetch api

or like any other library

even using server actions to fetch data is not a correct way

and you are just querying through the db inside your component.

like its my humble advice that you should create an api to fetch the data

You have no idea what you are talking about. Not only, do you come into a thread and answer something completely different than the topic, you are also totally wrong in what you are saying.

Next.js uses react server components per default. This data is fetched, and the pages are built on the server (SSG per default).

Can you try export const revalidate=0

Or worst case u can do revalidatePath or Tag everytime u open the page

hi, is this a doubt or you really did observe that next cached it? exporting dynamic as force-dynamic should be enough to make it server-rendered for each request

or is this component a child component of the root page.{tsx,jsx} component? given that the component name is Hero

Try moving the

export const dynamic = "force-dynamic";
export const fetchCache = "force-no-store";

to the page.tsx file

^ if it does occur that Hero is a child component of page/layout.tsx file

I agree with Duraid, what you have is kind of bad practice. It'd be better to pass a hero argument into your component, and fetch it outside the component, like in the page.tsx file. It'd still be server side rendered

i would have to disagree on that one :)
components fetching their own data makes it easier for it to be split into it's own <Suspense> chunk.
fetching the hero data on the main page.tsx file would block the entire page from rendering, it's a good practice to move the fetching onto a child server component to fetch the data independently so you can separate it to load as its own component in a <Suspense> boundary

You can use several suspenses in page.tsx for several components that will stream data to the page when the data is ready

the page doesn't wait for all suspenses to complete before rendering them

But regarding my comment about moving the cache disabling to page.tsx, I think you have to do that because in NextJS you disaable a cache on a route, not on a specific component

yes that is the case when the promise isn't awaited, you can pass promises into individual server components wrapped in a <Suspense> and have it be able to do the same thing as if they were fetched independently.
i thought you weren't taking suspense into account, if you were to have an await on the top-level page.tsx, it would make everything else wait until that promise is resolved.

i kinda forgot this pattern, but the OP can use either, both will work just fine :)

Right both will work the same. It's just fetching things from the DB within a single component can lead to some un-manageable code in the future. That is, you'll end up adding arguments to the component such as dontFetch: boolean

it's better to fetch the data outside, and pass in the data as arguments to the component

out of curiosity, on what occasion do you need a dontFetch parameter? i have played around with next for a while, and not sure where and when that "workaround" will crop up?

It comes down to re-usability. The components should be re-usable. As the application grows and you use the component in other areas, there will be times where you don't always want to fetch the data when the component is getting rendered. I know this because the fetch from the DB is a side-affect of rendering the component, and as an application grows things pop up where you need to supress the side-affects, or delay them

Here's an example: I reuse this component and I end up rendering it 20 times on my page, because I want 20 instances of it. That will cause 20 hits to the database. I don't want 20 hits to the database, I want one hit. So I add an argument to compensate for that

It already has side affects, and to compensate you have to make the component even more complex with more arguments

ah thank you! i wasn't working on projects with a lot of server components, haven't experienced such roadblock before. thanks for the insight

i guess the general rule of thumb is to keep side effects to a minimum for components that only displays some data

Here's another use case. Since the data is fetched from the DB within this component, the data HAS to already be in the DB in order to render this component. That couples the data source to the component. That means in the future you can't allow the user to build their own Hero, and supply the data to the Hero component elsewhere. No, in order to render a Hero that data must first be in the DB.

that use case of "building their own hero" is pretty specific and may never pop up, but by coupling the data source to the component you've limited its reusability

I will only use this component at one place.

Did anyone have a suggestion how this can be not cached btw?

I think you need to move the cache options you have to the page.tsx file

Hey. I face the very same problem right now. Would be great if you found a way to go and can share it here.

I think I solved it by going back to the page.tsx, because caching doesn't happen at the component, instead only at the page level.