This bubbling issue where something deep in this display list unexpectedly called a listener at a much higher level that wasn't expecting a different event type or target annoyed me surprisingly frequently back in the day. Touch/mouse events are perfect candidates for bubbling because you are actually interacting with every object up the chain. For most events dispatched by UI components, the event often doesn't make sense beyond its target, and maybe 1 or 2 levels up the chain. Re-dispatching, as Alex suggests, is the right way to go in those situations.
- Josh On Sep 6, 2016 8:32 AM, "Alex Harui" <aha...@adobe.com> wrote: > On 9/6/16, 1:38 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > >I don’t understand what you mean. > > > >It seems to me that bubbling is functionality that users would expect and > >implementing bubbling should have very little overhead. > > Yes, people misused (IMO) bubbling quite frequently in existing Flex code. > It is very tempting to use it to skip levels in the DOM so some outer > thing can catch an event from an inner thing like an ItemRenderer. > > More than once, a customer wrote in with with one of those hard-to-find > "can't coerce FooEvent to BarEvent" errors. After much investigation it > would turn out to be a problem caused by bubbling. IIRC, in one case > there was a DataGrid in a Panel. But a custom DataGrid ItemRenderer also > contained a Panel or Callout or something like that. Sure enough, when > you closed the Panel/Callout, the close event unintentionally bubbled up > to logic in the ItemRenderer and on up to the outer Panel that contained > the DataGrid. Once you bubble, you are shouting to the entire parent > chain unless you further take steps to stop propagation or start checking > targets. It is better, IMO, to have private conversations between the two > pieces that care. > > I think there was another case where a custom skin picked up an event > bubbled from a renderer. It worked in one theme, but not another. > > And there was another case where someone created a shell app for a > "mashup" that would host other Flex apps loaded via SWFLoader. Those > child Flex apps bubbled events that screwed up the shell app because it > happened to be listening for custom events that had a different semantic > meaning than the meaning in the child Flex apps. > > Bubbling, IMO, was intended for Mouse and Keyboard events (and I think > Scroll), where there is little doubt that the event will have the same > meaning globally, and you really do need to figure out who dispatched the > event since the DOM can be arbitrarily complex. For everything else, I > believe the best practice is event propagation with increased semantic > meaning. > > Thus, an item renderer containing a "delete" button would listen for > "click" on the button and dispatch a "rendererDeleted" event off of the > renderer. If the delete button was buried inside the renderer by several > containers, there is no wasted effort of the event bubbling up through all > of those containers. In FlexJS, a custom item renderer factory allows you > to add "rendererDeleted" listeners to each renderer as it is created. If > the list was, for example, a list of users, your code containing the List > and the custom factory might further propagate a "usersListItemDeleted" > event off of the containing MXML document. Some other controller logic > could then handle that, and would not be confused from some other list > deleting things. > > So, IMO, the Panel's TitleBar's Close Button should not just bubble a > Close event. The TitleBar should know to propagate a "close" event and > the PanelView should know it has a TitleBar and dispatch the event off the > Panel/strand. > > Sure, we should fix bubbling in FlexJS (once we decide on what event model > we are going with), but in my reading of the Google implementation, the > parent chain will be walked for every event dispatched. So, I think there > are plenty of reasons to discourage bubbling and recommend some other > practice. > > My 2 cents, > -Alex > > >
