New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Renewed Path to React Navigation V1.0 #2585

Closed
matthamil opened this Issue Sep 15, 2017 · 41 comments

Comments

Projects
@matthamil
Member

matthamil commented Sep 15, 2017

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

Resolved issues from original roadmap:

  • Header bar overriding #1220
  • Resetting non-deepest navigator #691
  • Simplified Nav Options #722

Look at this later


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

This comment has been minimized.

Contributor

plasticine commented Sep 15, 2017

@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

This comment has been minimized.

allmaxgit commented Sep 15, 2017

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

@matthamil

This comment has been minimized.

Member

matthamil commented Sep 15, 2017

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

@allmaxgit

This comment has been minimized.

allmaxgit commented Sep 15, 2017

@younanjo

This comment has been minimized.

younanjo commented Sep 15, 2017

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

@matthamil

This comment has been minimized.

Member

matthamil commented Sep 15, 2017

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.

@matthamil matthamil added this to Path to V1.0 in Path to V1.0 Sep 15, 2017

@matthamil matthamil referenced this issue Sep 15, 2017

Closed

v2 Roadmap #1263

0 of 1 task complete
@koenpunt

This comment has been minimized.

Contributor

koenpunt commented Sep 15, 2017

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

This comment has been minimized.

Contributor

ferrannp commented Sep 15, 2017

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

@Ashoat

This comment has been minimized.

Member

Ashoat commented Sep 15, 2017

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

This comment has been minimized.

sospedra commented Sep 15, 2017

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 #639 #2291
  • Prevent navigating twice to the same rotue + params #135 #2331 #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 #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?

@sospedra

This comment has been minimized.

sospedra commented Sep 15, 2017

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.

This was referenced Sep 15, 2017

@hysan

This comment has been minimized.

Contributor

hysan commented Sep 15, 2017

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

@matthamil

This comment has been minimized.

Member

matthamil commented Sep 15, 2017

@hysan Done, thanks for catching that.

@jacksontbryan

This comment has been minimized.

jacksontbryan commented Sep 15, 2017

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

@necolas

This comment has been minimized.

necolas commented Sep 15, 2017

What are your plans for web support?

@rpopovici

This comment has been minimized.

rpopovici commented Sep 15, 2017

@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

This comment has been minimized.

Contributor

dantman commented Sep 15, 2017

  • #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).

@matthamil

This comment has been minimized.

Member

matthamil commented Sep 15, 2017

@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

This comment has been minimized.

Contributor

dantman commented Sep 15, 2017

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

This comment has been minimized.

lucianomlima commented Sep 18, 2017

@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

This comment has been minimized.

Contributor

Andreyco commented Sep 18, 2017

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

This comment has been minimized.

MoOx commented Sep 18, 2017

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

This comment has been minimized.

Contributor

Andreyco commented Sep 18, 2017

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

@matthamil

This comment has been minimized.

Member

matthamil commented Sep 18, 2017

@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

This comment has been minimized.

necolas commented Sep 18, 2017

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

This comment has been minimized.

Contributor

Andreyco commented Sep 18, 2017

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

This comment has been minimized.

Contributor

Minishlink commented Sep 18, 2017

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

This comment has been minimized.

Contributor

dantman commented Sep 18, 2017

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

This comment has been minimized.

richardgirges commented Sep 19, 2017

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

This comment has been minimized.

zarcode commented Sep 19, 2017

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

This comment has been minimized.

joncursi commented Sep 23, 2017

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

This comment has been minimized.

Contributor

kelset commented Sep 24, 2017

@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

This comment has been minimized.

MovingGifts commented Oct 7, 2017

@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

This comment has been minimized.

rabrenio commented Nov 14, 2017

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

@hoscarcito

This comment has been minimized.

hoscarcito commented Nov 29, 2017

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

This comment has been minimized.

Contributor

stereodenis commented Nov 30, 2017

@matthamil check "Allow multiple Drawers #780"

@matthamil

This comment has been minimized.

Member

matthamil commented Nov 30, 2017

Thanks, fixed @stereodenis :)

@luco

This comment has been minimized.

luco commented Dec 25, 2017

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

@kelset

This comment has been minimized.

Contributor

kelset commented Jan 19, 2018

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

This comment has been minimized.

Member

matthamil commented Feb 7, 2018

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

This comment has been minimized.

jeveloper commented Feb 7, 2018

Thank you to all that made this happen !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment