Behavioral difference between enyo.dispatch(e) and target.dispatchEvent(e) web api

edited December 2014 in Enyo 2.4
I am curious to know that how dispatch of event happens in Enyo. Say for a, simple DOM tree, having a parent node with two child nodes. All i want to do is to propagate custom event generated from child 1 to child 2. I have created a sample for this.

If i try to use "target.dispatchEvent(evt)", and type the expected date format (i.e. Jan 01 2015 09:08:07), the clock time will set to the same, but the behavior is not similiar when try to use "enyo.dispatcher.dispatch(evt)".

Please help me to know the differences and enyo way of achieve the same.


  • The common approach to that problem is for data to flow up the tree via events and down via properties/methods. Passing horizontally (between siblings) isn't ideal because it usually tightly couples the components requiring each to only be used in a specific context. Instead, the input's onchange or oninput should be handled by its owner (as you've done) and the owner should update the clock.

    The reason why enyo.dispatcher.dispatch isn't working is the event doesn't have a target. Enyo uses that property of the event to determine where to start the bubbling. Without it, it silently aborts.

    You shouldn't need to create custom DOM events in Enyo. You're able to but I'd recommend using the framework's eventing system to reduce the amount of boilerplate code you have to create.
  • Thank you for the explanation. As i understood, if event have some target, then enyo.dispatcher.dispatch will start bubbling event to top starting from target. I will be thankful if you can share some example where event is provided with some target and dispatcher functionality is used to propagate and handled.
    Talking about topmost, i came across the term "enyo.master". It is not document (root of DOM tree). May you explain the term and behavior difference with reference to document.
  • There isn't a 'correct' pattern in Enyo for using events in this way. This is how I'd implement your sample without using custom events.

    enyo.master is the owner of any otherwise unowned controls (e.g. your top-level kind rendered into the body). As such, it is the last component to receive a bubbled event and is also the default dispatch target for events that don't have a target (like in your example using enyo.dispatcher.dispatch).
  • edited December 2014
    Thank you for the explanation. The example which i had shared is very basic sample. If we consider some thing more complex, having complex DOM structure,proceeding with same approach as you suggested may not hold.
    I am skeptical on two solutions, i.e. through signals and other is bubbling and waterfalldown event. Please take a look and suggest as both approach have pros and cons. Talking about signals, it does broadcasting which can be heavy in certain scenarios whereas bubbling/waterfall events can be questionable as where to bubble and where to waterfall event.
    Signal usage---
    Bubble/waterfall usage ----
  • I wouldn't recommend either of those designs. Signals should be used sparingly as it couples otherwise unrelated components together. Similarly, waterfalling events should be limited, particularly in complex trees, because it has to waterfall to every child.

    The complexity of the DOM tree doesn't change the design philosophy. The "Enyo Way" is to pass data down through properties/methods and up through events. If you have unique requirements, Signals or EventEmitter may be a good fit. Are you encountering problems with the 'usual' way?
  • @theryanjduffy‌ I don't know how to achieve the same using EventEmitter. Just having idea that EventEmitter doesn't bubble up event usual way, thus might effecting performance. May you share some sample related to EventEmitter usage.
  • @krakesh_cse‌, I assume what you want to do is allow state changes in one of the siblings to affect the state of the other siblings, right? If you look at things that way, the 'events' are simply the communication mechanism, but what you really care about is coordinating (shared) state.

    In terms of application structure, if you have 2 or more siblings that influence each others state in one way or another it's almost always best to create a parent component (a parent control or a controller, whatever you prefer) that implements the logic required to coordinate state across these siblings.

    The reason to put this type of logic in a parent component, is that it allows you to manage the state of the siblings in a single location and this single location can apply state to any of it's children in accordance with this logic.

    Once you have this parent that coordinates state across it's children, the only responsibility of the child is to respond to its own state changes.

    This keeps things structured and maintainable. It's probably also going to be easier to understand and work with, because the siblings themselves no longer have to explicitly know about each other.

    Once you have the logic centralized at a single location, the question then becomes how the parent knows about state changes in its children. It may at that point be possible to use observers, or bindings rather than events, eliminating the whole complexity of needing to waterfall and bubble multiple events throughout the tree.
Sign In or Register to comment.