Unsubscribing listeners on component destroy

[maniax89]

I am frequently using <aura:if> and <aura:iteration> statements bound to custom components that end up calling the connect method provided by this library.

This works well for a bit, but it ends up slowing down a lot after using an application for a while. After diving deeper into the developer tools in the browser, I notice that the handleChanges() event seems to keep firing for components that have been destroyed (and recreated with different identifiers).

It would be good to see if there is any way we can take the return value from the subscribe method on the redux store to attach an event handler of some sort to the destroy event of the component to call the return value of the subscribe method (unsubscribe). Otherwise I'm not sure how to prevent the subscriber queue from building up with a ton of event handlers over time.

[maniax89]

i posted what I think might be a solution in #18

[madmax983]

When this came in last night, I was hoping it would be as simple as throwing a handler on the destroy. Solution makes total sense to me. Only thing I am wary of is that components getting destroyed in LEX doesn't always happen right away. But this will at least ensure that when the redux service component is destroyed, that listener is removed.

[maniax89]

To be honest I looked at doing the same (adding event listener to the target component) but I couldn't figure out how to get it to fire. Seems to work for custom events but not for system events like destroy and init.

If you have more insight into the aura framework let me know as it would techincally be more correct to unsubscribe when the target component is destroyed rather than when the redux component is destroyed.

[madmax983]

I think this way is fine. This way implementors don't have to worry about it, the service component cleans itself up.

And it would take some finagling to do it any other way, I think this is the simplest path.

I also managed to clean up another performance issue (the try catch in the connect method. I'm sure I had a reason to do it that way when I first wrote it, but it's unnecessary).

I also fixed another bug when there was no name specified

[madmax983]

Thanks for the PR!

[maniax89]

thanks so much! very quick turnaround on this! everything is working great now