Upgrade to Pro — share decks privately, control downloads, hide ads and more …

React Native at Microsoft or: How I Learned to Stop Worrying and Love the Brownfield

React Native at Microsoft or: How I Learned to Stop Worrying and Love the Brownfield

How we use React Native at Microsoft... but the tech part. No boring everything is awesome marketing BS, let's dive into the nitty gritty.

Lorenzo 'kelset' Sciandra

November 23, 2021
Tweet

More Decks by Lorenzo 'kelset' Sciandra

Other Decks in Programming

Transcript

  1. Born & raised in Piedmont, graduated at PoliTO, moved to

    London in 2017. Senior Software Engineer @ Microsoft React Native maintainer Lorenzo Sciandra (@kelset) Hello, and welcome! [email protected] - @kelset 2/37
  2. Talk overview React Native as a Concept Deep dive: the

    desktop platforms Pushing it forward React Native’s impact at MS Deep dive: the multi monorepo world 1 2 3 4 5 (I swear, I usually don’t do this) [email protected] - @kelset 3/37
  3. React Native: greenfield By “greenfield”, we mean the standard RN

    approach to mobile development. Native components and APIs Native Mobile Async queue of JSON messages Bridge* Business logic JavaScript *let’s ignore the RN rearchitecture for this talk. if you want to learn more: aka.ms/rnrearch [email protected] - @kelset 5/37
  4. React Native: brownfield By “brownfield”, we define a pre-existing native

    app to which React Native is added in a second phase. Additional feature or section of the app JavaScript Bridge Standard iOS/Android app Native Mobile Custom initialization of the RN domain [email protected] - @kelset 6/37
  5. The revolution: exploding the brownfield How many doors can I

    open, if I expand the brownfield concept? Can be abstracted and generalized: it’s reusable! JavaScript Can be tailored to the app Some sort of Bridge Doesn’t have to be mobile Any platform [email protected] - @kelset 7/37
  6. Expanding the boundaries of brownfield at Microsoft When you see

    RN as an enabler, there are many possibilities. Can be shared across the platforms, apps and codebases! JavaScript* Tailored to the platform requirements EACH app its own BRIDGE APPROACH ANY app on ANY platform * JavaScript is the most used programming language, according to StackOverflow (aka.ms/sosurvey) [email protected] - @kelset 8/37
  7. The multi monorepo world At Microsoft, we have many repositories.

    Like, a lot. Most times, shared as npm packages JavaScript Experiences Codebase 1…N Its Bridge ANY app on ANY platform Codebase 3…N Bundlers, custom Babel plugins, etc. JavaScript Tooling Codebase 2…N Usually, one per platform [email protected] - @kelset 9/37
  8. RN: overview of Microsoft’s approach RN core Mobile apps RN

    Win/macos Desktop apps JavaScript Experiences JavaScript Tooling [email protected] - @kelset 10/37
  9. Desktop experience Our apps are used a lot on desktop

    platforms, via Windows and macOS (and web): (and more) [email protected] - @kelset 12/37
  10. React Native Windows FB (Meta) didn’t want to work on

    it – so it has always been defined as an “out-of-tree” platform, meaning that it’s an add-on on top of RN core. Not only Windows: means also Xbox, HoloLens, etc.. UWP (“Windows SDK”) What we maintain (in its own repo) UWP Native Modules (& more) Standard RN code JavaScript The FB (Meta) repo RN core [email protected] - @kelset 13/37
  11. React Native macOS RN macOS, because of its ”closeness” to

    its iOS counterpart, is instead a fork. macos What we maintain Standard RN code JavaScript RN core (forked) [email protected] - @kelset 14/37
  12. Does it work? Let’s mention a couple of real-world examples:

    Xbox https://www.windowscentral.com/xbox-app-pc-gets-speed-boost-ditching-electron-react-native-uwp FB (Meta) Messenger Desktop Keep your eyes out for ReactConf on Dec 8th: https://conf.reactjs.org/ https://reactnative.dev/blog/2021/08/26/many-platform-vision#expanding-to-new-platforms [email protected] - @kelset 15/37
  13. Challenges of Open Source ž Maintaining 2 extra platforms introduces

    a big overhead: ž We need to balance doing what we need with what happens in RN core ž This makes it hard to have feature parity across the various platforms (see macos) ž Despite collaborating with FB directly, the feedback loop can still be improved ž We have weekly syncs to address main challenges, but FB’s approach to OSS means that there’s a lot of unknowns always ž OSS is hard! ž And when you are Microsoft, the barrier is even higher (security, tooling, practices, etc.) [email protected] - @kelset 16/37
  14. Remember this? Let’s explore the lines: how is the code

    shared? Most times, shared as npm packages JavaScript Experiences Codebase 1…N Its Bridge ANY app on ANY platform Codebase 3…N Bundlers, custom Babel plugins, etc. JavaScript Tooling Codebase 2…N Usually, one per platform [email protected] - @kelset 18/37 Codebase 1: 3k+ developers 3.5M files Codebase 3: 1.5k+ developers 830 packages Codebase 2: 300-ish developers 40k files
  15. Challenges of a multi-monorepo world Application repo JS Experiences JS

    Tooling Separating the dev from the toolchain Keeping dependencies aligned [email protected] - @kelset 19/37 Am I using the right OSS libs? Updating RN – when and by who? What if I target multiple RN versions?
  16. Problem #1: separate developer from toolchain We need some way

    for the JS developers to test their code in isolation - without the overhead of more RN apps to maintain. developer Application Repo 1 Repo 2 [email protected] - @kelset 20/37
  17. Solution #1: React Native Test App ž REACT NATIVE TEST

    APP is a super compact RN app that hides the complexity of a greenfield app below the surface. ž The developer only needs to worry about the JavaScript code for their experience – but can still have full control of the native code (if needed). ž It supports many different RN versions, via a simple configuration change. if you want to learn more: https://github.com/microsoft/react-native-test-app [email protected] - @kelset 21/37
  18. Problem #2: dependencies alignment How can we make sure that

    code is compatible across different repositories? RN v.X Package A: v1 Package B: v2 RN v.Y Package A: v1 Package B: v3 RN v.Z Package A: v3 Package C: v3 RN v.X Package C: v1 Package B: v1 [email protected] - @kelset 22/37
  19. Solution #2: dep-check ž DEP-CHECK is a tool that can

    understand the dependencies in a package.json and can modify it, based on a series of curated profiles. ž 7 versions of RN supported, over 40 libraries curated ž It can even fix misconfigured package.json – the developer simply defines a local dep-check configuration, and the tool will take care of declaring the right packages, at the right version, in the right section. if you want to learn more: aka.ms/dep-check [email protected] - @kelset 23/37
  20. Even more platforms: RN in AR & VR “Babylon.js is

    a powerful, beautiful, simple, and open game and rendering engine packed into a friendly JavaScript framework." if you want to learn more: https://www.babylonjs.com/reactnative/ [email protected] - @kelset 26/37
  21. Even more tooling: RNX-KIT We are building more tools to

    enable even more people, and do it in an OSS way: https://github.com/microsoft/rnx-kit Bundlers, custom Babel plugins, etc. JavaScript Tooling = [email protected] - @kelset 27/37 👀
  22. Even more tooling: exploring Metro’s potential Metro is powerful bundler,

    with some room to grow: And keep an eye on Bundle Working Group! 👀 👀 [email protected] - @kelset 28/37
  23. Even more tooling: Hermes on desktop We are experimenting with

    Hermes: https://github.com/microsoft/hermes-windows Read more at: https://microsoft.github.io/react-native-windows/docs/hermes Native Mobile Bridge JavaScript [email protected] - @kelset 29/37
  24. Even more OSS: React Native releases ž We are directly

    involved in the RN release process ž We are helping improving the testing and infra pipelines ž In the future: ž Potentially, an LTS ž More structure and clarity around the process itself [email protected] - @kelset 30/37
  25. In conclusion, internally • React Native is a powerful enabler

    • It’s allowing us to hire JavaScript developers to work on native projects • It’s indirectly forcing an alignment of tooling, APIs and mindsets [email protected] - @kelset 32/37
  26. In conclusion, externally • We have a great investment in

    RN, that is reflected by a huge involvement in Open Source: • RN Windows & macOS • Releases • Hermes • We are constantly trying to push the boundaries: • Bundle group • Rnx-kit • <insert secret project #1212982374189723> [email protected] - @kelset 33/37
  27. Resources My contacts: ž Lorenzo Sciandra, SSE@Microsoft ž @kelset on

    twitter (DMs open) – GitHub – everywhere! ž [email protected] ž RN re-arch talk: https://www.youtube.com/watch?v=7gm0owyO8HU ž RNEU21 talk: https://www.youtube.com/watch?v=DAEnPV78rQc Microsoft & RN ž https://github.com/microsoft/react-native-windows ž https://github.com/Microsoft/react-native-macos ž https://github.com/microsoft/rnx-kit ž https://github.com/microsoft/react-native-test-app ž https://github.com/microsoft/hermes-windows ž https://github.com/BabylonJS/BabylonReactNative React Native ž https://github.com/facebook/react-native ž https://github.com/reactwg/react-native-releases/discussions ž https://github.com/facebook/metro ž https://github.com/facebook/hermes [email protected] - @kelset 36/37