broadcast the $destroy event to notify child scopes

[vojtajina]

broadcast $destroy event on the scope being destroyed so that all child scopes know about the imminent destruction.

[IgorMinar]

Why? Can you provide some use cases?

[hekke]

Real-world use case:

When using jQuery.dialog it detaches the DOM element that you install it on and appends it to the body tag.

When the scope it destroyed and the DOM is changed, it'll hang around forever as garbage.

A way to solve this is to have proper lifecycle events like $destroy, so widgets can do proper cleanup.

[IgorMinar]

when the scope on which the widget was listening on is destroyed then this widget will be notified even if the position of the element in the dom was changed by an external library. so the current $destroy should work just fine.

am I missing something?

[hekke]

It's doesn't work reliable when using routes:

http://jsfiddle.net/hekke/NyN3H/

Watch the console output - BarCtrl never receives a $destroy event and thus leaks

[IgorMinar]

Now I understand. The issue says "broadcast", but Vojta meant local broadcast (from the scope to its children) rather than global broadcast that goes to all scopes derived from the root scope.

Thanks for the example, hekke.

[vojtajina]

Yes I meant broadcast from the scope that is being destroyed, so that all its children are notified... (because it means they are being destroyed as well, so it's polite to at least let them know).

I changed the title of the issue.

[dandoyon]

I was looking into broadcast/emit in 0.10.7 and got the emit code to work but broadcast is not doing as I expect it to be. http://jsfiddle.net/dandoyon/Yvsd8/ is this the correct usage? Also, I'm curious as what the thought process was for having unidirectional messaging meaning broadcast downwards and emit going up? What if I have sibling controllers? I was also wondering why it wouldn't just be a pub/sub situation that doesn't really care about where the events originate or land. Or am i just being naive?

thx

[witoldsz]

Hi, you have a bug in your code:
Broadcast
[...]
$scope.broadcaster = ...

Notice: broadcast vs broadcaster.

As to your question what are two different mechanisms for (emit and
broadcast), they are used for different things. Emit is used when
working with forms, i.e. you want your "master" form receive all the
valid/invalid events from widgets. Consider two equal forms on a page:
one does not want widgets from one form affecting submit action of the
other.

On the other hand, there are things like application-wide or
controller-wide events, i.e. you have a "event-loginRequired",
broadcasted from $rootScope by $http interceptor, when it captures
status 401 response. Imagine widgets like log-in form, which is
invisible, waiting for such an event to beautifully slide down asking
user to provide valid credentials.

Regards,
Witold Szczerba

On 30 January 2012 06:59, dandoyon
reply@reply.github.com
wrote:

I was looking into broadcast/emit in 0.10.7 and got the emit code to work but broadcast is not doing as I expect it to be. http://jsfiddle.net/dandoyon/Yvsd8/  is this the correct usage? Also, I'm curious as what the thought process was for having unidirectional messaging meaning broadcast downwards and emit going up?  What if I have sibling controllers?  I was also wondering why it wouldn't just be a pub/sub situation that doesn't really care about where the events originate or land. Or am i just being naive?

thx

---

Reply to this email directly or view it on GitHub:
#683 (comment)

[dandoyon]

Witold,

Thanks for the explanation (with use case) and catching the obvious bug. I think I need a break from staring at screens all day.

--dan

[recht]

Is there any progress on this? Or how are you supposed to clean up from a controller?

[IgorMinar]

this was fixed in rc2. looks like we forgot to reference and close this issue.