Integrate May 5th RN nightly build.

[rectified95]

Few changes this time. Commits facebook/react-native@7e05480...438a4cf

• removed fork of MapBufferBuilder.cpp - Closes Remove fork of MapBufferBuilder.cpp #7591
• getViewManagerConfig() got deprecated
• filed Add ToggleButton accessibility role  #7856 about new ToggleButton accessibility role.
• filed Re-enable Switch measure test #7929 to track re-enabling a measurement test for Switch pending upstream fix ingestion

Microsoft Reviewers: Open in CodeFlow

[NickGerleman]

Looks like a new switch JS component was shipped. Integration tests are having trouble measuring it, but does it work correctly manually?

[asklar]

anyone have more context on getViewManagerConfig() being deprecated / should we call this out in changelog?

[NickGerleman]

Skimming through PRs, I think these are the ones we probably want to validate manually:

• facebook/react-native@382e90c
  • Usage of APIs in an area with stubs
• facebook/react-native@3775010
  • In case we have internal usages in forked components
• facebook/react-native@6d04a46
  • Since you added that one 😀
• facebook/react-native@ab66741
  • A whole new JS implementation for Switch
• facebook/react-native@da899c0
  • New AccessibilityRole, which you logged

Note that we do not care much about facebook/react-native@2b67631 (bumping the hermes-engine npm package) since we control that for Windows via NuGet package version.

Picking these commits is more of an art than a science. It helps when you learn what breaks we see. Some of what we care about here ends up being:

• Anything at the RNW RN Core boundary
  • E.g. anything directly interacting with a native component
• Platform-specific instance management code (e.g. Instance, NativeToJSBridge, JSIExecutor)
• JS Engine or JSI changes
  • Our implementations live in other repos
  • And, we think they kind of have to unless we impacted RNW dev experience
• JS logic around desktop-specific behavior
  • E.g. anything we forked to add mouse support
• OSS packages
  • E.g. CLI, Metro
• Code-generation frontend
  • Backend (e.g. Android) we don't much care about
• RNTester
  • Mostly just custom examples at this point
• New usages of unimplemented APIs
  • E.g. if a property becomes needed for more regular operation
• Anything possibly compiler specific

[NickGerleman]

cc @HeyImChris who will also have some experience from RN macOS integration. Have anything to add to the above list that you've encountered for macOS?

[asklar]

meta: curious about how RN breaking changes like these are marked; if they're not, it would be good to establish a process to do so : )

[NickGerleman]

meta: curious about how RN breaking changes like these are marked; if they're not, it would be good to establish a process to do so : )

They aren't really breaking to the general public, so they usually aren't marked in my experience. We are working at what are essentially private API boundaries. There are definitely cases where we can make a cleaner, more public or platform-neutral boundary in upstream code (or push that new changes do that 😉).

[NickGerleman]

@TheSavior I’ve gotten the take that FB internal also has some custom platforms. Are there any tags/labels on internal stacks which alter the paper view manager boundary?

[elicwhite]

@NickGerleman I'm not sure what you mean, can you elaborate?

For the new Switch component, one of the work streams on our team right now is to make React Native concurrent mode compatible. This has involved rewriting a lot of our components. We have been A/B testing those rewrites in prod to verify neutral metrics before we replace the old implementation.

[NickGerleman]

If an engineer changes interaction with a native component, do they ensure compat with React VR, or other platforms that are not Android/iOS?

The meta is I think finding way to create signal for changes which requires attention of anyone with native implementations of stock components.

[elicwhite]

Ah. It depends, but we aren't in that ideal state. The group working on the architecture don't currently focus on compact for other platforms today. They are working on parity and performance of the new architecture vs the legacy architecture. While that group doesn't block their work on other platforms having implementations already, they do make sure, as best they can, that their approaches and boundaries could be implemented for the other platforms.

For the group working on the core components, they actively design their APIs with the desktop group, although the implementations start on mobile because the other platforms are downstream forks (like microsoft's GitHub repos)

For the meta, we could clearly still improve the workflow here.

[NickGerleman]

Fix for the test is in facebook/react-native#31629

For now you can feel free to skip the test if we will integrate this soon, and everything else is working.

[ghost]

Hello @rectified95!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.