RFC0759 - React Native Frameworks

[cortinico]

Hi all,
Today we're excited to share an RFC to introduce the concept of React Native Frameworks.
You can find the rendered version here

We encourage partners, libraries developers, framework developers and member of the React Native Ecosystem to read it through and share your feedback.

Important

This RFC is open for comments till Monday 26th February 2024 (extended from 19th February)

Summary

This RFC defines the concept of React Native Frameworks: frameworks built on top of React Native to provide production-ready applications. With this document, we intend to declare what are the responsibilities of React Native itself vs. responsibilities of React Native frameworks.

By defining what React Native is and is not responsible for, we can improve the focus and stability of React Native and ensure that reliable extension points are available where needed.

We’re formalizing this concept now as, ultimately, we want our users to build production-grade applications while experiencing a top-notch developer experience.

We believe most of our users should be using a React Native Framework, and this document explains what exactly this means and how we can achieve this goal.

[brentvatne]

love it! a well-defined, focused, and stable core with thoughtful extension points is going to really help the react-native dx tooling ecosystem flourish.

[cortinico]

Thanks for the feedback!

[grabbou]

Awesome RFC! Thanks for the great work. I am really excited that we're describing and formalising the connection between React Native core and ecosystem of solutions around it.

This is going to open up a whole new segment of development in the community and I am looking forward to seeing some interesting React Native "Lite" Frameworks that are going to be highly specialised in certain workflows, while having a minimal abstraction layer.

[grabbou]

My only worry is the potential future fragmentation in available module structures and their support by frameworks. Let's imagine we have 4 frameworks in about 2 years from now. If there's no standard way to link native dependencies, it may impose additional maintenance burden on library authors to support all popular architectures and cause confusion amongst developers when installing a library.

Theoretically, there isn't much that can go wrong here. As long as we're using CocoaPods and Gradle under the hood, all solutions would be similar as there's a limited number of scenarios to support.

I wonder whether Community CLI and some of its internals could be rebranded as "Bare React Native Framework" package that other framework developers can use to build on top. It could provide some essential requirements as to what workflows have to be supported in order to pass the compliance test. It could also be one of the requirements when endorsing a framework that it must support certain basic workflows, such as auto-linking dependencies.

[zoontek]

I agree on this one.

Let's say tomorrow there's a new framework that chooses to have a custom CLI and autolinking system because they truly think it's the best way to improve their users' DX. This decision will create additional work for library maintainers, as they will have to develop new, specific plugins.

That's already (kinda) an issue with Expo, as some libraries require editing additional "native" files. Expo has its custom API for that (using @expo/config-plugins), which actually helps users a lot. However, it's not standardized. Imagine four or five frameworks each having their custom way to create these kinds of plugins.

[brentvatne]

Let's imagine we have 4 frameworks in about 2 years from now. If there's no standard way to link native dependencies, it may impose additional maintenance burden on library authors to support all popular architectures and cause confusion amongst developers when installing a library.

I think there could potentially be room for something like autolinking in core, but I'm hesitant to suggest that we should use what we have today, because it is rather slow and limited (eg: it's the main speed bottleneck for us in @expo/fingerprint and does not support transitive dependency linking). That said, I fully expect that any framework that arises will continue using RNC autolinking, as this is the de facto standard for modules built with the React Native core module API, and for anything to truly replace it, it'd be necessary for it to be API compatible / a drop in replacement.

Another possible approach for core is that React Native doesn't end up providing an implementation of autolinking directly, but instead defines a common schema that library authors can use and frameworks can build support for.

That's already (kinda) an issue with Expo, as some libraries require editing additional "native" files. Expo has its custom API for that (using @expo/config-plugins), which actually helps users a lot. However, it's not standardized. Imagine four or five frameworks each having their custom way to create these kinds of plugins.

If another framework is interested in following the same sort of pattern that Expo established with CNG then I know that we at Expo would be happy to work with them to see where we should make parts of this toolchain more generic to minimize the maintenance costs for library authors. We want to and are incentivized to ensure that support for CNG is as easy as possible for library authors, because this provides a better experience for all users of the feature.

Additionally, it's worth noting that it's also possible to use @expo/config-plugins in other frameworks, see the usage in react-native-test-app for reference, or byCedric/custom-prebuild-example which demonstrates using config plugins to generate macOS and Windows projects.

@blakef summarized where we landed on this topic in a previous RFC: #637 (comment)

[grabbou]

Another possible approach for core is that React Native doesn't end up providing an implementation of autolinking directly, but instead defines a common schema that library authors can use and frameworks can build support for.

That could be very interesting.

If another framework is interested in following the same sort of pattern that Expo established with CNG then I know that we at Expo would be happy to work with them to see where we should make parts of this toolchain more generic to minimize the maintenance costs for library authors

I think we could discuss whether we can come up on a standard (as a RFC) and have a reference implementation. I would be very happy to contribute to it myself, as I have historically worked on auto linking and I am always tinkering with some toolchains for different use cases.

[grabbou]

Additionally, it's worth noting that it's also possible to use @expo/config-plugins in other frameworks, see the usage in react-native-test-app for reference, or byCedric/custom-prebuild-example which demonstrates using config plugins to generate macOS and Windows projects.

Yup, I can definitely see a scenario where a new framework ends up providing additional specialised layer on top of Expo. I've been looking into it as well and to be honest, it's very pluggable which is very nice from Expo side.

[zoontek]

This could be included in the @react-native-community/cli-tools package and benefits the whole ecosystem right now.

I already do similar stuff in the react-native-bootsplash CLI, would love to have this available and white label, as it's currently kinda hard for me to write a @react-native-community/cli plugin + an expo plugin without duplicating the whole logic.

Imagine being able to edit any app.json like this:

{
  "name": "RNBootSplashExample",
  "displayName": "RNBootSplashExample",

  "plugins": [
    [
      "react-native-bootsplash",
      {
        "background": "#F5FCFF",
        "logo": "./svgs/light_logo.svg",
        "logoWidth": 100
      }
    ]
  ]
}

[cortinico]

Another possible approach for core is that React Native doesn't end up providing an implementation of autolinking directly, but instead defines a common schema that library authors can use and frameworks can build support for.

That's the direction where we're heading towards.
Practically autolinking as it is today, it's composed by two components:

1. Integration points - They should stay inside react-native. Those are APIs like ReactPackage. Practically speaking that's where you can 'feed' modules/components/libraries to core so that they're accounted as part of the build and runtime of react native.
2. Discovery logic - This should stay outside react-native. This is where react-native config and other discovery mechanism are executed (i.e. on Android we search for .java/.kt files which implements the ReactPackage API exposed by core). Here frameworks can implement their own discovery mechanisms.

[thymikee]

@zoontek we'd be happy to collaborate on how to make linking easier for libraries that also support Expo plugins, feel free to reach me out on Discord

[zoontek]

I agree on this one.

Let's say tomorrow there's a new framework that chooses to have a custom CLI and autolinking system because they truly think it's the best way to improve their users' DX. This decision will create additional work for library maintainers, as they will have to develop new, specific plugins.

That's already (kinda) an issue with Expo, as some libraries require editing additional "native" files. Expo has its custom API for that (using @expo/config-plugins), which actually helps users a lot. However, it's not standardized. Imagine four or five frameworks each having their custom way to create these kinds of plugins.

[zoontek]

In those terms, is it acceptable to remove certain parts of react-native? For example, I create a React Native framework that removes some props I consider harmful in the StatusBar module, or entirely removes certain APIs / Components, such as dropping Modal to provide a better alternative.

[cortinico]

In those terms, is it acceptable to remove certain parts of react-native?

As a principe: nope it's not. The reality is a bit different in the sense that we know there are some core components/API with better community alternatives.

Our goal is to work with Framework/Library developers to understand those gaps and streamline the core as much as possible. This follows the same direction of the Lean Core initiative in 2019. We want the core API to be streamlined and extensible so you don't need to "remove" anything from react-native.

[booker-dragon]

Maybe the framework should provide an interface for any third party to develop their own OTA update functionality, so developer could choose whatever provider they want but to ensure the basic OTA functionality work the same across all different providers

[cortinico]

As @brentvatne mentioned in this other comment, yes we'd love to have more formal APIs and RFCs a around those APIs.

Historically, we never really provided clear boundaries/APIs for framework developers, OTA updates is one of this scenario but not the only one.
As the React Native matures, we'll be providing more precise API boundaries and documentation for developers.

so developer could choose whatever provider they want but to ensure the basic OTA functionality work the same across all different providers

Yup, React Native will be providing the core functionalities, and Frameworks can customize them by offering top-notch developer experience with their own flavor.

[lindboe]

This bullet is not totally clear to me. Why is "learn only once how to write a native component" the particular example used here? I'm not sure how to connect it with the intention of the rule.

Also, I'm not sure hard-fork and soft-fork are widely-known terms, I would consider defining those more clearly.

[cortinico]

Does my other comments clarify here? #759 (comment)

[lindboe]

Again, I'm having trouble understanding why "forking" is the focus here, especially for a library. Like if I'm using the third-party react-native-foo library, I need to add some functionality but the maintainer is not responsive, I would expect I could fork and add what I'd like to my version. What's the problem there?

[cortinico]

Like if I'm using the third-party react-native-foo library, I need to add some functionality but the maintainer is not responsive, I would expect I could fork and add what I'd like to my version. What's the problem there?

Forking an unmaintaied library is actually encouraged, as you're providing a solution to one of the biggest pain point of React Native (source).

The sentence here refers to "forking the ecosystem". We want to avoid situations where a framework foo- forks a core API and starts encouraging developers do develop libraries on top of that forked API. So you'll end up having say a foo-push-notification libraries, rather than a react-native-push-notification camera that can easily be used between different frameworks.

[thymikee]

I'm happy about the direction we're going with this RFC, let's ship it

[thymikee]

Is annotating private APIs for frameworks a temporary step before making it public?

[cortinico]

Nope not really. APIs that are Framework annotated are those where we reached an agreement with Framework developers that they'll be the sole users. So they should not be considered stable as they could break if we iterate further on them.

[thymikee]

@zoontek we'd be happy to collaborate on how to make linking easier for libraries that also support Expo plugins, feel free to reach me out on Discord