documentation on the errorhandler

[jmls]

• [X ] Question

What version of this module are you using?

• [X] 2.1.0-rc.n (2.1 Release Candidate n)

Is there any documentation on how to use / reuse the errorHandler ? I'm getting errors where a token has expired, and need to redirect the user to the login, but can't quite figure out how to handle the error ;)

Do I need to write my own errorhandler and drop that into the sdk somehow ?

[jmls]

bump ;)

[jonathan-casarrubias]

@jmls right now there is no way to pass a custom handler but it should be kind of easy to implement it.

I can not do it right now since I'm full now but I can provide some steps and PRs are welcome if anyone wants to contribute for this.

1.- Within the LoopBackConfig add a new setter method "setErrorHandler(handler: Function) { this. errorHander }" 2.- Within the LoopBackConfig add a new getter method "getErrorHandler()" which returns this.errorHandler 3.- Within the base.service file implement LoopBackConfig.getErrorHandler() and validate if available use that otherwise use the current default behaviour

Once this is implemented and we publish this changes.....

Then in your application

import { LoopBackConfig } from 'sdk';

LoopBackConfig.setErrorHandler((error: Response) => { return // Custom error handling. })

Cheers Jon

[jmls]

wouldn't it be better to do it the angular way (tm) and make a provider for the errorhandler - by default the provider is the standard errorHandler, but if you wanted to you could provide a different one for your app ?

This way the errorhandler (either default, or custom) is simply injected wherever you want to use it

[jonathan-casarrubias]

Yes you can do that and I think it might be fine, it's just that we have 2 pieces of software working together... Angular and the SDK

The thing is, the SDK is not just Angular anymore..... We also support React now and I would like to use the SDK Way rather than the Angular way...

That way it will work the same way in Angular and React (And future Implementations)

Thoughts?

[jmls]

if the code is generated from templates then I would suggest the best way is to use the strength of each framework, not a lower common denominator. ie generate the most appropriate code for each framework.

Providers is a standard mechanism for changing default behaviour in Angular4+.

[jonathan-casarrubias]

@jmls The templates are the same for both frameworks,

I see what you say... and I kind of agree but we don't have the resources, nor contributors to execute as you propose...

If this is implemented the way I'm proposing it will immediately work for both, Angular and React at once.

Otherwise lets say you contribute to the Angular version of the handler, who will implement the React one? you as well? who to keep both SDK consistent.

Also I don't see any technical advantage to use a provider, you say the provider can be used anywhere in your app, the LoopBackConfig can be used anywhere in your app as well, It provides static methods, these are not new instances of the config.....

Though I know is not Angular standard, I just don't see any performance or technical benefit other than do it the "Angular way" actually I see more downsides within the SDK context.

Please let me know if there are more technical or performance benefits that I can not see and I might be able to reconsider the approach and then see how to address the React portion of the SDK..

Cheers Jon

[jmls]

hey man, it's your project - you get it built however you want ;)

If you think that your proposal is the best way forward, then I'll follow your lead.

I'll have a look and see if I can implement what you suggest.

[jonathan-casarrubias]

@jmls ok cool thanks, take a look and see if you find it doable.... Any question I'll be glad to answer.. -as soon as I can-

Cheers Jon