[unimodules-react-native-adapter] Flush UI blocks when needed

[sjchmiela]

Why

Fixes #2288.

How

Adding a UI block wasn't making React run the blocks as soon as possible. 🤷‍♂

Test Plan

With this fix applied Camera.takePicture works as expected.

[ide]

setNeedsLayout actually performs layout and might be expensive on every addUIBlock call (I have not profiled this, though) -- alternatively, what do you think about mirroring UIManager's API and exposing a setNeedsLayout method that the Unimodule is responsible for calling?

[sjchmiela]

From my short debugging investigation it looked like React doesn’t do much if the layout hasn’t changed. (In _layoutAndMount, the first _dispatches return early, uiBlockWithLayoutUpdate too.) Is there some other place layout is being recalculated? 🤔

[ide]

I didn't look into the implementation _layoutAndMount very deeply, so it may be cheap to call it. My main concerns with this PR are (a) whether _layoutAndMount is expensive to call frequently and (b) whether there are other non-performance reasons we want to add a UI block without triggering layout. (Why does RN's UIManager not run _layoutAndMount when adding a UI block?)

[sjchmiela]

a) _layoutAndMount seems to be cheap to call frequently
b) Other React Native libraries dispatch calls to view managers via UIManager.dispatchViewManagerCommand, which somehow ensures that batch of calls is executed right away and afterwards, batchDidComplete is called, which triggers _layoutAndMount on RCTUIManager.

I think we could either change addUIBlock into executeUIBlock, which would 1. add and then 2. trigger _layoutAndMount (similar to UIManager.dispatchViewManagerCommand, but probably not batched) or use UIM.dVMC in our unimodules' code (like other libraries do), but then write our own implementation of handling Promises for these functions.

[ide]

change addUIBlock into executeUIBlock

I think this is a good idea -- we probably want a native API to add a block in addition to a JS API.

[sjchmiela]

What do you think about running UI blocks synchronously on the main thread?

[ide]

I think it'd be better to execute the UI blocks asynchronously by default for a few reasons:

• dispatch_sync can lead to deadlock. If we need synchronous execution, I think we should have a separate way to do that, ex: introduce a new method like [UIManager dangerouslyExecuteUIBlockSynchronously].
• If there are other UI blocks in the queue, we would run all of them. This might be a little expensive, and it'd be better to run the UI blocks at the start of the next frame so we have a full 16ms to run them.
• Generally, it is easier to change asynchronous code to be synchronous code instead of the other direction. So if we decide that synchronous execution makes more sense, perhaps with Fabric, it will be easier to make that change.

Additionally, it looks like UIManager handles running UI blocks in flushUIBlocksWithCompletion. It gathers all the currently pending UI blocks, and then executes them on the main thread (with dispatch_async). Since that behavior works for the rest of RN, I'd naively expect it to work for Unimodules too.