Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sharing-loader-data example choice justification #421

Open
NicolasCharpentier opened this issue Feb 5, 2024 · 0 comments
Open

sharing-loader-data example choice justification #421

NicolasCharpentier opened this issue Feb 5, 2024 · 0 comments

Comments

@NicolasCharpentier
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant