Renewed Path to React Navigation V1.0

[matthamil]

A (Renewed) Path to React Navigation V1

Blog post about the new roadmap. The blog post introduces the many awesome community members who have stepped up to revitalize this project.

Below lists the updated roadmap to 1.0 for react-navigation. The roadmap has been updated to include issues that received positive feedback from the community. For reference, the old roadmap can be found here.

---

Renewed Roadmap to 1.0

• Updated and improved documentation website
• Add ex-navigation style StackNavigator actions New StackRouter Push Action #3401 StackRouter PopToTop Action #3403 StackRouter PopN Action #3404
• Improve Reset NavigationAction proposal/fix: StackNavigator RESET action replaces with no animation unless action.direction = 'back' | 'forward' is supplied #1663
• Navigate key for idempotent pushes Add optional key to navigate action, allowing idempotent pushes #135
  • Proposals Make sure dispatch can be called multiple times per-tick #1313, queued transitions #2400, Fix idempotent pushes during transition. #2578
• Resolve go back issues: goBack issues #2454
• Screen lifecycle hooks screenIsActive prop / componentDidFocus event for TabNavigator items #51
• Fix issues with drawer navigator - Drawer causes header title to disappear, possibly has wrong font #374
• Allow multiple Drawers creating two sidemenu or drawers navigator #780

Resolved issues from original roadmap:

• Header bar overriding Make header configurable #1220
• Resetting non-deepest navigator Specify reset key to define what state should be reset #691
• Simplified Nav Options RFC: Simplified Navigation Options #722

Look at this later

• Fix inter-navigator issues Integration between different navigators #88
• Add customizable per-screen transitions Support customizable, complex transitions that animate individual views on a screen #175, StackNavigator: Allow configurable, different transition animations between screens #124, Modal StackView nested inside other StackNavigator is not presented modally #690, mode prop for Screen #232, Choose transition mode for each screen in StackNavigator #707, make a specific screen a modal? #770

---

How can you help?

We need your help to reach 1.0. For the time being, we will be prioritizing PRs that help the community reach 1.0.

There are many ways to contribute without writing a PR:

1. When opening a new Issue, fill out the Issue Template. This helps maintainers and the community at large to resolve your issue quickly.
2. Close issues that are now resolved.
3. Answer questions in the Issues.
4. Ask questions on StackOverflow and in the Reactiflux community Discord (and answer questions there too :)).
5. Review PRs by asking questions about changes made to stimulate conversation.

Ultimately, the path to 1.0 will take time. We hope to quickly bring the library up to speed again.

[plasticine]

@matthamil fantastic — thanks for the update, and looking forward to the post.

Feel free to take this as a comment, but I’d really like to see (and would be interested in contributing) a more robust, integration level set of tests to this library. Examples are good, but are not the right tool to prove functionality and prevent regressions—especially as the collaborators attempt to tackle the above roadmap...

I would strongly urge you to tackle this as a matter of priority as it will make the project as a whole more accessible and reliable.

❤️

[allmaxgit]

Tabs connected to Redux on android very slow. Please add it fix in Roadmap.

[matthamil]

Do you have an open issue for this problem @allmaxgit?

[allmaxgit]

@matthamil #739

[younanjo]

@matthamil any chance this guy can be looked into as part of the roadmap? #1493

[matthamil]

Although not a roadmap issue, this is something I'd like to see addressed as well @younanjo. There's an open PR for it that needs review #2520. Always open to other solutions that the community comes up with.

[koenpunt]

Dynamic routes and/or options for TabNavigator (and other navigators) would be nice; currently I have to jump through all kinds of hoops to get this working.

Because for example, there are ways to show less tabs than there are screens, by using a custom tabBarComponent. But then the screen still exists, which means you can still swipe to the "invisible" tab. I worked around that by actually reimplementing the TabNavigator (copy/paste), and overriding swipeEnabled with true when not all tabs should be accessible, but this obviously is not desirable.

[ferrannp]

What do you think about improving Android transitions? They are totally off right now comparing to native. See #726.

[Ashoat]

I would love if we could actually fix Flow types for react-navigation. I will do this if somebody promises to actually review my PR.

The issue is that a stock React Native app with Flow enabled will have dozens of Flow errors once you install and require react-navigation. More details here, but this has been the case for months. I have tried addressing it before, but nobody has actually reviewed my PRs.

I really think 1.0 should be able to install on a stock React Native app without any Flow errors.

[sospedra]

From reviewing our code looking for our hacky solutions. I make this list with the workarounds we believe shall be covered by the lib:

• Are we taking reset as part of the goBack issue? If not, I think it's very important and requested Flicker during navigation reset #639 Reset stack from other stack inside tab #2291
• Prevent navigating twice to the same rotue + params Add optional key to navigate action, allowing idempotent pushes #135 Don't render twice when goBack and re navigate on same screen #2331 Screen mount twice when go back and quickly re navigate to same screen  #2396
• Connect component's props with navigationOptions (avoid hacky and unresponsive setParams on any React lifecycle hook)
• Navigate to any nested navigator shouldn't be a problem (Not finding the routeName)
• Instead of break the app when a route isn't found allow a 404/Miss
• Android performance StackNavigator has performance issues and renders too many screens #706 Stacknavigator transition extremely slow #608 Android native transition between screens #726
• Reset parent navigationOptions when goBack There is no way to reset a parent's navigationOptions when navigating back in the StackNavigator #2309

And my personal advice:

• Heavily improve test suite and CI

About the roadmap to v1. IMHO, I feel like it's too ambitious. The current state of the issue's list is very prone to fail cause overwhelm. Can we think about break it into smaller milestones?

[sospedra]

See this comment for a sum up of another suggestions thread #2031 (comment) (note these are more general/abstract)

Copy of the list here

• More robustness and stability overall. This lib, as a core lib for 99% of apps, should be a plug-and-play. Without tweaking almost nothing to get a native experience.
• Be less opinionated and follow more general accepted Javascript design patterns
• Have more, isolated and clear examples. Specially for the most common cases: drawer, tab navigation, redux integration, deeplink and nesting navigators.
• Have more use cases examples: flush routes, reset nested navigators, navigate without animation, goBack multiple routes, etc.
• Make easier for community devs to help. Better code structur and quality. Simplify logics.
• Related with the previous one: make it easier to extend. A lot of issues are opened because the specific use case of the developer cannot be done without core changes.
• Allow to each scene to define its own animation
• Improve docs: which components are exposed, which props can be override, add best practices, add some receipes of common use cases (drawer + tabs), share Header with multiple navigators, add a clear API, etc
• Combine props with navigationOptions to avoid hacky and unresponsive setParams to change Navigator configuration like the title
• Define and be consistent with the design patterns. Favour either stateless or classes components. Favour composition or FP. And so on
• Performance issues. Specially with previous screens and Android
• Fix the goBack battery of problems
• Include a lifecycle system
• Component never unmount; which is weird. If we need this for animations at least make a clear statement that this is happening since a lot of logics are placed in React lifecycle's hooks.
• No replace action; neither popAndReplace
• Animations are fixed to indexes, hence making very difficult to create dynamic routers
• Android animations are very far from the natives ones
• Testing suite and CI are broken. And very much missing.

[hysan]

@matthamil Could you fix the Reactiflux link? It's broken.

[matthamil]

@hysan Done, thanks for catching that.

[jacksontbryan]

I would second @sospedra 's list. In particular reset and navigate do not work well with nested navigators. Example #1715

[necolas]

What are your plans for web support?

[rpopovici]

@matthamil #1313 and #2400 are not exactly related to idempotent pushes. These two are much more severe bugs than that :)
They are both related to the fact that dispatch it's exposing a sync interface but internally it's using setState(async) without waiting for completion, which eventually is messing up your state. #2400 is treating a similar problem in Transitioner where props and previous props are not being correctly preserved during transitions.

I opened #2334 for idempotent pushes which, IMO, it's a better solution than #2578 because it's not a time based solution and allows an optional key to be passed in case you want to push the same screen. It also fixes some of the GO BACK issues

[dantman]

• Set default params? #441 We have a whole ugly hack explicitly coded in out app just to work around not being able to have drawer routes of the same screen with different params
• Improvement: navigation.state.params should be empty object instead of undefined #2046 leads to code in our app being messier as we have to guard against params being undefined
• There is no way to wait for the transitioner to finish so we can't lock buttons and other interactable components while that is happening
• The Stacknavigator transition extremely slow #608 performance bug means that our item selection is cripplingly slow

I'd like to help fix these issues, though that is just pending our client giving the ok to work on them and react-navigation's maintainers not bothering to finish reviewing my PR(s).

[matthamil]

@dantman see #2476 (comment). With this new team of awesome people, we should be able to get to your PRs in a reasonable amount of time :). Thank you for your contributions

[dantman]

Ok. @matthamil you reviewed #1313 and I made the changes you requested, it's been unreviewed since then. Could you or someone else re-review it?

[lucianomlima]

@matthamil Will roadmap fixes be released as they are completed (beta-13, beta-14, beta-15...) or will we have to wait for a full v1 release?

[Andreyco]

Would like to ask same question as @necolas did.
How much attention would you like to pay to web? Is it one of core functionalities? Is it worthy?

In my opinion, navigation on web and mobile differs so greatly, it's not even possible to reuse navigation logic. Mobile apps does not share layouts with web apps - web apps often do more work on single screen than mobile counterparts.

While navigation library could support both environments, the question is whether it should.
Do you still consider it priority? Would stepping down from supporting web make things easier? Focus on one thing and one thing only, maybe.

Edit: how about declarative config? #2546

[MoOx]

In my opinion, navigation on web and mobile differs so greatly, it's not even possible to reuse navigation logic. Mobile apps does not share layouts with web apps - web apps often do more work on single screen than mobile counterparts.

Depends on "desktop" or "mobile web" (eg: twitter like)...

[Andreyco]

Fair point here, but I still think web based twitter does more job per screen than on mobile.

[matthamil]

@lucianomlima I'd like to see versions released with each update. Unless an improvement or feature doesn't make sense to be released by itself.

To answer @necolas and @Andreyco , I don't speak for every collaborator, but I believe that web support in react-navigation is not a priority for 1.0. The web support for react-navigation is very experimental currently, and there is plenty of work already to be done for mobile navigation. However, we'll gladly accept a PR that helps add web support. I'd love to see web support eventually.

[necolas]

I see, maybe it would be best to drop mention of web support for now? A lot of people incorrectly assume this library will work on web or with react-native-web.

[Andreyco]

Yep, I agree web support should not be priority for react-navigation at least to the point it reaches stability of v1. With all respect to everyone working on web support, we could agree there are better alternatives available.

It's extremely crucial to get mobile navigation right! :)

[Minishlink]

Concerning web, it doesn't seem to slow down the project: if you search for web in this repo, you get 4 commits and 77 issues, most of which being StackOverflow questions.
Making clear that it is experimental and not thoroughly tested wouldn't hurt, though it does the job for simple things.

[dantman]

Discussing whether support for web is useful based on whether react-navigation is useful in a browser or not is pointless. Browsers aren't the only target for web, web is also what you build to target other web based platforms like Chrome Apps with a variant of your mobile/tablet app.

[richardgirges]

Discussion of dropping/retaining web support for react navigation should probably be moved to a separate issue so we can keep this discussion focused on the v1 roadmap. I think the majority can agree that react navigation's v1 roadmap should focus only on native, considering this library is called out as the recommended navigator for react native.

[zarcode]

A lot of people "incorrectly" assume this library will work on the web because on docs site it says: "Share navigation logic between mobile apps, web apps, ..." or "Learn once, navigate anywhere" on GitHub. There are web projects that use this and depend on it because docs say it can be used on the web.

[joncursi]

I have lots of thoughts, but since there's already a lot on the table here, I'm only going to list my number one:

1. [Immediate Need]: Android performance (long list of issues here), hands down. Unfortunately, we can't ship apps to production with 2-5 second lags on every press. A lot of people in this community, myself included, have been banging heads on their keyboards trying to find ways to speed up screen transitions on Android so we can ship. The premise of react-native is the ability to kill 2 birds with one stone during app development, but right now this library is really only compatible with iOS. Speed is a feature, and Android is missing this out-of-the-box. @kelset mentioned that there are optimizations that can be made within this library to improve this situation, so in addition to being critical path, it also sounds like ppotentially low-hanging fruit.

[kelset]

@joncursi I think you sort of misunderstood my comment about performances you are referring to; what I mean there is that the "low-hanging fruit" resides outside the lib itself but in the Components' code written by developers. Improving perfs is surely something we want to work on but it may be quite complicated.

[MovingGifts]

@matthamil I think the Circular Reference Issue in StackNavigator we spoke about earlier is also an important unresolved part of this library. If you look at the labels added by @satya164 it becomes pretty obvious that it should be part of the library.

I don't know enough to fix it myself with a PR but I know it's pretty important to bring it up in this thread for a possible fix :) Thoughts?

[rabrenio]

Please add this feature #2659 it would be a great help, thanks.

[hoscarcito]

Is it possible to add the pending PRs related with the open issues??
For example, #780 is solved with #1803, and that PR is waiting for a review, but if we don't know about that PR we won't know the status of that issue. Even if it is solved in that PR or not, what we care is the status.
Thanks in advance!

[stereodenis]

@matthamil check "Allow multiple Drawers #780"

[matthamil]

Thanks, fixed @stereodenis :)

[luco]

Any chance taking a look on #2390 ?
It would be awesome.

[kelset]

Quick update guys, a lot of reinforcements arrived - and they will do some heavy lifting in the next few weeks - so if releases get bolder and crazier don't panic, it's because we are aiming for 1.0 for end of Q1.

[matthamil]

Huge shout-out to everyone who contributed to get this library to 1.0! 😄 https://reactnavigation.org/blog/2018/02/06/react-navigation-1.0.html

[jeveloper]

Thank you to all that made this happen !