Road to v1 stable

[ericvicenti]

For the first release, lets focus on API sanity and stability, rather than adding every feature that people have requested.

• Navigate key for idempotent pushes Add optional key to navigate action, allowing idempotent pushes #135
• Go back to a screen: How do I go back "to" an arbitrary route from another? #1213
• Header bar overriding Make header configurable #1220
• Screen lifecycle hooks screenIsActive prop / componentDidFocus event for TabNavigator items #51
• Simplified Nav Options RFC: Simplified Navigation Options #722
• Resetting non-deepest navigator Specify reset key to define what state should be reset #691
• Explore <NavigationOptions /> for a less confusing configuration method
• Fix issues with drawer navigator - Drawer causes header title to disappear, possibly has wrong font #374

After v1:

• Accessibility Review Accessibility Review #58

Lets aim to reach stability by mid-April!

[chandu0101]

any chance to get this #691 in v1 ..

[ericvicenti]

@chandu0101, yep, just added it! I'm still searching around for high-pri issues

[migueloller]

@ericvicenti is #175 a high priority for v1?

[jakecraige]

I'd second #175 / #124 being part of 1.0. There's a large amount of ceremony around having an individual screen within a StackNavigator present from the bottom up that seems like a fairly core feature that many would find useful.

[nihgwu]

@ericvicenti what about #271 debounce action reduce
and as I've said in #271, we shouldn't override custom key, or we can't find specific screen via key as it could be override, per #691 and NavigationActions.back('key')

[migueloller]

@nihgwu, I believe #135, which @ericvicenti included in the list above, would solve that problem.

[cychiuae]

I believe #527 is important too

[nihgwu]

@migueloller sorry I didn't notice that before

[nihgwu]

@cychiuae but #527 has been resolved, forget to close it though

[cychiuae]

@nihgwu someone said he still got the issue with master

[TomAtterton]

@ericvicenti I've noticed you still haven't added #175 / #124 / #690 / #232 The issue of controlling transitions of individual screens seems to be a high priority issue.

[getnashty]

+1 the need for #175.

[nehvaleem]

+1 need for #175

[nascode]

A better way to configure screen transitions is needed for react-navigation to be competitive with other solution.

+1 for #175

[aranda-adapptor]

Perhaps #802 (Ability to "replace" screens in the stack navigator) should be on this list?

[ragnorc]

+1 for #175 / #707 / #770

[lashae]

@ericvicenti :
...
Lets aim to reach stability by mid-April!

We are just one week away from mid-April and it seems that all of the referenced issues are still open. I guess mid-April deadline is not realistic so far.

Is there any new ETA for the stable version?

[ericvicenti]

The most important thing right now is for us to focus on stability so that people's apps are production-ready.

I think #124 and #175 are important for the long-term success of the library, but these are invasive and risky changes. We are trying to stabilize the library, and these features would require us to rip it up. If you're interested in highly-customized animations, you can of course use Transitioner directly, or you can find a third-party library that takes a navigation prop.

For those interested in an easy way to configure some screens as a modal and others as a card (#707 #770 #690 #232), you may find this workaround handy. I think it would break a lot of things if we tried to implement it differently. If anybody has ideas for a different implementation, feel free to open up a new issue and we can discuss. Maybe there is an easier way that I'm not seeing.

Replace functionality (#802) is also a pretty common request, and I think we could accomplish it by adding a key to the navigation action- you'd just pass the current key in order to replace. It seems that #271 would also get solved by #135.

@lashae, I won't make any more promises on timeline, but if you have any important fixes for your app, ping me and I'll help you merge them!

[charlle]

@ericvicenti The screen life cycle events proposed in #51 are necessary to manage Scene updates on Back, to close and open web sockets / event listeners. Are there proposed work arounds?

[ericvicenti]

@charlle, at the moment you can use controlled navigators, (see the redux example). When you explicitly provide the navigation.state, you can see when it changes and do things at that time. But I agree that #51 is very high-pri

[grabbou]

From my perspective, #88 would be great. I could work on it we can make it into next release candidate.

[DaleLJefferson]

Animated replace is an important issue for us. #351

[grabbou]

We are quite settled on the initial list of features to support in v1 release. If you'd like to suggest more improvements, feel free to visit #1263 where we are discussing things to go into second stable release (namely v2)

[boliveira]

I think #706 should be in the list for v1.

[MovingGifts]

Almost 2 months in past the mid-April v1 estimate. Any status updates?

[luco]

+1 for #707 . I think adding a mode for each scene it's a must.

[timwangdev]

Expecting release a new beta version for all the issues are fixed in master.

[rpopovici]

I opened several PRs. Is anyone checking this stuff?

• idempotent pushes idempotent pushes #2334
• queued action dispatch and fixed queued transitions in Transitioner queued transitions #2400 (due to redux integration I updated this one in favor of Make sure dispatch can be called multiple times per-tick #1313). Basically both are needed.
• some fixes to the Drawer menu Fix drawer side menu contentOptions props load order #2294 (this one might not be needed if Factor out DrawerItem for easy "account picker" demo #2183 will be merged)
• fix reset action in stack navigator Ignore reset action in stack navigator if reset key does not match current navigator #2292

[spencercarli]

@rpopovici working on it - project went quiet for a while but we're playing catch up and trying to get things sorted out. Appreciate all the PRs you've opened - we'll get to them!

[dantman]

@rabrenio Could you add a feature request for that instead of just a comment in the v1 issue.

[kelset]

Closing this issue in favour of #2585.