Renewed Path to React Navigation V1.0
matthamil opened this issue · 41 comments
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 #3401 #3403 #3404
- Improve Reset NavigationAction #1663
- Navigate key for idempotent pushes #135
- Resolve go back issues: #2454
- Screen lifecycle hooks #51
- Fix issues with drawer navigator - #374
- Allow multiple Drawers #780
Resolved issues from original roadmap:
Look at this later
- Fix inter-navigator issues #88
- Add customizable per-screen transitions #175, #124, #690, #232, #707, #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:
- When opening a new Issue, fill out the Issue Template. This helps maintainers and the community at large to resolve your issue quickly.
- Close issues that are now resolved.
- Answer questions in the Issues.
- Ask questions on StackOverflow and in the Reactiflux community Discord (and answer questions there too :)).
- 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.
@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.
❤️
Tabs connected to Redux on android very slow. Please add it fix in Roadmap.
Do you have an open issue for this problem @allmaxgit?
@matthamil any chance this guy can be looked into as part of the roadmap? #1493
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.
What do you think about improving Android transitions? They are totally off right now comparing to native. See #726.
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.
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
resetas part of thegoBackissue? If not, I think it's very important and requested #639 #2291 - Prevent navigating twice to the same rotue + params #135 #2331 #2396
- Connect component's props with navigationOptions (avoid hacky and unresponsive
setParamson 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 #706 #608 #726
- Reset parent navigationOptions when goBack #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?
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.
@matthamil Could you fix the Reactiflux link? It's broken.
What are your plans for web support?
@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
- #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
- #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 #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).
@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
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?
@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?
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
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)...
Fair point here, but I still think web based twitter does more job per screen than on mobile.
@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.
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.
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! :)
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.
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.
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.
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.
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:
- [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-nativeis 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.
@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.
@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?
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!
@matthamil check "Allow multiple Drawers #780"
Thanks, fixed @stereodenis :)
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.
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
Thank you to all that made this happen !