React: schedule callbacks in renderer

[dakom]

From looking at an early implementation of custom Fiber renderer (https://github.com/manaflair/mylittledom/blob/master/sources/term/react.js#L437) it seems there is a callback that is not in the official renderers: scheduleAnimationCallback()

Additionally, there's a callback in the official renderers which is not in the tutorial/example at https://github.com/nitin42/Making-a-custom-React-renderer - scheduleDeferredCallback()

Lastly, both of these are referenced in the guide at https://github.com/acdlite/react-fiber-architecture

So this begs the question - are custom renderers meant to implement these? If so, what are the best practices for doing so?

In a more general sense - do custom renderers have any relationship with setting ProrityLevels or _affecting_ the scheduler?

[gaearon]

The animation priority and callback have been removed. If I remember it right it was because they were already expressible with existing API (e.g. flush synchronously inside a coalesced rAF call).

No, custom renderers don't currently need to be aware of priorities and scheduling. The only need to provide an idle callback scheduling mechanism.

That said they do have access to the few methods directly exposed on the renderer, and can further expose them to the user. For example see how ReactDOM exposes flushSync.

[dakom]

Thanks @gaearon ! I have a few more followup questions if you don't mind...

an idle callback scheduling mechanism.

1. Is this done by providing something to scheduleDeferredCallback?

2. It seems the Noop and Test renderers do some manual managing of this - but in different ways, while the Art renderer uses the prebuilt ReactDOMFrameScheduling.rIC Can you please explain a little more about the reason why one approach is taken vs the other in each of those cases?

3. What is the useSyncScheduling flag for - would I ever want to turn it off?

[iamdustan]

1. Yes. For example in browsers it is the requestIdleCallback method.
2. Noop and test renderers are run primarily in Node. Noop renderer was originally built to test and explore the fiber reconciler. (Extent of my knowledge)
3. useSyncScheduling keeps the reconciler in sync/compatibility mode. You can definitely turn it off to use React in the future async/prio manner, but there will be bugs since that set of features is still under development.

[gaearon]

1. Yes.

2. Noop and Test renewers are not used in real browsers and just do the simplest thing possible. DOM renderer uses browser's requestIdleCallback but falls back to a polyfill if it's not available.

3. It forces everything to be synchronous. Tests should always be synchronous for simplicity. But in the browser, we want to (eventually) enable async scheduling (that's what Fiber architecture is all about). However we can't just enable it immediately because it's not quite ready. So we leave it disabled and will offer a way to gradually opt into it.

[iamdustan]

Haha. Seeing how similar my answer was was very reassuring that I kinda know what I’m talking about 😄

[gaearon]

Lol

[dakom]

Interesting... if I'm using the renderer to _only_ drive animation (for example, a WebGL renderer - or if outside the browser, a manual screen repaint via SDL or something), would I still want scheduleDeferredCallback to be like requestIdleCallback or would I want to instead force it to always be "now" ?

[gaearon]

It would make sense for me to use requestIdleCallback if you can. The deferred callback is used for low-priority work. For example components that aren’t visible but might become visible in the future. React can start working on them in idle periods.