Handle rejected promises

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!!

[tswaters]

If someone is looking for a catch behaviour, you can pull out the error from state and throw if it exists… something like the following should work. This tosses the first error encountered, but could easily be reworked into aggregating all the errors into an array.

loadOnServer({ ...renderProps, store }).then(() => {
  const {loadState} = store.getState().reduxAsyncConnect
  const err = Object.keys(loadState).reduce((memo, key) => memo || loadState[key].error, null)
  if (err) { throw error }
  // whatever else
})
.catch(err => {
  // a wild error handler appeared!
  next(err)
})

I’d much prefer if it automagically went into the catch block myself, but can appreciate the reasoning / breaking changes / potential for multiple errors, etc. for not doing it like that.

[vpanjganj]

@yoadsn ,I think if a component (UI) has to visually respond to a data load failure, it is enough reason to include that in the state and implement the behaviour in the component. To address your concern about redundant code to handle data errors; you can use Higher-ordered components to reuse the logic anywhere necessary.