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

oh dear ... yes, Transaction ... what a typo I've got there :D

Other thoughts on this idea ?

Cheers


On Wed, Oct 23, 2013 at 6:10 AM, Brian Kardell <bkardell@gmail.com> wrote:

> 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
>>>
>>>
>>>
>>>
>>