Timing issues in ErrorHandler? about ngx-simple-modal

[freon27]

Just thought you might be interested in an update I have on this.

Our tick solution stopped working when BrowserAnimationModule was included in the app (ran into weird problems where the window redisplayed after dismiss but there was a modal overlay left on TOP of it - thus breaking everything.

I now (after half a day of reading) understand that the ErrorHandler is executed outside of the Angular zone (presumably so that throwing the error again doesn't re-trigger the error handler. This means that none of the normal detection cycles are happening (hence the manual tick being required).

Presumably the single tick isn't enough once the animation module gets involved (a similar problem occurs when people try to navigate from the ErrorHandler when the animation module is included). I don't use this module myself but I'm assuming it adds a bunch of extra stages to component create/destroy.

Using zone.run puts the modal process back inside the angular zone so that it gets the benefit of all of the normal Angular cycles. As far as I can tell this has resolved our issue and feels like less of a hack than ticking manually.

zone.run(() => {
    this.notificationService.showModal(...) 
});

[kevcjones-archived]

I have a feeling that this is more to do with change detection vs instantiation and changes being applied late because i think handleError occurs after the apps change detection cycle has completed. For times like this you've take two possible work arounds..

I wouldn't use the applicationRef.tick personally either i agree, that causes the whole app to perform change detection.

Do you have something you can share as an example? Perhaps a plunkr/codepen example of your issue so i can replicate it and help.

[kevcjones-archived]

I assume you've followed this approach for custom error handler then? https://egrilaszlo.com/2017/12/31/custom-error-handler-angular/

[kevcjones-archived]

Hey @freon27 please take a look inside https://github.com/KevCJones/ngx-simple-modal/tree/feature/add-tests and in particular the demo branch

https://github.com/KevCJones/ngx-simple-modal/tree/feature/add-tests/demo/src/app/custom-error

I added a custom error handler, but i injected the modal service directly, simply because i didn't need to abstract it any further, shouldn't make a big difference. It appears to work without any special requirements. So i now think its more likely your dialogue perhaps?

Could you clone that branch and via terminal

cd demo
npm i 
ng serve

Have a look a peek in that and see if its different in any way to your approach. See the app.component for where i throw the error.

[freon27]

Thanks for replying so quickly. Yes - I didn't use that specific blog post but something almost identical. I'm running your demo and trying to see what's different. If I can't replicate it/work it out in there, then I'll try to create a plunkr.

[freon27]

Ok so if I add my stuff into your demo app then it works (if I remove my TranslationService). If I put your AlertComponent into my app and call it directly (no NotificationService in the way) then it fails the same as with mine (unless I use app.tick). I see that your demo is using Angular 4 and I'd like to try to provide a Plunkr for Angular 5 to see if the problem is recreated.

Possibly a dumb question but how do I include your module in Plunkr? I tried adding 'ngx-simple-modal': 'npm:ngx-simple-modal' to the config but then it tries to download https://unpkg.com/simple-modal.service unsuccessfully. Pretty new to Plunkr so this is my first time including an external npm lib.

[kevcjones-archived]

I see so this could be an ng5 problem... I'm not a plunkr wiz tbh, this might be a good use case to try https://stackblitz.com/ i think... its in my list of demonstration platforms to try. Does most of the boilerplate for you for ng5 too.

edit: I actually had a spare 10 mins, and this was a good exercise.. plus it reproduced the problem.

https://stackblitz.com/edit/angular-vjjdn7

[kevcjones-archived]

So on updating that demo slightly and having a play before my next meeting. I can see that

• throwing an error as a result of an async event like (click) works as expected
• throwing the error inside a setTimeout to simulate some mid async behaviour like you're describing.. and it indeed fails on ng5.

Interesting bug, the issue still feels like change detection, i'm going to try to add a OnPush change detection style alert.. to see if its something we can work around...

https://angular-vjjdn7.stackblitz.io/

[kevcjones-archived]

Amusingly i think you already found the cleanest solution so far.

https://stackoverflow.com/questions/37793276/angular-2-custom-exceptionhandler-change-detection-lag#37793791

Which is pretty much what you did, though a timeout of 0 ms, works too, not sure if perhaps your translation stuff would work like this... this is a bit of an annoying bug tbh.. it tells me that the errorHandler is happening outside the change detection digest cycle and doesn't fire another update to handle any UI changes you might choose to make... since we're in a @injected service and not inside a component...

I tried to add change detection to the modal and it didn't seem to make a difference.

[kevcjones-archived]

I've tagged as a bug... but i'm not sure its 'our bug' per say... given this worked ok in ng4.x... i have to wonder if this isn't something we should file as an issue on the angular repo instead? Perhaps they have input which can explain why entryComponents being created inside ErrorHandler are too late for change detection in ng5.x... i suspect the answer is 'because we made a performance decision and now the Errorhandler does not trigger change detection and that we have to do it yourselves.'

[freon27]

Thanks! I've actually worked out a way to make sure the translation service is ready before the modal is created so I'm able to make the timeout complete instantly (which prevents the user seeing the blank window for a fraction of a second). I don't think the tick is too much of a disaster given that it's only happening when we reach the point of having an unhandled error. If it's happening often then we have bigger problems than a laggy interface ;)

Cheers for the help, really appreciate it.

[kevcjones-archived]

Thats good news... and no worries, it was an interesting discovery all the same tbh, one that might save me pains down the line. You never know!