synchronous forceUpdate

[KevinDoughty]

The comment for the function forceUpdate says:
"Immediately perform a synchronous re-render of the component"

This PR restores that behavior. Does not cause any tests to fail. I cannot find much information on a "double render" problem which sounds dubious to me.

Animation libraries need timely updates and there is no reason to arbitrarily deny that. Please use setState({}) instead.

See:
#1939

[github-actions]

📊 Tachometer Benchmark Results

Summary

A summary of the benchmark results will show here once they finish.

Results

The full results of your benchmarks will show here once they finish.

_{tachometer-reporter-action v2 for Benchmarks}

[KevinDoughty]

My mistake, tests fail. Will try again soon.

[marvinhagemeister]

Seeing that the comment was made 5 years ago, it's very likely that it is out of date. In general you don't want to kick off a render whilst another one is currently being processed. That was the main reason for us going with enqueueRender() for .forceUpdate() if memory serves correctly.

The current scheduling mechanism uses a microtask which is the smallest unit of scheduling in the event loop and it runs <1ms. Did you run in a specific problem where that caused problems with an animation?

[marvinhagemeister]

Haven't played with the view transitions API yet, but it looks like it might require a synchronous flush of the queue: #3929

[sschultze]

Haven't played with the view transitions API yet, but it looks like it might require a synchronous flush of the queue: #3929

@marvinhagemeister The flush of the queue actually doesn't have to be synchronous. The callback passed to startViewTransition can return a promise, as described here.

But I think that there's a chance that 3rd party libraries will use React's flushSync with the View Transition API, so it's probably better to implement this rather than introducing another async function.

[KevinDoughty]

Solved my problem without synchronous renders. Thanks.