Epic Web Conf regular tickets are available now!

Prices go up soon

Join the community and network with other great web devs.

Time's up. The sale is over
Illustration of a microphone

Calls with Kent C. Dodds.

You call, I'll answer.

Listen to the podcasts here
Phone sitting on a stool

What's this all about?

The goal of the Call Kent Podcast is to get my answers to your questions. You record your brief question (120 seconds or less) right from your browser. Then I listen to it later and give my response, and through the magic of technology (ffmpeg), our question and answer are stitched together and published to the podcast feed.

I look forward to hearing from you!

Record your call

Calls with Kent C. Dodds Season 4 — 37 episodes

07.Remix Full-Stack Components (vs Server Components)
07:44
Keywords

remix, full-stack, components

Description

With React Server Components getting more traction, this idea of each component being able to fetch its own data seems to getting more popular rather than data-fetching being purely route-based.

In Remix-land, you’ve had a talk about “full-stack components” with a similar concept where a “resource route” can have no default exports but still export a loader and a React component in order to have a reusable component with its own data fetching.

It seems there might be differences between React Server Components and these “full-stack components” though, especially in that Server Components don’t need to be defined in routes but Remix full-stack components do.

Firstly, how are the two approaches different?

I ask, because I know Remix is working on implementing Server Components without the foot-guns, so curious what how the mental model would change in the future.

You, also said that it isn’t a good practice to get into to commonly import components from other routes.

My second question is why is it not a good practice, and can you give examples for cases where it would or wouldn’t make sense to import full-stack components from other routes?

Thank you!

Remix Full-Stack Components (vs Server Components)
07.Remix Full-Stack Components (vs Server Components)
07:44
Keywords

remix, full-stack, components

Description

With React Server Components getting more traction, this idea of each component being able to fetch its own data seems to getting more popular rather than data-fetching being purely route-based.

In Remix-land, you’ve had a talk about “full-stack components” with a similar concept where a “resource route” can have no default exports but still export a loader and a React component in order to have a reusable component with its own data fetching.

It seems there might be differences between React Server Components and these “full-stack components” though, especially in that Server Components don’t need to be defined in routes but Remix full-stack components do.

Firstly, how are the two approaches different?

I ask, because I know Remix is working on implementing Server Components without the foot-guns, so curious what how the mental model would change in the future.

You, also said that it isn’t a good practice to get into to commonly import components from other routes.

My second question is why is it not a good practice, and can you give examples for cases where it would or wouldn’t make sense to import full-stack components from other routes?

Thank you!

Remix Full-Stack Components (vs Server Components)
07.Remix Full-Stack Components (vs Server Components)
07:44
Keywords

remix, full-stack, components

Description

With React Server Components getting more traction, this idea of each component being able to fetch its own data seems to getting more popular rather than data-fetching being purely route-based.

In Remix-land, you’ve had a talk about “full-stack components” with a similar concept where a “resource route” can have no default exports but still export a loader and a React component in order to have a reusable component with its own data fetching.

It seems there might be differences between React Server Components and these “full-stack components” though, especially in that Server Components don’t need to be defined in routes but Remix full-stack components do.

Firstly, how are the two approaches different?

I ask, because I know Remix is working on implementing Server Components without the foot-guns, so curious what how the mental model would change in the future.

You, also said that it isn’t a good practice to get into to commonly import components from other routes.

My second question is why is it not a good practice, and can you give examples for cases where it would or wouldn’t make sense to import full-stack components from other routes?

Thank you!

Remix Full-Stack Components (vs Server Components)
07.Remix Full-Stack Components (vs Server Components)
07:44
Keywords

remix, full-stack, components

Description

With React Server Components getting more traction, this idea of each component being able to fetch its own data seems to getting more popular rather than data-fetching being purely route-based.

In Remix-land, you’ve had a talk about “full-stack components” with a similar concept where a “resource route” can have no default exports but still export a loader and a React component in order to have a reusable component with its own data fetching.

It seems there might be differences between React Server Components and these “full-stack components” though, especially in that Server Components don’t need to be defined in routes but Remix full-stack components do.

Firstly, how are the two approaches different?

I ask, because I know Remix is working on implementing Server Components without the foot-guns, so curious what how the mental model would change in the future.

You, also said that it isn’t a good practice to get into to commonly import components from other routes.

My second question is why is it not a good practice, and can you give examples for cases where it would or wouldn’t make sense to import full-stack components from other routes?

Thank you!

Remix Full-Stack Components (vs Server Components)

Looking for more content?

Have a look at these articles.

See the full blog