Lazy initialized TabBar

[burakgormek]

Thanks for the library.
Is there are a way to lazy initialize TabBar? Currently it's loads all TabBar screens on start.

e.g: RNN & RN lazy options

[grahammendick]

Hey, I'm glad you're enjoying the Navigation router.

You can add an onChangeTab prop to the TabBar so that you can work out when a tab is loaded. Here loaded tracks what tabs have been clicked. It starts out as {0: true} and becomes {0: true, 1: true} if the user clicks on the 2nd tab.

const [tab, setTab] = useState(0);
const loaded = useRef({0: true});
<TabBar
  tab={tab}
  onChangeTab={(newTab) => {
    setTab(newTab);
    if (!loaded.current[newTab]) loaded.current[newTab] = true;
  }}
>

Then you can use loaded to decide to lazy load the content. In the Twitter sample on Android let's delay the loading of the Notification tab content until it's clicked. We pass a new loaded prop to the Notifications component. This prop gets set to true when the user clicks the notifications tab.

<TabBarItem title="Notifications">
    <Notifications loaded={loaded.current[1]} />
</TabBarItem>

Then the Notifications component can only load its content when loaded is true. Notice that I'm rendering a shell and the loaded check is conditionally loading the content (it's important that you render a real native view into the TabBarItem on Android).

const Notifications = ({ loaded }) => (
  <SafeAreaView style={{flex: 1}}>
    <CoordinatorLayout>
      {loaded && (
        <>
          <NavigationBar

If you have a NavigationStack in your TabBarItem, like the Twitter sample on iOS, then you can pass the loaded prop as shown below. Well this should work, but while I was investigating your question, I noticed a bug that means it doesn't work at the moment. But I have a fix so it will do soon.

<TabBarItem title="Notifications">
  <NavigationHandler stateNavigator={notificationsNavigator}>
    <NavigationStack>
      <Scene stateKey="notifications"><Notifications loaded={loaded.current[1]} /></Scene>
      <Scene stateKey="tweet"><Tweet /></Scene>
    </NavigationStack>
</TabBarItem>

I hope this helps but please let me know if any of it isn't clear. I'm happy to go into more detail if you want.

[grahammendick]

@burakgormek I've just released the fix for the loaded prop in the stack. Thanks for your interesting question 👍

[burakgormek]

Thanks for the quick fix and also your effort

[burakgormek]

Thanks for the detailed explanation. Currently your explanation best approach so I will mark as answered.

On the other hand, I think we should do this on native side. This library looks most performant in this navigation area. So i think it's better to keep handling lazy TabBar options on native side rather than lean on react state.

I wish I could check if it can be done in native and make a PR(not have native exp.) but don't have time these days because of our app needs to be finalize :/

Thanks again.

[grahammendick]

What do you mean by lazy? Doesn't that have to be on the React side if you don't want to render the content until the tab is clicked? Or do you mean something else?

Also, I prefer to put that kind of thing in userland than in the framework because then you can decide what you want to render. For example, you may want to render some basic content upfront and render the more complicated stuff when it's clicked. Or, with React 18 here, you could render the hidden tabs on a lower priority than the selected one.

[burakgormek]

It feels like this behaviour is related to navigation. Of course you can control things that you want to render on React side. I do this for stack navigation. It shows minimal content and waits for interaction(runAfterInteraction) to show the rest of the content when navigating.
If I want to do same for tab: hide with loaded state, and hide with runAfterInteraction state. Just more boilerplate codes and nested conditions.

Thats why I thought it will be much better to do this on framework(perf another reason). And It will makes it easer to convert from RN&RNN.

Just my opinion. I appreciate your approach&thought.

[grahammendick]

I really appreciate your thoughts on this. Thanks for taking the time to write back.

The Navigation router uses React to freeze/suspend scenes that aren't at the top of the stack. That means React skips their render phase until they're unfrozen. I did look at doing this for tabs but ran into some problems. I think React are doing work in this area - making it easier to background React subtrees - so I'll take another look when their work lands.

[burakgormek]

Oh I didn't know that navigation uses freeze. That would be awesome for tab for sure.

[grahammendick]

Hey, I don’t think lazy loading tabs works that well if it’s built into the Navigation router. In the Twitter example, if the notifications tab is lazy loaded then when first selecting it it will show blank until the notifications fetch completes. Because the tab doesn’t render it until it’s selected, the query can’t start until then.

Over the weekend, I managed to freeze the inactive tabs. This could work a bit better because the Navigation router could delay the freeze to allow for a first render to happen even on the inactive tabs. Then when switching to the notifications tab the query will have already returned. But what if the notifications tab takes more than one state update to fully render? In that case, it won’t be finished when first switching.

I think this is better left in userland because it’s the developer that knows how best to load the content of the inactive tabs. For example, the developer could startTransition from React 18 so the notifications tab renders in the background. That way it won’t delay the app launch and also it means the tab will be fully rendered when first switched to.

What do you think?

[burakgormek]

Over the weekend, I managed to freeze the inactive tabs. This could work a bit better because the Navigation router could delay the freeze to allow for a first render to happen even on the inactive tabs. Then when switching to the notifications tab the query will have already returned. But what if the notifications tab takes more than one state update to fully render? In that case, it won’t be finished when first switching.

Thanks for working on freeze branch. I've tested it now. And yep, it's complicated and hard to overcome.

Can we simplify this like navigating to stack screen? Transition starts after the content render.
Maybe we can support this? Rest of the query handling, background rendering and other stuff can be user's responsibility.

RN do this by default, not sure for RNN.

[grahammendick]

React Navigation’s approach doesn’t sound good. Let’s say it takes 500ms to fetch the notifications. With React Navigation this slow fetch won’t start until the notifications tab is selected. It probably takes the user quite a while before they switch so it’s a waste not to complete the fetch in that idle time.

Freezing but allowing an initial render is better. The initial render allows the fetch to complete. So when the user switches the tab all React Native has to do is render the notifications. But I’m still not that keen because it requires the developer to start the fetch in the very first useEffect.

I kinda think we should freeze inactive tabs but only once they’ve been selected at least once. But that’s almost the opposite of lazy so doesn't help with the first load.

[burakgormek]

Hmm...
Maybe we should introduce more options:

1. init (for prefetch data. renders nothing if not visited. container only)
2. render (current default)
3. lazy (pass the screen control to user. if they have heavy component, then they will decide either wait to render or show loading indicator)

1st one is freeze-tab branch. Also complicated one.

I kinda think we should freeze inactive tabs but only once they’ve been selected at least once. But that’s almost the opposite of lazy so doesn't help with the first load.

Why?

Btw I've tested freeze-tab branch but console.log didn't appear(Notifications.js). Did I miss something?

[grahammendick]

Hopefully we can make this behaviour so it just works and then we don’t need to introduce a prop for it at all.

That tabs-freeze branch is very much a work-in-progress. I remember trying to freeze tabs before and hitting a brick wall so I was really just checking that I could get it working on both platforms. It doesn’t currently allow a first render before freezing which is why you’re not seeing your console.log in Notifications.

So I’m going to keep working on the tabs-freeze branch to see if I can implement freezing inactive tabs while allowing a first render. Then we can try it and see how it behaves. Does that sound like a plan?

[burakgormek]

OK. Let's see how it goes 👍

[grahammendick]

Hey there @burakgormek I've got a new idea that I'd like to run past you.

I'll just give a bit of background first. The Navigation router freezes scenes (using React Suspense) that are hidden in the stack. Frozen scenes receive state updates but don't render. When the user navigates back, the Navigation router unfreezes the previous scene so it can render with its latest state.

We want to do the same thing with tabs. But tabs are different to scenes because all but one of the tabs start as inactive (scenes are always active when they first appear). We don't want to freeze inactive tabs straight away because they won't have done a single render. So when the user switches to them they'll flash blank before the first render happens.

So the Navigation router has to let tabs render before freezing them. But there's no way for the Navigation router to know when a tab has loaded (finished rendering). It might take a few render cycles for the tab to be considered loaded. In the following (pseudocode) example, it takes 2 renders for notifications to load.

const NotificationsTab = () => {
  const [notifications, setNotifications] = useState();
  useEffect(() => {
    const data = await fetch();
    setNotifications(data);
  }, [])
}

But in this example it takes 3 renders. The notifications aren't fetched until run is true which happens after the second render.

const Notifications = () => {
  const [notifications, setNotifications] = useState();
  const [run, setRun] = useState(false);
  useEffect(() => {
    setRun(true);
  }, []);
  useEffect(() => {
    if (run) {
      const data = await fetch();
      setNotifications(data);
    }
  }, [run])
}

My new idea is to let the developer tell the Navigation router when the tab has loaded! We'll create a TabBarItemContext with a loaded function. The developer calls this function when their tab has loaded. In the examples above, the developer calls loaded when notifications is populated (and after they're rendered). As soon as loaded is called, the Navigation router freezes that tab if it is inactive.

const Notifications = () => {
  const {loaded} = useContext(TabBarItemContext);
  useEffect(() => {
    if (notifications) {
      loaded();
    }
  }, [notifications]);
}

I haven't talked about lazy initialization yet. But really that's just a special case of this generic solution. For example, if the developer wants to do a 'traditional' lazy initialization then they call loaded before the notifications are fetched. That way the tab is frozen before the notifications render.

useEffect(() => {
  loaded();
  const data = await fetch();
  setNotifications(data);
}, [])

[burakgormek]

Hey, sorry for late response. I've seen that you're working on it(tab branch). Nice idea to control render.
But it can be confusing. Can we add default behavior like adding loaded func to TabItem onPress? For another simplified way.

Dev. can choose a complex&controllable way(useEffect) or a simplified way to control render.

[grahammendick]

I’ve tried a lazy prop but it does end up with a blank flash if there’s a slow render. You’re right that the Stack does wait for the render but the TabBar doesn’t. That’s because the stack-navigation trigger happens in JavaScript but the tab-change trigger happens in native.

So, I’m not going to add a lazy prop for now. I’m going to stick to the onLoad as the way to lazy load tabs. Most tabs have some kind of data fetching in them so onLoad is the way to go. If the tab doesn’t have any data fetching at all then it’s still possible to lazy load straight away with onLoad.

const [show, setShow] = useState(false); 
const {onLoad} = useContext(TabBarItemContext);
useEffect(() => {
  onLoad();
  setShow(true);
});
return !show ? <View /> : <Settings />;

I’m going to put the onLoad change into Native Web, too. I can add the lazy prop here - everything happens in JavaScript so the tab will wait for the render.

React Native's new architecture makes synchronous rendering possible. This could mean that the tab switch will wait for the render and avoid the blank flash. So I’ll revisit the lazy prop when synchronous rendering lands.

[grahammendick]

@burakgormek Ok, all done 👍 Could you give the branch a look over/test, please?

Also, are you happy with the names onLoad and TabBarItemContext?

[burakgormek]

I'm not good at naming things :)
but...

freezeOnLoad?

onLoad doesn't give a context about freezing.

[grahammendick]

I don't really want freeze to be part of the name. Freeze is too much about the implementation rather than the intent. I want the user to tell us when the tab loads and it's up to the Navigation router what it does about it.

[burakgormek]

Oh, I see. onLoad ok for me 👌

[grahammendick]

This has been fixed by #650

Thanks @burakgormek for the great discussion. I really enjoyed chewing over some ideas with you. Hopefully we can work together again on something. I’ll thank you more formally in the release notes.

In summary, the Navigation router freezes inactive tabs once they’ve been visited. To handle freezing an inactive tab that hasn’t been visited, there’s a TabBarItemContext with an onLoad function. The user calls onLoad once it’s safe to freeze. In a Twitter example, the notifications tab is frozen once the data is fetched,

const NotificationsTab = () => {
  const {onLoad} = useContext(TabBarItemContext);
  const [notifications, setNotifications] = useState();
  useEffect(() => {
    onLoad();
    const data = await fetch();
    setNotifications(data);
  }, [])
}