Memory leaks?

[felixfbecker]

Hi, stumbled across your blog post and module. I implemented the same module over a year ago - but I used a WeakMap to store promises. I see you are not, wouldn't that cause memory leaks?

https://github.com/felixfbecker/angular-async-filter

[kylecordes]

@felixfbecker - I am not the author of this thing, but I did feature it in the following video:

https://www.youtube.com/watch?v=XY9VPrKuJaA

I suspect the answer to your question in practice, at least for me, is @cvuorinen 's clever observation that by writing something | async(this) in the template, the async implementation gets access to the scope by which to register an $onDestroy handler and therefore stop listening at the right time.

(That's not so relevant to yours, as it is promise-only. I have not investigated whether this implementation is memory safe when not using this.)

[felixfbecker]

okay, so that seems to be required, which is not that nice... but still, even if they do get cleaned up on $destroy, if the scope is not destroyed it would not get garbage collected, right? Don't know if it's actually possible to have a situation where the scope lives longer than the object though.

I didn't add Observables at the time cause I didn't need it, but would have happily accepted a PR

[cvuorinen]

You're both correct. Currently there can be memory leak when not passing in the scope. When scope is passed in, it will get cleaned up on scope destroy. See https://github.com/cvuorinen/angular1-async-filter/issues/1 and https://github.com/cvuorinen/angular1-async-filter/pull/2

As mentioned in the above issue, I did also consider using WeakMap, but decided against it to avoid having to use a polyfill.

Maybe should detect if WeakMap is supported and use it if it is and fall back to current implementation if not?

[felixfbecker]

@cvuorinen

Maybe should detect if WeakMap is supported and use it if it is and fall back to current implementation if not?

at that point you are essentially using your own polyfill ;)

I wonder why you decided to publish your own module, was there anything anything that put you off from collaborating on https://github.com/felixfbecker/angular-async-filter?

[kylecordes]

As an interested non-author of either, I would be thrilled if these would consolidate to a single implementation that does all the things well:

• Observable - ideally compatible with any observable implementation that uses the standard-ish observable symbol marker
• promise
• Memory safety for promises without async(this)
• Support for all browsers supported by AngularJS
• Documentation
• Example / demo of effective use and the shorter app code that results
• Promoted, cross-linked, etc. so that hopefully any future user that needs it picks it up rather than starting their own

[cvuorinen]

at that point you are essentially using your own polyfill ;)

Yes, but users of this package would not be required to install anything additional or try to figure out if they need it or not.

Don't remember exactly the reasons why I created my own package since it was over a year ago. Might have been because Observable support, or the WeakMap polyfill. The code actually evolved from a project I was working on at the time, so might be just that I already had it working and then decided to publish it to npm.

[felixfbecker]

@cvuorinen Well, in turn the ones who target newer browsers end up with either memory leaks or dead code.

Adding polyfill on the other hand is a matter of adding

<script src="https://unpkg.com/weakmap"></script>`

to your page.

@kylecordes Just checking for Symbol.Observable without definitely be the path I would take. Don't care who has ownership of this after all, but I think having this twice on npm has no benefit to users :)

[kylecordes]

About the easy polyfill: Most of the projects I see are in-house, behind a firewall. The applications bring in code only from local servers, not from anywhere on the web. Therefore the polyfill is not quite so easy:

• Often it is yet another piece of code to seek approval to use
• Needs to be integrated in to a (typically already quite complex) build process
• .. and deployed

There is some merit in building in the ability to operate even on older browsers.