[NavigatorIOS] resetTo will not change the title or rightButton

[lazywei]

I'm not sure if this is a feature or a bug.

My initial route:

return <NavigatorIOS
       style={{flex: 1}}
       initialRoute={{
               component: Login,
               title: 'Login',
       }} />;

in Login, I have such function to handle reseting route:

_handleLogin() {
     this.props.navigator.resetTo({
       component: ChatList,
       title: 'Chat List',
     });
},

However, the title seems not change even the ChatList is rendered correctly.

[a-warner]

This is happening to me as well, pretty sure it's a bug, since pushing another route afterwards and then popping does change the title correctly to the title specified in resetTo

[pwmckenna]

This seems to be a bug with any navigation that defers to replaceAtIndex, which doesn't do the locking that push/pop/etc do.

This might also have to do with the fact that the navigation containers are keyed by index, rather than some combination of the route+index. I haven't been able to change that key to something more unique without running into the locking issue mentioned above, but if the key has not changed, I wouldn't expect React to re-render the nav bar title. This also would explain why push/pop changes the title, because the container is briefly unmounted, so even though the key is reused, it must be mounted again causing a render.

[pwmckenna]

@ericvicenti thoughts? If I was on the right path I could try put a pull request together. Don't really have a sense of the scale of the issue though.

[ericvicenti]

Yeah, it sounds like you are on the right track. If this is affecting you then I would see what you can do to fix it or work around it. We don't use NavigatorIOS internally, so we can't spend much time fixing things, but we are happy to accept any fixes that people contribute.

[AdamBrodzinski]

+1 I'm having to same issue too.

[pwmckenna]

@ericvicenti do you guys just use navigator internally?

[ericvicenti]

Yep, we only use the Navigator in our apps right now. It gives us a bit more flexibility over gestures and animations, and we're using it on Android as well, which helps us share code.

We don't have the bandwidth to support components which aren't used by our internal clients, so it is up to the community to maintain NavigatorIOS. We are happy to accept your PRs!

[jaredly]

@pwmckenna the base issue is that NavigatorIOS doesn't have the logic for updating nav items in-place see source

[brentvatne]

@jaredly - seems like this is worth adding support for - I had an initial shot at this here, we could use the same strategy for other props

[mccambridge]

I seems as if replace suffers from the same issue.

[Iragne]

well i create this PR for that #1733

[AdamBrodzinski]

I've found a work around to use resetTo that resets the title. When you want to use resetTo, save a reference to the route and use replace instead.

 nextPage() {
    global.__feedRoute = {
      title: 'Feed',
      component: require('../FeedContainer')
    };
    this.props.navigator.replace(__feedRoute);
  }       

Then in the next component (Feed in this example), call resetTo which removes the back button and animates in.

  // Feed.js
  componentWillMount() {
    this.props.navigator.resetTo(__feedRoute);
  },          

The first call to replace will change the title and hopefully the right button, this also does not animate it. The next call to replaceTo will reset the stack and you should be good to go.

[hanai]

same problem with replace

[Iragne]

may be this PR can help
#2526

[matejkramny]

replace has the same issue.

What needs to happen to fix this? Any way i can help?

[cancan101]

There is this: #3516

[kevinsqi]

#3516 was replaced by #3809. Seems like @rocman has a potential fix, but is dealing with a failing CI build.

[Iragne]

I check both implementation in objective c. i think the delegate link in this pr #2526 is more code compliant.

[longsangstan]

I use <Navigator> and have similar issue.
The old rightButton still clickable (although hidden) after pushing to the new route.

[DenisIzmaylov]

Up!

[lacker]

AFAICT this issue now covers a number of different problems, of which #3809 and #2526 fixed two of them. I am going to close this issue but if there is still a problem then I encourage folks to open a new issue with a repro of the specific bug in a rnplay.org link.