flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ent <p...@adobe.com>
Subject Re: [FlexJS] ElementWrapper.forwarder() Changes Target
Date Thu, 18 Aug 2016 20:34:55 GMT
Just to play devil's advocate for moment, ReactJS duplicates the DOM for
its own purposes and seems to do quite well. I know it has code in it to
do optimization for what to redraw, making it more complex than just a
duplicate tree structure.

That said, reducing our overhead is a worthy goal and if it can be done
without duplication that would be great. I guess a duplicate event system
that really brings nothing else to the table would not be worth it if
there were alternatives.


On 8/18/16, 2:38 PM, "Alex Harui" <aharui@adobe.com> wrote:

>On 8/18/16, 10:42 AM, "Peter Ent" <pent@adobe.com> wrote:
>>I think I'm leaning more toward agreeing with you, Harbs, about a Flex
>>event bus. I remember changing MouseEvent because of some issue (have to
>>look at the logs) with it being a subclass of Event. If we make it a rule
>>that every FlexJS component only work with org.apache.flex.events.Event
>>(or a subclass), and have a set of interactive event (mouse, touch,
>>keyboard) classes (which derive from our own Event class), something deep
>>down should be able to translate platform events to our events and put
>>them onto our bus. It is a shame not to take advantage of the platform's
>>own dispatching system, but when trying to put things together from
>>different systems, sometimes you need to go outside the box.
>Duplicating the event system is definitely a possibility, but I would like
>to explore other solutions first.
>Stepping back, IIRC, the reason we tried wrapping Sprite was to deal with
>code-hinting in the IDEs and issues with property and method names with
>low-level Flash APIs.  It occurred to me that the wrapping solution might
>be attacking this problem incorrectly:  it is adding runtime overhead for
>an author-time problem.  That isn't PAYG.  Further adding a duplicate
>event system will only add more runtime overhead.  The Google event system
>we use on the JS side added 6K to every download.  Not sure how big a
>Flash version will be, but it will double the number of event listener
>arrays and worse, the duplicates will be in ActionScript instead of C
>code.  And when you add overhead, you invite others to undercut you with
>lower-overhead alternatives and fracture the community.
>In addition, IMO, it was a goal to try to abstract away the internal
>implementations of the components.  I'm concerned that we will get used to
>wrapping everything.  The CreateJS code and another Canvas framework that
>doesn't have to wrap HTMLElements shouldn't have to wrap elements.  Same
>will be true for any Flash 3D/Starling/Feathers sort of thing for the SWF.
>So maybe the answer is to upgrade the tools to solve the original set of
>problems.  Then the runtime is as efficient as it can be for each
>The separate problem of event classes and their inheritance is, IMO a
>separate problem and the solution is dependent on whether we keep wrapping
>DisplayObjects in the SWF implementation.  I will say, though, that it is
>important to remember that we want the lowest overhead on the JS side, so
>having some additional overhead on the SWF side is ok, but double the
>number of objects may be too much.  Further, 100% compatibility with Flex
>is not a requirement.  So, some old Flex coding patterns and expectation
>may have to change, including whether you have to get the type of your
>events correct because MouseEvent doesn't subclass Event. That might still
>be better fixed with better tooling and debugging.  I can imagine some
>hybrid apps where the app uses more than one library which are dispatching
>different kinds of events.
>I am going to go dig up the original thread and respond there with a
>discussion on alternative solutions.
>My 2 cents,

View raw message