Usage with application level singletons? about until-destroy HOT 5 CLOSED

What for? :)

When your tab is reloaded - all memory gets released, there is no need to unsubscribe.

from until-destroy.

I think he meant hmr.

from until-destroy.

Note that you're adding extra code (untilDestroyed) to support development mode with hmr.

from until-destroy.

Let's say you're working on an app that uses firebase. It's likely you have singleton services that create some subscriptions - and every such subscription holds an active websocket. With HMR the tab does not reload and new instances of the angular app and new instances of services get created. This leads to gradual slowdown and leakage of resources ... I know because I had this problem until I found untilDestroyed. It is extra code in non-HMR environment but in my opinion it's totally worth it.

Also, such singleton services made with untilDestroyed can easily be converted to component level services.

Additionally singleton services get destroyed in unit tests all the time ...

I think handling proper lifecycle in singleton services is simply a good idea - that's why I got confused by the README. Hopefully the use case is still supported with Ivy.

from until-destroy.

I think we can remove this message and leave the decision to the developer. In general, @arturovt is right, but as you said, there are edge cases such as hmr.

from until-destroy.