@resolveError

[ericclemmons]

This is super-useful for catching bugs & stuff that happen during the @resolve...

[ericclemmons]

@goatslacker Check it:

• Fix issue where error (perhaps all data?) persists throughout history.

[ericclemmons]

Totally dig this.

[ericclemmons]

This is a pretty good example of what the v2 architecture tries to allow - "bubbling" of Promise handling up the chain.

Coming up next, #72!

[ericclemmons]

I've already been pinged to include <PrettyError>. I should be able to do it via react-resolver/components/PrettyError so it's optional.

[goatslacker]

So nice

[monder]

@ericclemmons any chance to merge this?

[monder]

Aghh, just found out that it breaks server rendering. :) Need to think of some other approach

[ericclemmons]

Actually, we may want to revisit this from a clean slate. (Close this PR, basically)

I think the implementation of @loader (#39) but with a .catch clause is the way to go.

@monder You've been helping out a lot. Would you like contributor/publisher rights?

[monder]

Its not as simple as with @loader =) Tried that.
What I want to do is to have some sort of error handling that just works.
For example I could define:

<Component1>
  <ErrorHandlerX>
    <Component2>
      <ErrorHandlerY>
        <Component3>
        </Component3>
      </ErrorHandlerY>
     </Component2>
   </ErrorHandlerX>
</Component1>

Where ErrorHandlerY will catch errors from Component3
ErrorHandlerX will catch errors from Component2 and all unhandled ErrorHandlerY ones.
If none catches - the exception will bubble to server side catch.

That way for example I can draw a navigation bar on all 404 and 403 pages with the user's name.
And only when there was an error to retrieve the user context the rendered error will be without navigation bar =)

What I currently came up with and it works on both server side and client side - https://gist.github.com/monder/f3f969ca8210191b550af130627b26cf
(Requires #117)
But before I create a proper PR I want to fix some of the stuff I don't like (this['ReactResolver.IS_CLIENT'] for example, ResolveError extends Resolver, setState magic).

The api is

@resolveError((error) => {
  if (error.response && error.response.status === 404) {
    return error.response.status;
  }
  throw error;
}) 

So if the axios in my example throws an error in @resolve block and its a 404, the error property will be "404", else the error is passed to the next <Resolver> on stack if there is one. Why just "404" and not the whole Error object or ResolverError (which BTW is currently unused)? Its because the Error is not serialisable to JSON, and we require that to do the correct SSR hydration.

[ericclemmons]

Man, that sounds so slick Great writeup!

I'd suggest @handleError or @catchError since there isn't any resolution happening, but great work!

Let's get #117 taken care & get you access!

[ericclemmons]

Also, I think it'd be great to have an example for something like this, even if the error's faked or randomized between requests!

[monder]

@catchError sounds better indeed.
I will definitely add/update the example. But as you've already said it should be a new PR :)

[ericclemmons]

@monder Yep, you're right. Hook me up with your NPM name as well so I can give you publishing rights!

[monder]

Thanks. It's the same as on github - https://www.npmjs.com/~monder

[ericclemmons]

@monder You're added onto both npm and Github!

~/Projects/ericclemmons/react-resolver master ⇣
❯ npm owner ls
ericclemmons <[email protected]>
monder <[email protected]>
pwmckenna <[email protected]>

[ericclemmons]

Super old commits, so I'm closing due to inactivity. Any collaborator can re-open. If anyone else wants collab rights, ping me!