makeomatic / makeomatic/redux-connect

Handle rejected promises

Open
#104 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

question
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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.