flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS] Bubbling Problem
Date Tue, 06 Sep 2016 15:32:06 GMT
On 9/6/16, 1:38 AM, "Harbs" <harbs.lists@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

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

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

My 2 cents,

View raw message