makeomatic / makeomatic/redux-connect
Handle rejected promises
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 545
- Forks
- 61
- PR merge metrics
- No merged PRs in 30d
Description
I must be missing something here.
If I return a rejected promise from the loader of a component, nothing seems to work as expected.
On the server side, loadOnServer itself is not rejected but rather it continues to resolve the promise and so the component tree gets rendered without the required data. I then get other exceptions due to the missing data which does reject the entire promise. (as expected).
loadOnServer({ ...renderProps, store }).then(() => {
// Even when the loader promise is rejected this code runs..
})
.catch(err => {
// this would run eventually when something breaks in a component due to the missing data..
})
On the client side, I am not even sure what to expect - clearly there is no extension point where I can change the routing and redirect to an error page. How should that be handled on the client?
<ReactReduxProvider store={store}>
<Router {...renderProps}
render={(props) => <ReduxAsyncConnect {...props}
render={applyRouterMiddleware(useScroll(cusotmScrollBehaviour))}
/>}
routes={getRoutes(context)}/>
</ReactReduxProvider>
Any insights on this would be great (I was digging in the sources for a while, but I don't think there is any special handling for this situation)
Thanks!!
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing loadOnServer and ReduxAsyncConnect from the issue's server and client examples, then inspect how rejected loader promises propagate. Reproduce the behavior on both sides and determine the expected error-handling path; done means rejected loaders are handled consistently or the supported behavior is clearly documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, react, redux
- Domain
- backend, frontend, full-stack
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100