Use resource routes for all data fetching ?

[Burzmalian]

What are the downsides if any, of creating resource routes for all your data operations and reusing them throughout the app where you need them? Instead of repeating the same loader or action.

[sergiodxa]

You would need to fetch them, instead of just calling a function in your loaders and actions that can be shared and avoid a network roundtrip.

[Burzmalian]

@sergiodxa thanks! so doing data fetching like this would require a network roundtrip when those fetchers are called? Could you expand on that a bit how using a loader/action in the route is different from using them in a resource route from a network perspective?

[Burzmalian]

I think I understand, if a route calls a fetcher that is 2 network trips, one for the route and one for the fetcher.

[sergiodxa]

If you're fetching the resource route using useFetcher, this only works client-side instead of server-side, so the flow would be:

1. browser sends document request to get the HTML
2. server runs your route loader and render to HTML the UI
3. browser renders the HTML, loads JS, parse it and execute it
4. React hydrate your app client-side
5. hooks run and here useFetcher starts the requests (another round trip)
6. server receives requests in your resource routes
7. server send responses from resources routes
8. UI is updated with new data from fetcher.data

Note that any data from those resource routes is not server-side rendered, essentially you're building a traditional SPA.

Another option is that your server loader fetch your resource route loaders, this is slightly better.

1. browser sends document request to get the HTML
2. server runs your route loader and render to HTML the UI
3. route loaders fetch the resource route loaders (another round trip)
4. server send back the resource route loaders data
5. browser renders the HTML, loads JS, parse it and execute it
6. React hydrate your app client-side

There are less steps here, and now your resource routes data is being server-side rendered, but you're still doing another round trip to get the data, just that this times it happens from your loader, so while a server-to-server request is better than a browser-to-server requests, it's still not ideal.

The best, and probably simplest, way to do this is to just get the data you need in the route loaders.

1. browser sends document request to get the HTML
2. server runs your route loader and render to HTML the UI
3. browser renders the HTML, loads JS, parse it and execute it
4. React hydrate your app client-side

This way you're getting the data you need in the server, and you're server-side rendering it, so you're not doing any extra round trips to get the data you need.

And if what you want is to share the logic to get this data, you can use a function, let's say you want to share the logic to get the data of one user using its id, you can do something like this:

// app/models/users.ts
export async function getUserById(id: string) {
  // here do your DB query
}

Then in any route loader or action where you need to get the data of one user using its id, you just import and call that function, no need to do a network request to your own server or do it client-side.

---

By the way, a last option could be that instead of doing a network request you could import the loaders of the resource routes and call them as functions, while it works you will need to create a fake Request object, ensure you pass the correct params object, and then parse the Response body, while calling a function would be simpler.