Interesting. This is new to me as well. What’s interesting to me is that it seems like FlexJS should (mostly) not have this problem.
If I’m reading it correctly, it’s reading geometric properties from the DOM which cause the reflow. Since the vast majority of reads in FlexJS is actually on the flexjs wrappers around the DOM elements, most reads should not trigger reflow. The only major exception which comes to mind is the use of DisplayUtils methods which use getBoundingClientRect() and the like. On Jan 6, 2017, at 9:52 PM, OmPrakash Muppirala <bigosma...@gmail.com> wrote: > On Fri, Jan 6, 2017 at 8:07 AM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> On 1/6/17, 1:04 AM, "Christofer Dutz" <christofer.d...@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. >> > > I have been looking at FastDOM [1] which batches DOM manipulations so we > don't have 'layout thrashing' [2] > > When I get some time, I will try to do some benchmarks and see if we can > identify hotspots and route them through FastDOM calls. > > Thanks, > Om > > [1] https://github.com/wilsonpage/fastdom > [2] http://wilsonpage.co.uk/preventing-layout-thrashing/ > > > >> My 2 cents, other opinions welcome... >> -Alex >> >>
