9 ms·

What is even considered overuse of event broadcasting and listening? I disagree completely with this being an anti-pattern. It is very effective and it helps en

by dmak 12y ago

What is even considered overuse of event broadcasting and listening? I disagree completely with this being an anti-pattern. It is very effective and it helps encapsulate code and separate out concerns very well. For example, if you are polling for new data, it is MUCH cleaner to broadcast the event and let each directive react and change their own state. In other words, each directive should be in charge of their own state. It is not the poller's responsibility to understand who's state that it needs to mutate.

poof131 12y ago
While I think your use case for events is clearly a good one, I’ve also seen the pattern abused, e.g. a widget opens a dialog selector and the selector fires an event to transmit the selection rather than just returning a promise that it resolves. Events seem the perfect fit for pub/sub like you describe where there is a one to many relationship, but the pattern does seem abused by people who use it for a one to one communication between parts of the code. Calling it an anti-pattern is perhaps a bit too harsh and detracts from the valid uses. Though, I am glad the author brought it up as too many events in the system can make it challenging to reason about.
- dcherman 12y ago
  That shouldn't even be a Promise imo. That should be an expression on your directive that is called with the selection. `on-select=handleSelection( selectedItem )` or something.
  - robinson7d 12y ago
    I also don't think a promise makes much sense, if we're talking about the same sort of widget. For a "selector", where the whole purpose is selecting a thing, I think that even better than that would be to use ng-model (or something similar). Which nearly comes back full circle to the original $emitting an event scenario, except instead the other side would $watch (rather than $on, and avoiding the emit/broadcast part on the directive's side totally).

by dmak 12y ago

poof131 12y ago

While I think your use case for events is clearly a good one, I’ve also seen the pattern abused, e.g. a widget opens a dialog selector and the selector fires an event to transmit the selection rather than just returning a promise that it resolves. Events seem the perfect fit for pub/sub like you describe where there is a one to many relationship, but the pattern does seem abused by people who use it for a one to one communication between parts of the code. Calling it an anti-pattern is perhaps a bit too harsh and detracts from the valid uses. Though, I am glad the author brought it up as too many events in the system can make it challenging to reason about.

dcherman 12y ago
That shouldn't even be a Promise imo. That should be an expression on your directive that is called with the selection. `on-select=handleSelection( selectedItem )` or something.
- robinson7d 12y ago
  I also don't think a promise makes much sense, if we're talking about the same sort of widget. For a "selector", where the whole purpose is selecting a thing, I think that even better than that would be to use ng-model (or something similar). Which nearly comes back full circle to the original $emitting an event scenario, except instead the other side would $watch (rather than $on, and avoiding the emit/broadcast part on the directive's side totally).