3 ms·
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
by 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 agoThat 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 agoI 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).