You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
Just went through the interesting https://github.com/remix-run/examples/tree/main/sharing-loader-data example
Where you say this :
I get the point, and I feel like you optimize for the "single roundtrip way" because :
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!
The text was updated successfully, but these errors were encountered: