[Android] Discussion: Support for Jetpack Compose

[thevoiceless]

Status as of April 2024

You should be able to use Compose with React Native, but it does not play nice with react-native-screens

---

The update to Gradle 7+ in RN 0.66+ means that we can now use Jetpack Compose to build React-like declarative UIs natively on Android. It's completely separate from the traditional View system but there are interoperability APIs to bridge the two worlds.

Thanks to AbstractComposeView, I was able to implement a basic proof-of-concept (edited for brevity):

class MyViewManager : SimpleViewManager<MyView>() {
    override fun createViewInstance(reactContext: ThemedReactContext) = MyView(reactContext)

    @ReactProp(name = "displayText")
    fun displayText(view: MyView, displayText: String) {
        view.displayText = displayText
    }
}

class MyView @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
) : AbstractComposeView(context, attrs) {
    var displayText by mutableStateOf("")

    @Composable
    override fun Content() {
        Text(displayText)
    }
}

However!

Release builds crash with an IllegalStateException: ViewTreeLifecycleOwner not found ... when trying to display the Compose UI content. I haven't been able to nail down the exact reason why this only occurs in release builds, but I was able to figure out two workarounds:

1. Update androidx.appcompat:appcompat to version 1.3.1+, discovered via this StackOverflow post and a few others; unfortunately this involved forking RN since it still uses version 1.0.2 which is from 2018 (!!!). Compose depends on some lifecycle and saved-state logic in androidx.activity.ComponentActivity, whereas ReactActivity currently ends up extending from the same-name-but-different-package androidx.core.app.ComponentActivity.

2. Manually shim the missing logic using ViewTreeLifecycleOwner and ViewTreeSavedStateRegistryOwner; thankfully ReactActivity already implements LifecycleOwner via the older androidx.core.app.ComponentActivity, but you do need to add androidx.savedstate:savedstate-ktx version 1.1.0+ to your dependencies:

abstract class MyReactActivityDelegate(
    activity: ReactActivity,
    mainComponentName: String?,
) : ReactActivityDelegate(activity, mainComponentName) {

    private val shim = SavedStateRegistryOwnerShim(activity)

    @CallSuper
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        shim.onCreate(savedInstanceState)
    }

    private class SavedStateRegistryOwnerShim(
        private val activity: AppCompatActivity,
    ) : LifecycleOwner by activity, SavedStateRegistryOwner {

        private val controller = SavedStateRegistryController.create(this)
        override fun getSavedStateRegistry() = controller.savedStateRegistry

        fun onCreate(savedState: Bundle?) {
            activity.window.decorView.rootView.let { root ->
                ViewTreeLifecycleOwner.set(root, this)
                ViewTreeSavedStateRegistryOwner.set(root, this)
            }
            controller.performRestore(savedState)
        }
    }
}

class MyActivity : ReactActivity() {
    override fun createReactActivityDelegate() {
        return object : MyReactActivityDelegate(this, mainComponentName) { ... }
    }
}

As far as I can tell, both approaches prevent the crash and Compose seems to function as expected. However:

• Option 1 involves forking RN and I'm not sure how the change may affect RN overall. I also assume that Compose will eventually require newer and newer AndroidX dependencies, so it would be nice to have them "officially" updated.

• Option 2 is a kludge that may need to be periodically updated to match the AndroidX implementation, and I have no idea if it even fully implements all of the plumbing that Compose expects under the hood.

So, any chance we could get androidx.appcompat:appcompat updated to at least 1.3.1?

Or better yet, some kind of official support for Compose? Perhaps a SimpleComposeViewManager that directly accepts @Composable content?

[cortinico]

Thanks for opening this discussion @thevoiceless

I'd like to loop in @ShikaSD and @mdvacca as they have relevant context on RN <=> Compose.

I think that we would like to add a sample components inside RN-Tester that uses a Composable to render. Potentially also adding a Guide to the website would be beneficial so that others could follow your approach.

As for the specific problem you point out:

Update androidx.appcompat:appcompat to version 1.3.1+

This seems like the way to go. You don't need to fork react-native, as specifying a dependency on androidx.appcompat:appcompat:1.3.+ inside your app build.gradle will force Gradle to pickup that dependency instead of the one provided by RN (1.0.2).

Specifically there was a crash reported that prevented the adoption of AppCompat 1.4.x, which was addressed a couple of months ago so you should be fine using AppCompat till 1.4.x.

That being said, it's actually a good call to update the version of AppCompat used by ReactNative to a newer one. I saw that some work was already done here: facebook/react-native#31620 so let's try to land that or a similar PR - cc @dulmandakh if you have bandwidth or if anyone else wants to pick this up, I'll be happy to review it.

[thevoiceless]

Sounds good! I'm happy to help/contribute any way I can.

You don't need to fork react-native

Ah, looks like you're right; I'm using appcompat-resources in the project where I noticed the issue, not the full appcompat - my bad 😅

Thanks for looking into the appcompat issue!

[ShikaSD]

Hey, really happy to see someone trying Compose with React Native! Me and @mdvacca did a few related experiments in October last year, and it should be totally possible to use it with the legacy renderer the way you described, I think.

We were investigating Compose support with Fabric renderer, at the same time, and some of the required functionality is not really supported from Compose side (e.g. measure in background). I hacked around it for the sake of experiment, but not sure it can be considered "production-ready" yet with Fabric.

For now, we don't plan any official support for Compose (because of performance and feature related concerns), but will keep an eye on new developments/community feedback.

I also would love to hear about your experience if you manage to use a Compose-based view in your project :)

[thevoiceless]

@ShikaSD I seem to recall seeing Fabric-related stuff in the stacktraces while investigating the appcompat issue; am I imagining things, or is it already enabled on Android?

[cortinico]

or is it already enabled on Android?

It shouldn't be enabled by default, unless you specifically did it. Instructions on how to enable it are here: facebook/react-native-website#2879

[thevoiceless]

Ah I definitely haven't done any of that, but might take a stab at it. Thanks!

[ShikaSD]

You might see Fabric related things in the stack traces even on legacy renderer because we adapted most of the Android native components from legacy renderer to work with both :)

[thevoiceless]

For now, we don't plan any official support for Compose

@ShikaSD can you elaborate on this? Should I avoid investing any effort in using Compose if Fabric won't support it? Compose seems to be the future of UI on android, but Fabric seems to the future of UI in RN...

[ShikaSD]

Should I avoid investing any effort in using Compose

I think not, frankly the opposite :) My comment had more cautionary intention in case you are adopting Fabric right now. Compose support is just not ideal at the moment and it is going to be rough around the edges for some time :)

[thevoiceless]

I think not, frankly the opposite

Awesome, I was hoping you'd say that! I'm working on proving out using Compose in various parts of my current project, so I'll keep you all posted with anything else that I find.

On that note: It seems to "just work" in DialogFragments with the updated appcompat as well 🙂

[thevoiceless]

I believe I've found another issue:

I'm not 100% sure if this is the scenario to reproduce, but I have a component like

const Foo = () => {
  const [loading, setLoading] = React.useState(true)

  if (loading) {
    return (
      <View><ActivityIndicator /></View>
    )
  }

  return (
    <View><MyView /></View>
  )
}

where MyView is implemented as shown in my original post (i.e. SimpleViewManager returning an AbstractComposeView). However, when switching from the "loading" UI to the "loaded" UI, it appears that NativeViewHierarchyManager.updateLayout() is invoking

viewToUpdate.measure(
  View.MeasureSpec.makeMeasureSpec(width, View.MeasureSpec.EXACTLY),
  View.MeasureSpec.makeMeasureSpec(height, View.MeasureSpec.EXACTLY));

before viewToUpdate (in this case, my MyView) is attached to the window. This crashes with

java.lang.IllegalStateException: Cannot locate windowRecomposer; View ... is not attached to a window

because AbstractComposeView.onMeasure() calls ensureCompositionCreated() which calls resolveParentCompositionContext(). Unfortunately its onMeasure() is final so I can't simply add a check to no-op if not attached; the only workaround I've found is to extract some of the logic from View.createLifecycleAwareViewTreeRecomposer(): Recomposer declared in androidx.compose.ui.platform.WindowRecomposer.android.kt:

class MyView @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
) : AbstractComposeView(context, attrs) {

    init {
        val currentThreadContext = AndroidUiDispatcher.CurrentThread
        val pausableClock = currentThreadContext[MonotonicFrameClock]?.let {
            PausableMonotonicFrameClock(it).apply { pause() }
        }
        val contextWithClock = currentThreadContext + (pausableClock ?: EmptyCoroutineContext)
        val recomposer = Recomposer(contextWithClock)
        setParentCompositionContext(recomposer)
    }

    override fun onAttachedToWindow() {
        setParentCompositionContext(null)
        super.onAttachedToWindow()
    }

    @Composable
    override fun Content() {
        // ...
    }
}

which ensures that some kind of parent composition context exists.....but I'm not exactly confident that this is "correct" 😅

[ShikaSD]

Yep, that's the issue we encountered with Fabric as well. I had to commit a few reflection crimes to get around that limitation, but maybe it is possible to just not measure the view until it is attached?

I don't remember the details on how legacy renderer works here, but maybe you could measure the view to the size of the parent (or just 0) and then resize when it is attached.

[ShikaSD]

If the only problem is the absense of composition context, it should be possible to extract it from parent view/activity context, and the set it similarly to the way you worked around this limitation (without resetting the composition context).

Compose attaches the recomposer to the view tag of android.R.id.content, IIRC, so if you can get hold on the activity, you can:

class MyView @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
) : AbstractComposeView(context, attrs) {

    init {
        val activity = getActivity(context) // you probably want to unwrap it in case it is ContextWrapper
        val compositionContext = activity.findViewById(android.R.id.content)!!.compositionContext
        setParentCompositionContext(compositionContext)
    }

    override fun onAttachedToWindow() {
        // I don't think there's any need to re-attach here, as recomposer is created once per window.
        super.onAttachedToWindow()
    }

    @Composable
    override fun Content() {
        // ...
    }
}

This should work, albeit still very hacky :)

[ShikaSD]

Exported our internal proof of concept from October last year: facebook/react-native#32871
It tries to change a <Switch /> component to use Compose, supporting a subset of original props and events. All of it with Fabric only though, but seems like there are less issues with legacy renderer so far :)

cc @mdvacca

[thevoiceless]

maybe it is possible to just not measure the view until it is attached

Unless I'm missing something, it looks like AbstractComposeView specifically forbids that by marking onMeasure() as final - it does expose an open fun internalOnMeasure() but that's not called until after ensureCompositionCreated(). It seems that any measurement workaround might have to be on the RN side of things - perhaps some kind of marker interface for special behavior? Just spitballing here...

sealed interface SpecialBehavior {
  interface MeasureOnlyWhenAttached : SpecialBehavior
  // ...
}

and then NativeViewHierarchyManager.updateLayout() would check if (view !is SpecialBehavior.MeasureOnlyWhenAttached)?

This should work, albeit still very hacky

Still looks better than my approach - I'll give it a shot!

Exported our internal proof of concept

Awesome, I'll take a look, thanks!