actually I don't think this works. You've still gotta wait a frame w/ double rAF after synchronous setState
-
-
Replying to @owencm
ah - was riffing on preact here, which can be configured to use rAF for async setState. Agreed though regarding the shared queue
1 reply 0 retweets 1 like -
Replying to @_developit
I think this would be great if Chrome and WebKit didn't have the bug with rAF linked in the post...
1 reply 0 retweets 2 likes -
Replying to @owencm
: at the same time, is it a bug? I'm not entirely convinced that it is.
2 replies 0 retweets 0 likes -
Replying to @slightlylate @_developit
I wasn't sure but Shane thinks so. Edge implements it by waiting for next frame too, WebKit doesn't
1 reply 0 retweets 0 likes -
Replying to @owencm
: I could see both sides of this. I'd actually like an options bag to specify which; soonest vs. next.
2 replies 0 retweets 2 likes -
Replying to @slightlylate @_developit
right. I think most usage intends in waiting for next frame, i.e. Do some stuff and then let me know when I'm done
2 replies 0 retweets 2 likes -
also if rAF returns in *this* frame, it's weird to me that you can chain to get next frame?
1 reply 0 retweets 1 like -
Replying to @owencm
: also fair. The other argument is that if you want this-frame timing, use Promise.resolve().then() (modulo bugs). /cc
@_developit2 replies 0 retweets 1 like -
Replying to @slightlylate @_developit
I need to learn more about promises wrt tasks and frames. I'm sure there's a Jake or Paul somewhere that can help
2 replies 0 retweets 2 likes
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.