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
Currently, if something goes awry in your loader, the recommendation is to throw a Response so that the error will be handled in the nearest ErrorBoundary. This is convenient, but comes with the downside that the error information can’t be inferred from typeof loader since TypeScript is not “throw-aware” (I’m sure there is a better term for this).
This proposal aims to enable fully type-safe error handling, provided that the developer always returns a response rather than throwing.
Change SerializeFrom so that it can differentiate between Responses with { status: 200 } and other responses (or whatever the distinction is made by Remix to render the route component or the ErrorBoundary fallback). This would (hopefully) allow useLoaderData to Extract<...> the happy-path data from typeof loader, so that you can just consider that case and ignore any error-associated data, which wouldn’t be passed to the route component anyway
Make useRouteError generic, so that it can take a typeof loader from which it can Exclude<...> the “OK” responses, basically the complement of the previous bullet point
For this to work properly, it might be necessary (or helpful) to provide separate convenience functions success(...) and error(...), which would wrap json(...).
These functions could return a branded type, so that the loader return type could be a discriminated union (provided that the developer returns nothing else from loader).
The second (init) argument argument to these functions could be type-restricted, such that only the appropriate status codes would be allowed
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Currently, if something goes awry in your loader, the recommendation is to
throw
aResponse
so that the error will be handled in the nearestErrorBoundary
. This is convenient, but comes with the downside that the error information can’t be inferred fromtypeof loader
since TypeScript is not “throw
-aware” (I’m sure there is a better term for this).This proposal aims to enable fully type-safe error handling, provided that the developer always
return
s a response rather thanthrow
ing.SerializeFrom
so that it can differentiate betweenResponse
s with{ status: 200 }
and other responses (or whatever the distinction is made by Remix to render the route component or theErrorBoundary
fallback). This would (hopefully) allowuseLoaderData
toExtract<...>
the happy-path data fromtypeof loader
, so that you can just consider that case and ignore any error-associated data, which wouldn’t be passed to the route component anywayuseRouteError
generic, so that it can take atypeof loader
from which it canExclude<...>
the “OK” responses, basically the complement of the previous bullet pointFor this to work properly, it might be necessary (or helpful) to provide separate convenience functions
success(...)
anderror(...)
, which would wrapjson(...)
.loader
return type could be a discriminated union (provided that the developer returns nothing else fromloader
).init
) argument argument to these functions could be type-restricted, such that only the appropriate status codes would be allowedAdapted from
responses.ts
:Same line of thought for
action
.Would this make sense?
Beta Was this translation helpful? Give feedback.
All reactions