Both methods can be used so that one event handler can listen to the firing of an event from another event handler. The documentation says they are the same thing, just different implementation. I'm wondering why the framework bothers providing two different methods for this same task? Probably pipe() is better for chaining, but I'm wondering if there is any other hidden advantage of using pipe() over emit()/subscribe()
Asked
Active
Viewed 268 times
0
Lim H.
- 9,870
- 9
- 48
- 74
1 Answers
2
If you do widgetA.pipe(widgetB) then all events from widgetA are sent to widgetB regardless whether widgetB is listening to them. Pipe is like a firehose.
Subscribe on the other hand, is more performant. WidgetB.subscribe(widgetA) says "of the things you emit, I want to subscribe to a particular subset." Other events are then completely ignored.
This is especially important when interacting with the DOM, which outputs a lot of events (mousedown, mouseup, touchmove, resize, etc...), and it's preferred to use Subscribe when listening to a DOM element.
dmvaldman
- 413
- 2
- 13
-
Where'd the idea for pipe/subscribe come from? Is there some API somewhere from which Famous oh-three's events took inspiration from? Can you also explain how subscribing in your example subscribes to a subset? Oh, is it because subscribing will only pick up the events that the source listens too? So if source only has source.on('click'), then subscribing will only get you those click events? pipe also calls subscribe, in the reverse direction, then it does some stuff (https://github.com/Famous/famous/blob/develop/src/core/EventHandler.js#L107-L112) What's it doing there? – trusktr Sep 24 '15 at 21:29