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] Do we have a similar invalidation/commit concept as with the old Flex SDK?
Date Fri, 06 Jan 2017 16:07:34 GMT


On 1/6/17, 1:04 AM, "Christofer Dutz" <christofer.dutz@c-ware.de> wrote:

>Hi Guys,
>
>While writing my article, I stumbled over one question: Have we ported
>the validation/invalidation concept of the Flex SDK to FlexJS?
>I know it’s possible because I implemented something similar when I had
>to work with GWT and it drastically reduced the number of events and
>event processing. So I was expecting us to keep this concept from the
>Flex SDK.
>But looking for proof for this, I couldn’t directly find anything.
>Do we still have that? If not, are we planning on having it in the
>future? What would need to be done to have it?

The Basic set does not have invalidation and hopefully will never have it.
 The underlying browser doesn't have a "run code then render display list"
concept.  I call the browser behavior "immediate".  If you set a property
the browser updates right away.  So far, we've been able to build our apps
without invalidation.

The Express set will hopefully be a composition of Basic and thus not have
invalidation and never need it, but you never know.

Other component sets are welcome to use invalidation if it helps.

You are correct that there can be extra updating if you don't use
invalidation, but the cost of an invalidation/validation system might
outweigh the benefits in many cases, and I think we can just optimize
certain special cases that are hot spots.  And have a component set that
supports invalidation for those who need it.  That's a key takeaway:  In
FlexJS we want to try to make sure there isn't just one way to solve
problems that have more than one right answer.

My 2 cents, other opinions welcome...
-Alex

Mime
View raw message