Re: How about a global `requestTransition(callback)` mechanism ?

Transaction?
On Oct 21, 2013 12:23 PM, "Andrea Giammarchi" <andrea.giammarchi@gmail.com>
wrote:

> up
>
>
> On Thu, Oct 17, 2013 at 4:47 PM, Andrea Giammarchi <
> andrea.giammarchi@gmail.com> wrote:
>
>> Something pointless to discuss on Twitter as I am doing right now :-)
>>
>> I wonder if I am the only one that would like to have the possibility to
>> avoid any visual rendering on the screen during multiple DOM actions such
>> adding classes to different nodes, change the scrollTop after dropping an
>> element that is not even visible on the screen but up there in the body
>> content or who know what else.
>>
>> It's not the first time I find myself in a situation where
>> requestAnimationFrame is badly/hopefully used only to speed up the amount
>> of flicks I could have with multiple changes at once and specially in the
>> mobile world (on desktop things are fast enough I cannot notice).
>>
>> I understand that browsers should optimize already multiple operations at
>> once but these are inevitably in troubles doing this implicitly when it
>> comes to access classes, add more that could change layout for everything
>> else around, etcetera, etcetera.
>>
>> How much effort would be to be able to explicitly inform the browser that
>> many DOM operations will be performed at once and that all computation
>> (reflow, repaint) should be avoided until the callback has finished its
>> execution ?
>>
>> Similar, but actually simpler, mechanism we have for
>> `requestAnimationFrame` except this one will take care of "transitions" (or
>> the equivalent of SQL transitions)
>>
>> ```javascript
>>
>> // example
>> requestTransition(function () {
>>   // do anything you want
>>   document.body.classList.add('whatever');
>>   documentquerySelector('div.stuff').appendChild(
>>     document.createElement('p')
>>   ).classList.add('a', 'b', 'c');
>>   document.querySelector('div.drop').remove();
>>   // offsetHeight of that element will the the one
>>   // **before** this transition, no need to reflow, repaint
>>   // nothing in here, the DOM is still as it was before
>>   // this callback ws executed
>>   document.body.scrollTop -=
>>     document.querySelector('div.drop').offsetHeight;
>>   transitionCompleted();
>> });
>>
>> // invoked later on
>> function transitionCompleted() {
>>   // now the screen is showing
>>   // the DOM after all things happened before
>>   // we have just avoided N potential flicks
>>   // and maybe lagged some extra ms ... who cares ?
>>   // flicking is worse than a tiny delay, imho
>> }
>>
>> ```
>>
>> At least in my experience a similar approach could solve TONS of modern
>> WebApp problems but of course I would like to know if anything I've written
>> or proposed makes sense to you too.
>>
>> Thoughts?
>>
>> Thanks for reading and Best Regards,
>>     Andrea Giammarchi
>>
>>
>>
>>
>