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

Lorenzo S.
November 23, 2021

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 S.

November 23, 2021
Tweet

More Decks by Lorenzo S.

Other Decks in Programming

Transcript

  1. React Native at Microsoft

    or: How I Learned to
    Stop Worrying and
    Love the Brownfield
    [email protected] by

    View Slide

  2. 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

    View Slide

  3. 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

    View Slide

  4. How things shifted, when I joined Microsoft
    React Native as a Concept

    View Slide

  5. 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

    View Slide

  6. 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

    View Slide

  7. 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

    View Slide

  8. 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

    View Slide

  9. 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

    View Slide

  10. RN: overview of Microsoft’s approach
    RN core
    Mobile apps
    RN Win/macos
    Desktop apps
    JavaScript
    Experiences
    JavaScript
    Tooling
    [email protected] - @kelset 10/37

    View Slide

  11. Expanding React Native past mobile
    Deep Dive: the desktop
    platforms

    View Slide

  12. Desktop experience
    Our apps are used a lot on desktop platforms, via Windows and
    macOS (and web):
    (and more)
    [email protected] - @kelset 12/37

    View Slide

  13. 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

    View Slide

  14. 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

    View Slide

  15. 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

    View Slide

  16. 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

    View Slide

  17. Deep dive: the multi monorepo
    world
    Let’s talk about the scale of codebases at MS

    View Slide

  18. 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

    View Slide

  19. 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?

    View Slide

  20. 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

    View Slide

  21. 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

    View Slide

  22. 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

    View Slide

  23. 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

    View Slide

  24. Do you like demos?
    Check out our talk at RNEU21!
    link
    [email protected] - @kelset 24/37

    View Slide

  25. Pushing it forward
    We are not quite done, yet

    View Slide

  26. 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

    View Slide

  27. 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
    👀

    View Slide

  28. 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

    View Slide

  29. 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

    View Slide

  30. 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

    View Slide

  31. React Native’s impact at MS
    Closing off

    View Slide

  32. 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

    View Slide

  33. 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

    [email protected] - @kelset 33/37

    View Slide

  34. Did I really stop worrying and
    learned to love the brownfield?
    (backstory time!)

    View Slide

  35. Thank you for listening!

    View Slide

  36. 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

    View Slide

  37. Q&A time!

    View Slide