Propose/experiment with API for navigationOptions about hooks

[fbartho]

@ericvicenti if you pass a closure to useNavigationOptions() then you get the benefit of the dynamic navigationOptions API today + the rest of the features you described.

Also, a context-based API would be super valuable to help deep children get a reference back up to the Navigator they're contained in.

One super painful thing today is that some screens are nested deeply:

ModalNavigator➡️BottomTab➡️Stack➡️TopTab➡️Target

It would be neat if Target were capable of dynamically putting something in the top-right navigation bar position on the Stack, or dynamically telling the BottomTab to hide the tab bar.

Exposing a third parameter on the useNavigationOptions tuple could give helpers to get up the tree.

Something like:

const [options, setNavigationOptions, useParentNavigationOptions] = useNavigationOptions();
const [stackOptions, setStackNavigationOptions, /* another level up if any */] = useParentNavigationOptions();

Ideally then, we'd be able to dynamically show-hide the bottom-tab-bar, no matter how nested our subscreen is.

Thoughts?

[ericvicenti]

Yeah I think we could use suspense for something like this.

In your screen component:

const [options setNavigationOptions] = useNavigationOptions()

And in the header:

const { title } = useCurrentRouteNavigationOptions()

So if navigators were wrapped with <Suspense>, useCurrentNavigationOptions would throw a promise when the options are missing, or the current active route key does not match the key of the current options. The screen would render afterward, provide options to useProvidedNavigationOptions, resolving the suspense promise with the new options.

This doesn't actually sound that hard to implement, if you useNavigation inside of these new hooks in order to know the current navigation state from the navigator, and to know the current route key from the screen.

[satya164]

I think conceptually an API like this will be great:

useNavigationOptions({
  title: 'My app'
});

But wondering how would it work technically. What would do under the hood? Call a method on context which updates the navigator's state (like I was thinking with navigation.setOptions)? Double rendering will still be an issue with this, no?

I was thinking if suspense will be useful with this where we could pause rendering new content until the options are set. But since I haven't used suspense yet, I don't have much idea of how feasible it will be.

[satya164]

We're not planning to add it to React Navigation 4. In React Navigation 5, you can do navigation.setOptions:

function SelectionScreen({ navigation }) {
  const [selectCount, setSelectCount] = React.useState(0);

  navigation.setOptions({
    title: selectCount > 0 : `${selectCount} items selected` : 'Select some items',
  });

  return <SelectionList onSelectCountChange={setSelectCount} />;
}

[ecSpl01t]

@slorber,
Will you have time to provide this useNavigationOptions hook?
Or I missed documentation about it, should I still have to use an old type
"MyComponent.navigationOptions = () =>" ?

[deepakkumardk]

@satya164 How to do the same in Typescript?
Getting error Property 'setOptions' does not exist on type 'StackScreenProps<MainStackParams, "MainScreen">'