sharing-loader-data example choice justification

[NicolasCharpentier]

Just went through the interesting https://github.com/remix-run/examples/tree/main/sharing-loader-data example

Where you say this :

The app/routes/workshops/$workshopId.tsx route has a loader in it to determine whether the workshop exists. This is important and does not defeat the purpose of sharing the data. The loader runs on the server and we benefit by sharing the data because we don't have to send the data to the client.

I get the point, and I feel like you optimize for the "single roundtrip way" because :

• You throw a 404 if not found from the server.
• Where I would have redirected in the component (client-side) if parent segment does not have the workshop. So two trips to the server, and not pretty.

But why do I still prefer my way ? I believe that in many cases a 404 on resources is rare, at least it happens much less frequently than a 200. So (what you do) optimizing the rare path by making an extra DB call in the frequent path (200) is a trade-off I don't like.

Plus, the fact that you send an empty object in the loader looks pointless to me, I believe in many app a single resource won't be that big, so it's OK adding it in a response we already have to send.

So I imagine you are promoting best practices in those examples, and i am wondering if I am missing something, if it's too much the Remix way instead of the UX way ? (UX cos in status 200 responses, server did not have to check DB, so faster response)

By the way I don't even use Remix (currently considering it) and i much appreciate having those precise examples.

Thank you!

[machour]

Hey @NicolasCharpentier

Where I would have redirected in the component (client-side) if parent segment does not have the workshop.

In your case, /workshops/nimportequoi would still reply with a 200, and then would redirect client side. This looks really bad for seo, and I could reference a bunch of links with horrid stuff on the url, and they would get indexed by search engines, harming your website reputation 😄

In that regards, it makes sense to always have a test in the $workshopId.tsx route.

Plus, the fact that you send an empty object in the loader looks pointless to me, I believe in many app a single resource won't be that big, so it's OK adding it in a response we already have to send.

Yep, in a real-world app, you wouldn't probably have the parent route load all entities, and the child routes read from that. Every child route would load its own entity in its loader and deal with it's own data. The purpose of the example is to show how to retrieve a parent route data at the component level, so it makes sense to have it that way.

The example is outdated, as we know have useRouteLoaderData which is way more powerful in this particular case. I'm in the process of updating all examples.

Did you give Remix a go?

[machour]

Btw, closing this to tidy up the issue tracker, feel free to hop on our discord server to continue the conversation: https://rmx.as/discord