Road to v1 stable
ericvicenti opened this issue · 34 comments
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 #135
- Go back to a screen: #1213
- Header bar overriding #1220
- Screen lifecycle hooks #51
- Simplified Nav Options #722
- Resetting non-deepest navigator #691
- Explore
<NavigationOptions />for a less confusing configuration method - Fix issues with drawer navigator - #374
After v1:
- Accessibility Review #58
Lets aim to reach stability by mid-April!
any chance to get this #691 in v1 ..
@chandu0101, yep, just added it! I'm still searching around for high-pri issues
@ericvicenti is #175 a high priority for v1?
@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')
@nihgwu, I believe #135, which @ericvicenti included in the list above, would solve that problem.
@migueloller sorry I didn't notice that before
@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.
A better way to configure screen transitions is needed for react-navigation to be competitive with other solution.
+1 for #175
Perhaps #802 (Ability to "replace" screens in the stack navigator) should be on this list?
@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?
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!
@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?
From my perspective, #88 would be great. I could work on it we can make it into next release candidate.
@ericvicenti Thanks for the response. Just to clarify are you suggesting to have a HOC "watch" and compare navigation.state changes rather than have a triggered event at the component level?
Looking good! We switched to react-navigation from react-native-router-flux in our company's first React Native app. Really looking forward to a stable version of react-navigation. As a first version I think it contains enough features. And with those mentioned in this issue, it will be a great alternative for other routers.
Keep up the good work! ⭐️
@ericvicenti I feel like something like #525 / #486 / #314 (Allow TabBarBottom accept onTabPress callback) is pretty crucial. A large number of production apps which use bottom tabs have some custom action when the currently active tab is pressed again (e.g. reset the stack, scroll to top, etc). Feels like quite a limitation that this isn't supported.
Animated replace is an important issue for us. #351
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)
Almost 2 months in past the mid-April v1 estimate. Any status updates?
Expecting release a new beta version for all the issues are fixed in master.
I opened several PRs. Is anyone checking this stuff?
- idempotent pushes #2334
queued action dispatch andfixed queued transitions in Transitioner #2400 (due to redux integration I updated this one in favor of #1313). Basically both are needed.- some fixes to the Drawer menu #2294 (this one might not be needed if #2183 will be merged)
- fix reset action in stack navigator #2292
@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!