memoization issues with 3rd party libraries (incl. React Navigation)

[chankruze]

Before posting this isuue, I already read the #97 and https://github.com/jaredh159/tailwind-react-native-classnames#taking-control-of-dark-mode thoroughly. From there I understand that, the theme change won't re-render components using memo.

My question is, how can we useAppColorScheme() with React Navigation and get this to work ?

I've created a minimal repo and also recorded the screen for the demo purpose.

Repo Link
Video Demo

[jaredh159]

Thanks for the time you took making the repo and the video.

I don't have an answer for you at this point. I've not used React Navigation with twrnc, so I've not encountered this issue personally. I just looked for a few minutes through the code of react navigation, and they do use React.useMemo pretty extensively, although it's not easy for me to see if they are memoizing core components, or other values.

I think the way to really figure this out would be to try determine for sure that React Navigation is memoizing a key point in your component heirarchy, and exactly where. I might try this by putting some console.log('rendering SomeComponent') in the render functions of some components until i can figure out where it stops rendering.

If you can isolate where the renders get blocked by use-memo, the next thing I would do is see if that component accepts some prop that I could change when the app color scheme changes, thus forcing it to re-render. You might even be able to pass the component some arbitrary key prop, forcing a rerender.

I'm busy working on other things right now, so I'm not going to do a really in-depth troubleshooting of your case at this point, but I would hope that you might be able to try the technique I described above, and possibly find a solution. If you do, it would be great if you could share it in this issue for others. If some sort of pattern emerges, then maybe we could incorporate it into the library itself.

If you get totally stuck and are not able to find a workaround, let me know, I might be able to set aside some time before too long to take a shot at it myself as well.

[chankruze]

@jaredh159 Sure!
I got all your points. I'll try the key prop way, cause this seems cleaner to me and I've used this way in a game I developed. Thank you for your replay by the way.

Meanwhile, I will use shopify restyle for theming purpose. But I believe this is a good issue. I'll try my best to help you with this.

Thanks ;)

[Jackmekiss]

@chankruze Hi, how did you resolve this issue at the end ?

[chankruze]

@chankruze Hi, how did you resolve this issue at the end ?

I am using shopify restyle for theming purpose for now. It also helps in consistent ui.

[tmlamb]

I've noticed a similar issue with React Navigation when using withDeviceColorScheme: true on iOS.

When the device theme changes between dark/light, navigating to a new page in the app successfully reflects the new theme except when navigating to the first screen in the stack (i.e. the "home page"). I believe it may be because I only navigate to that screen using React Navigation's goBack, which does not re-render the screen unless there has been a state change.

A workaround I'm using is to force the home page screen to always re-render with React Navigation's useFocusEffect and a changing key prop on the component, although I could see this being detrimental if the component is expensive to render. Anyone have any suggestions on better way? I tweaked the repo provided by @chankruze to use the device theme and with my solution to demonstrate:

https://github.com/tmlamb/rn-twrnc-exp/commit/c14280d6f01a89b0b8bcb77483eceb47dcd897bb

[JamesHemery]

The problem is present with all the memoized components, having a hook/HOC for all these components is not a technically good solution, I will try to find a solution for my application and make a PR if ever.

Update: Adding a key props on the React Navigation Navigator component with the current breakpoint as value works perfectly.

import { config } from '@ui/tailwind';

function useBreakpoint() {
  const { width } = useDeviceDimensions();

  const breakpoints = Object.keys(config.theme.screens).reverse();
  const breakpointIndex = Object.values(config.theme.screens)
    .map((breakpoint) => parseInt(breakpoint.replace('px', ''), 10))
    .sort()
    .reverse()
    .findIndex((breakpoint) => width >= breakpoint);

  return breakpoints[breakpointIndex];
}

export function GuestStack() {
  const breakpoint = useBreakpoint();

  return (
      <Navigator
        key={breakpoint}
        initialRouteName={...}
      >
         {/* Screens... */}
      </Navigator>
  );
}

[tmlamb]

I'd like to share an improved approach I've found to handling system theme changes when using this library with React Navigation. The solution I described in my last comment was to naively re-render to root screen of the app whenever the user navigated to it via the useFocusEffect:

import React from 'react'
import { useFocusEffect } from '@react-navigation/native'
import { View } from "react-native";

export default function HomeScreen() {
  const [forceRenderKey, setForceRenderKey] = React.useState(0)
  useFocusEffect(
    React.useCallback(() => {
      setForceRenderKey(v => v + 1)
    }, [])
  )

  return (
    <View key={forceRenderKey}>
        // Home screen content...
    </View>
  )
}

This worked fine with a home/root screen that was fairly static and didn't rely on any async behavior to render. In a new app I'm working on, the home screen requires a network request to render content, so the above approach results in the network request being sent whenever the user navigates away then back to the home screen, and the visual delay that entails (not ideal at all). The improvement I found is to have the home screen keep a reference to the system theme, and compare to the current theme onFocusEffect and when the app switches from background to foreground, so that the key that forces rerender only increments when needed:

import React from 'react'
import { useFocusEffect } from '@react-navigation/native'
import { Appearance, AppState, View } from "react-native";


export default function HomeScreen() {
  const [forceRenderKey, setForceRenderKey] = React.useState(0)
  const colorScheme = React.useRef(Appearance.getColorScheme());

  const handleColorSchemeChange = () => {
    const systemColorScheme = Appearance.getColorScheme();
    if (colorScheme.current !== systemColorScheme) {
      setForceRenderKey((v: number) => v + 1);
      colorScheme.current = systemColorScheme;
    }
  };

  useFocusEffect(
    React.useCallback(handleColorSchemeChange, [])
  )

  const appState = React.useRef(AppState.currentState);
  useEffect(() => {
    const listener = AppState.addEventListener("change", (nextAppState) => {
      if (
        appState.current.match(/inactive|background/) &&
        nextAppState === "active"
      ) {
        handleColorSchemeChange();
      }
      appState.current = nextAppState;
    });
    return () => {
      listener.remove();
    };
  }, []);

  return (
    <View key={forceRenderKey}>
        // Home screen content...
    </View>
  )
}

There may be more to consider if you give users the ability to toggle your app's theme separately from the system theme, but I think that could be handled with a little additional state/logic.

It's also worth considering moving the foreground event listener to a HOC that can be reused on every screen in an app, since switching from background to foreground seems to cause visual issues in the React Navigation header even on pages that are not at the root of the React Navigation stack.

[jaredh159]

@tmlamb that's really helpful, thanks for taking the time to make the detailed writeup with code samples, i appreciate it.

[Nova41]

I found a much easier solution, but I am not sure if it's case-specific. Simply add a useColorScheme() hook call to the component that does not update w.r.t device's color scheme. This will trigger a rerender on the component every time the system color scheme changes.

Example:

export const RootStackNavigation = () => {
  return (
    <Stack.Navigator>
      <Stack.Screen name="HomeScreen" component={HomeScreen} />
    </Stack.Navigator>
  );
};

export const HomeScreen = () => {
  useColorScheme(); // <-- add this

  return (
    <View style={tw`bg-white dark:bg-black`} />
  );
}

[jeromecovington]

I was able to solve this using the docs: Enabling Device-Context Prefixes

[tmlamb]

I found a much easier solution, but I am not sure if it's case-specific. Simply add a useColorScheme() hook call to the component that does not update w.r.t device's color scheme. This will trigger a rerender on the component every time the system color scheme changes.

@Nova41 With this approach are you able to see a React Navigation Header component with a theme-dependent background also switch to the new color at the same time as the screen View? I tried in my own app and I'm having trouble getting the header to re-render along with the screen view.

[Nova41]

I found a much easier solution, but I am not sure if it's case-specific. Simply add a useColorScheme() hook call to the component that does not update w.r.t device's color scheme. This will trigger a rerender on the component every time the system color scheme changes.

@Nova41 With this approach are you able to see a React Navigation Header component with a theme-dependent background also switch to the new color at the same time as the screen View? I tried in my own app and I'm having trouble getting the header to re-render along with the screen view.

I am using a custom header rendered within the component so it wasn't really an issue for me. Regarding your case, I think the header from the navigation library would not be rerendered, as it is not handled by the component and thus the state update of the component triggered by the hook does not trigger a rerender on the header. Perhaps you can try manually triggering a rerender of the header from the component by using the ref to the navigation (useNavigation) to set the header title to the same one?