using ElementRef as target in combination with ScrollToService causes "memory leak"

[Sazeidya]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Feature request
[ ] Documentation issue or request

Current behavior

When using the ScrollToService in combination with an ElementRef to scroll to a specific element causes memory leak, when current view is switched (because of routing to another component for example), because the whole view is kept as Detached HTML elements (checked with Chrome tools). When using a string for target ID in ScrollConfig, everything works fine and the detached DOM can be GC.

Interesting: When using the ScrollToService in combination with ElementRef in another component, the old component gets GC, but when switching to another component again, the old component is kept as Detached HTML elements and can't get GC.

Expected behavior

Old view should be able to get GC.

Minimal reproduction of the problem with instructions

I do not have a demo, unfortunately. But you can reproduce this when you have a app with routing functionality and two components to switch between. In one component, you need to use the ScrollToService to scroll to an specific target element, which you pass as ElemenRef in the code (for example when clicking on a button to scroll down). After you did that, switch wo the second component and then run the Chrome Browser Tools (memory tab). There you can see, that the HTML Elements of the old view are still there and can't be GC. If you reload the page and repeat the steps without ever clicking the button (so the ScrollToService never executes) the detached elements of the view will not appear. As noted, this only happens on ElementRef (with and without .nativeElement), but when using strings it works as expected.

I have also tested a little bit arround, and I could fix this problem by adding the following line to the .stop() function of the ScrollToAnimation class:

ScrollToAnimation.prototype.stop = /**
* Stop the current Scroll Animation Loop.
*
* @return {?} Void
*/
function () {
clearInterval(this._interval);
this._options = null; // <=== with this line added, everything works fine with ElementRef too
this._interval = null;
this._source$.complete();
};
return ScrollToAnimation;

Maybe this is already the solution, but maybe you have a better idea :)

What is the motivation / use case for changing the behavior?

It would be nice, if using ElementRef would not cause a "memory leak", because I use that option very often :)

Environment

Angular version: 6.0.6

Your version of `@nicky-lenaers/ngx-scroll-to`: 1.0.0

Browser:
- [x] Chrome (desktop) version 68
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: v10.5.0  
- Platform: Windows (Windows 7 SP1)

[uloga]

There is memory leak even if you don't use ElementRef. Tried this plugin, after using it for an hour click even has an delay of 1 sec and its increasing with the time. Sometimes it scrolls half way then stops and starts again.