react & greensock & onRequestAnimationFrame

[erikb]

Was curious about timing issues between react and greensock.

Specifically, was curious about onRequestAnimationFrame priority when tweening vanilla js objects passed into React setState to change how elements are rendered in the React render() call.

 

So, I built my codepen to see if react or greensock would go first - and it seems, based on console output of Tweenmax.ticker.frame,  that greensock updates first, and then react renders (which is what I would want to happen on every tick).

 

I am aware this is a different way of using react and greensock than what you've published here - 

 - but for many of my use cases, I tween through a proxy object, hence my inquiry.

 

I am wondering - is there a way to ensure that greensock is called first 'on the tick' before react render calls are made?  Where / how would this sort of thing be coordinated and set between the two libraries? 

 

I took a gander at the react source at https://unpkg.com/react@16.9.0/umd/react.development.js specifically around `requestHostCallback` where there is instructions on how to use rAF.  Not much I see on first pass regarding prioritization with other libraries.  

 

Your insight into this issue and advice greatly appreciated.  Thank you!

 

See the Pen bGbJgaw?editors=0010 by jedierikb (@jedierikb) on CodePen

[OSUblake]

13 minutes ago, erikb said:

I am wondering if there is a way to ensure that greensock is called first 'on the tick' before react render calls are made?

 

Maybe I don't understand your question, but isn't that what's happening? After every setState call, it will cause a render. But setState works asynchronously so there is no way to guarantee when it will actually render. I'd imagine gsap could potentially update several times before React gets around to rendering.

 

 

[erikb]

17 minutes ago, OSUblake said:

 

Maybe I don't understand your question, but isn't that what's happening? After every setState call, it will cause a render. But setState works asynchronously so there is no way to guarantee when it will actually render. I'd imagine gsap could potentially update several times before React gets around to rendering.

 

I suppose you are right - tween goes first, and that queues a repaint.  Yes, you are right.

 

I guess I am wondering if there is a way to ensure that react will render on the same rAF that the tween onUpdate was called from... (assuming react is queuing updates on the rAF, which is looks like it does).  OR maybe that is an abstraction barrier I don't need to worry myself about

[OSUblake]

29 minutes ago, erikb said:

OR maybe that is an abstraction barrier I don't need to worry myself about

 

Probably. And after reading the comments for requestHostCallback, it sounds like React is doing something with the event loop.

 

 

I don't know how React works under the hood, but some rendering libraries use promises instead of rAF to schedule rendering.