-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
change subject.unsubscribe() to subject.complete() #32
base: master
Are you sure you want to change the base?
Conversation
Don't know why CI tests failed, but running |
I've been noticing these errors when my project restarts in dev after a code change/rebuild, and I'm assuming they're related to this issue.
|
Any update on this? I am seeing this error still when using with ngIf. We would love to use it in production soon. I know you're a busy guy @toddmotto - thank you for providing this module. |
Well, until the PR get approved I published my forked version |
Any idea when this will be merged, this error is still present and when combined with *ngIf |
@virgil-av waiting for @toddmotto |
Thank you @gigioSouza until @toddmotto approves this PR I will remove ngx-error from the project as I have a few forms that relay on *ngIf to hide and show, but good job on fixing the problem so clean. |
@gigioSouza that package doesn't work for me, looks to contain the whole github repo. I've set up an npm package which contains the changes in this pull request |
I've tried using the forked version of this @szilarddavid posted, and I'm getting the exact same error. Just so I'm clear - I'm seeing this on components where *ngIf is used to hide a div that contains an ngx-error directive, and the 'TypeError: Cannot read property 'unsubscribe' of undefined' is thrown when the containing component is destroyed. Is that correct? Should the modified ngx-errors-complete resolve this issue? |
This pull request is related to a bug I found out when testing the ngx-errors to use on my project. I discovered that another user had already opened an issue #22 .
The bug occurs because the
BehaviorSubject
is closed whenngOnDestroy
is called, but don't recieve another instance when a new component is created, making it impossible to use this component withngIf
directive.Hunting down this bug I found out that the
BehaviorSubject
references was kind of "dirty" because it was beingunsubscribed()
when thengOnDestroy
fromngxerrors
was being called.As the
ngxerrors
wasn't subscribing to it, there was no reason tounsubscribe()
, to leave this reference you should complete the subject as thengxerrors
is it's manager.By completing it, all subscriptions should be already unsubscribed and the components was ready to receive other instance of
BehaviorSubject
when a new component is created.And passed the instantiation of the
BehaviorSubject
to thengOnInit
lifecycle hook.What are you adding/fixing?
Bug fix #22
Have you added tests for your changes?
I tried to add, but failed. I couldn't test if the
fixture.detectChanges()
was triggering and error.Will this need documentation changes?
No
Does this introduce a breaking change?
No
Other information