Performance: use React Native Render HTML explicit composite architecture

[jsamr]

@marcaaron

Details

Summary of changes:

1. A new component, HTMLEngineProvider, has been created. This component renders TRenderEngineProvider and RenderHTMLConfigProvider. All configuration props, including custom renderers, are now handled by this component, which is rendered at the root of the application (App.js).
2. RenderHTML component has been greatly simplified to a one-file component rendering RenderHTMLSource component.
3. A little fix has been provided regarding the <edited> element (see commit).

This refactoring follows closely guidance provided in the docs: https://git.io/JRcZb

Fixed Issues

#4123

Tests

There are no behavioral changes. If something should not work, it would break immediately.

QA Steps

N/A

Tested On

• Web
• Mobile Web
• Desktop
• iOS
• Android

Screenshots

N/A

[jsamr]

@marcaaron I am planning to do two benchmarks as we discussed in #4123; the only thing I am unsure is this:

I build the release native app then time when the FlatList onLayout is called (I know, not perfect) and log this to our log server

Can you provide me guidance on how to "log to your log server", and how to check those logs?

[marcaaron]

Can you provide me guidance on how to "log to your log server", and how to check those logs?

Ah to clarify, only Expensify staff can check these logs. But it's something I can help you with no problem.

[marcaaron]

Ok! Did some pretty basic benchmarking here on an Android release build. Unfortunately, I didn't see a huge difference in how long it takes to lists of chat messages. This PR is maybe 10 ms faster than the main branch - which seems inconclusive.

Not sure whether you have other ideas about what to test?

On the positive side, things didn't get slower and everything appears to work fine so I can't think of a reason not to recommend these changes.

[jsamr]

@marcaaron The thing is that onLayout will give you the first paint (depending on initialNumToRender, while this patch is interesting considering the cumulative cost of rendering each cell. My expectation would be a 200ms gain for 100 items; so you would have to set initialNumToRender to 100 to test my hypothesis :-) Moreover, if the render time of RenderHTML (7 to 11ms in my audit) is negligible compared to the render time of each cell, you might find 200ms negligible compared to the total render time of the first paint...

[marcaaron]

My expectation would be a 200ms gain for 100 items; so you would have to set initialNumToRender to 100 to test my hypothesis

Got it. That makes sense. I'm not sure there is any requirement that we load 100 or more items at once (at least not yet), but it's good to know it will be faster if we did.

[jsamr]

@marcaaron Great! I fixed some conflicts with main and marked this PR as ready for review. Tell me if there is anything else I should do!

[Luke9389]

No changes to request.

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[OSBotify]

🚀 Deployed to staging by @marcaaron in version: 1.0.85-10 🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅

[botify]

This has been deployed to production and is now subject to a 7-day regression period.
If no regressions arise, payment will be issued on 2021-09-01. 🎊

[OSBotify]

🚀 Deployed to production by @roryabraham in version: 1.0.86-11 🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	failure ❌
🕸 web 🕸	success ✅

[botify]

This has been deployed to production and is now subject to a 7-day regression period.
If no regressions arise, payment will be issued on 2021-09-06. 🎊