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

General Feedback - React Navigation is just not good #2031

Closed
AlmogRnD opened this Issue Jun 30, 2017 · 68 comments

Comments

Projects
None yet
@AlmogRnD

AlmogRnD commented Jun 30, 2017

This is general feedback and hopefully, things can be improved. At this stage, I believe that react navigation should not be the official navigation. I would have to say this is one of the most frustrating router libs I have every seen (and I have worked with a lot). I think there are core issues when you try to build anything real world and not a simple hello world app.

Now, this might be just the documentation and it would be great to see some real examples that let you create complex navigations.

I'm running into simple issues trying to build a navigation, with public views like login, then dashboard using tabs and a drawer navigation with redux of course.

I'm not even sure you can jump between two different StackNavigator.

@AlanFoster

This comment has been minimized.

Show comment
Hide comment
@AlanFoster

AlanFoster Jun 30, 2017

Contributor

@AlmogRnD There is a redux example within the repository that you can follow

Contributor

AlanFoster commented Jun 30, 2017

@AlmogRnD There is a redux example within the repository that you can follow

@AlmogRnD

This comment has been minimized.

Show comment
Hide comment
@AlmogRnD

AlmogRnD Jun 30, 2017

@AlanFoster that was the first think I looked at and while it did help a little it's still a very basic example I had to figure a lot out and I'm still having a number of issues. At the end, I believe we need some better docs and more complicated examples. A real app will have drawer navigation, tabs navigation and public views with login/logout

AlmogRnD commented Jun 30, 2017

@AlanFoster that was the first think I looked at and while it did help a little it's still a very basic example I had to figure a lot out and I'm still having a number of issues. At the end, I believe we need some better docs and more complicated examples. A real app will have drawer navigation, tabs navigation and public views with login/logout

@AlmogRnD

This comment has been minimized.

Show comment
Hide comment
@AlmogRnD

AlmogRnD Jun 30, 2017

@akshaysinghi I know how to code, I'm not a beginner 10 years of experience and I have developed some complicated apps. I'm just saying there need to be better docs and some more complex examples a lot of the current examples out there are a bit outdated.

AlmogRnD commented Jun 30, 2017

@akshaysinghi I know how to code, I'm not a beginner 10 years of experience and I have developed some complicated apps. I'm just saying there need to be better docs and some more complex examples a lot of the current examples out there are a bit outdated.

@AlanFoster

This comment has been minimized.

Show comment
Hide comment
@AlanFoster

AlanFoster Jun 30, 2017

Contributor

it's still a very basic example I had to figure a lot out

If there are points missing from the documentation, please send a pull request to help pass on the knowledge 👍

There is additionally a larger example that @si-harps put a lot of effort into that you could check out - https://github.com/react-community/react-navigation/pull/1625/files

Contributor

AlanFoster commented Jun 30, 2017

it's still a very basic example I had to figure a lot out

If there are points missing from the documentation, please send a pull request to help pass on the knowledge 👍

There is additionally a larger example that @si-harps put a lot of effort into that you could check out - https://github.com/react-community/react-navigation/pull/1625/files

@matthamil

This comment has been minimized.

Show comment
Hide comment
@matthamil

matthamil Jul 1, 2017

Member

Hi @AlmogRnD and thank you for the feedback. I am a newer collaborator on this project, and I would like to take steps to improve the developer experience using react navigation. The documentation can be confusing, and we do need more real world examples using react navigation. Your honest feedback is very important to help this library progress and grow. If you have found any specific parts of the documentation to be confusing, or if there are any particular examples you wish to see more of (or wish that you saw in the past), please let me know.

@akshaysinghi Responding to a user's real concern in that manner does not provide any value to the one who opened the issue nor does it help any other user who stumbles across this issue.

Member

matthamil commented Jul 1, 2017

Hi @AlmogRnD and thank you for the feedback. I am a newer collaborator on this project, and I would like to take steps to improve the developer experience using react navigation. The documentation can be confusing, and we do need more real world examples using react navigation. Your honest feedback is very important to help this library progress and grow. If you have found any specific parts of the documentation to be confusing, or if there are any particular examples you wish to see more of (or wish that you saw in the past), please let me know.

@akshaysinghi Responding to a user's real concern in that manner does not provide any value to the one who opened the issue nor does it help any other user who stumbles across this issue.

@TheTekton

This comment has been minimized.

Show comment
Hide comment
@TheTekton

TheTekton Jul 1, 2017

Contributor

We have an app getting close to production using react-navigation (and redux) with a root navigator providing login flow, a tab navigator with nested navigators (tab config allows for stack screens to overlay tabs, there's a github issue with a good example, just can't find it quickly atm), and custom drawers. Started with basic/complex examples. Even with those, it took quite a bit of prying and trial/error to figure out a competent setup. Perhaps the complex example isn't complex enough? 😆

One caveat atm with our setup is the back navigation gesture takes the user to login when swiping from a drawer navigator's overlay view. Other than that, recent documentation updates in the latest beta version, with quite a bit of diving through github issues, have helped work through most of our issues. The one big problem with documentation I've had is that when it's missing bits, I'll look through github issues, and it isn't always clear what is old information and what is up-to-date.

All in all, frustrating, but does work fairly well when the blocks are put together just right.

Contributor

TheTekton commented Jul 1, 2017

We have an app getting close to production using react-navigation (and redux) with a root navigator providing login flow, a tab navigator with nested navigators (tab config allows for stack screens to overlay tabs, there's a github issue with a good example, just can't find it quickly atm), and custom drawers. Started with basic/complex examples. Even with those, it took quite a bit of prying and trial/error to figure out a competent setup. Perhaps the complex example isn't complex enough? 😆

One caveat atm with our setup is the back navigation gesture takes the user to login when swiping from a drawer navigator's overlay view. Other than that, recent documentation updates in the latest beta version, with quite a bit of diving through github issues, have helped work through most of our issues. The one big problem with documentation I've had is that when it's missing bits, I'll look through github issues, and it isn't always clear what is old information and what is up-to-date.

All in all, frustrating, but does work fairly well when the blocks are put together just right.

@allpwrfulroot

This comment has been minimized.

Show comment
Hide comment
@allpwrfulroot

allpwrfulroot Jul 1, 2017

I feel like there's a lack of cohesive vision for how this lib should work: from working with several different navigation systems over the past year, this feels the most jumbled. And you see it in the code you have to write for an app: it's not pretty, you know? It's powerful if you take the time to root around the github issues and experiment, but it's not understandable like react-router or even react-native-router-flux can be.

I'm curious, why this project for a router that rules them all? And after 6+ months with a lot of work and frustration, does it still make sense?

allpwrfulroot commented Jul 1, 2017

I feel like there's a lack of cohesive vision for how this lib should work: from working with several different navigation systems over the past year, this feels the most jumbled. And you see it in the code you have to write for an app: it's not pretty, you know? It's powerful if you take the time to root around the github issues and experiment, but it's not understandable like react-router or even react-native-router-flux can be.

I'm curious, why this project for a router that rules them all? And after 6+ months with a lot of work and frustration, does it still make sense?

@AlmogRnD

This comment has been minimized.

Show comment
Hide comment
@AlmogRnD

AlmogRnD Jul 2, 2017

Wanted to update on everything.

@AlanFoster the link you sent for that is an example is a GitHub changelog file no one will every find it and it's real hard to follow the whole point of good documentation is that it needs to be easy. You need to scroll like crazy and even then your looking changelog/diff files.

@matthamil it's really great to see contributors step up and help with this, makes me feel very confident with the direction and community behind react navigation thank you. At some point, I would also like to help out but I feel I'm learning the basics. Saying that I have thought about a couple different examples that I think would help, would be useful to everyone and would make a big impact.

  1. I think we need a good example showing the proper way to have public views like login, signup, reset password view and then private/locked views and how you would transfer between the two. One thing that I noticed if you do this within stack navigator you run into issues with the back button and swipe gesture back and there doesn't seem to be a way to load different stack navigators. It would be great if there was a clear example showing this.

  2. I think we need a more detailed example showing public view, tab navigator, stack navigator and drawer navigation. If you look at any real world apps you will see that they have tab navigator, stack navigator, and a drawer. It would also be good to show the correct way or best practices around this.

  3. The same as number 2 but with redux.

@TheTekton I'm at the same point I have some of the navigation working still having issues with the drawer and back button/gesture on login which to me this is very basic for any routing and should be easy to do and very clear. I had to spend a lot of time figuring things out and that is not a good sign for routing.

@allpwrfulroot I agree with you I really question why FB made this the official routing lib I think just don't feel it's clear yet

AlmogRnD commented Jul 2, 2017

Wanted to update on everything.

@AlanFoster the link you sent for that is an example is a GitHub changelog file no one will every find it and it's real hard to follow the whole point of good documentation is that it needs to be easy. You need to scroll like crazy and even then your looking changelog/diff files.

@matthamil it's really great to see contributors step up and help with this, makes me feel very confident with the direction and community behind react navigation thank you. At some point, I would also like to help out but I feel I'm learning the basics. Saying that I have thought about a couple different examples that I think would help, would be useful to everyone and would make a big impact.

  1. I think we need a good example showing the proper way to have public views like login, signup, reset password view and then private/locked views and how you would transfer between the two. One thing that I noticed if you do this within stack navigator you run into issues with the back button and swipe gesture back and there doesn't seem to be a way to load different stack navigators. It would be great if there was a clear example showing this.

  2. I think we need a more detailed example showing public view, tab navigator, stack navigator and drawer navigation. If you look at any real world apps you will see that they have tab navigator, stack navigator, and a drawer. It would also be good to show the correct way or best practices around this.

  3. The same as number 2 but with redux.

@TheTekton I'm at the same point I have some of the navigation working still having issues with the drawer and back button/gesture on login which to me this is very basic for any routing and should be easy to do and very clear. I had to spend a lot of time figuring things out and that is not a good sign for routing.

@allpwrfulroot I agree with you I really question why FB made this the official routing lib I think just don't feel it's clear yet

@prontiol

This comment has been minimized.

Show comment
Hide comment
@prontiol

prontiol Jul 2, 2017

My five cents:
Considering react-navigation is now the official navigation solution for react-native, I must admit it's being developed extremely slowly. There are 690 open issues and 63 open pull requests at the moment, core bugs are not being fixed for months, not enough documentation and examples.
Seeing so many open pull request not being merged distracts me from creating a new one from my side, and seeing so many bugs not being fixed for so long time distracts me from using the lib at all.
As a resume: I do not recommend anyone to start with this lib (at least now)

prontiol commented Jul 2, 2017

My five cents:
Considering react-navigation is now the official navigation solution for react-native, I must admit it's being developed extremely slowly. There are 690 open issues and 63 open pull requests at the moment, core bugs are not being fixed for months, not enough documentation and examples.
Seeing so many open pull request not being merged distracts me from creating a new one from my side, and seeing so many bugs not being fixed for so long time distracts me from using the lib at all.
As a resume: I do not recommend anyone to start with this lib (at least now)

@matthamil

This comment has been minimized.

Show comment
Hide comment
@matthamil

matthamil Jul 2, 2017

Member

@AlmogRnD Thank you for the list of examples you would like to see. I will work on making examples showing solutions to these common problems.

@prontiol I strongly encourage anyone to submit a PR if they are able to fix a bug or suggest a new feature. We are in the process of triaging issues and changes. We will be prioritizing bug fixes for now and resolving the issues that will bring react navigation to 1.0.

A lot of the open issues are common questions about the library that could be resolved with better documentation. If you find any part of the documentation lacking, please submit a PR or open an issue.

This library is a community effort. It can only be great if we all help out in one way or another 😄 . If you feel like you aren't experienced enough using react navigation to contribute, you can still make an impact by:

  1. Responding to one of the open Issues. Even if you can't resolve or fully answer a question, asking for more information or clarity on an issue is extremely beneficial for someone to come after you to resolve the issue.

  2. Creating public example repos of navigation problems you have solved.

  3. Documentation fixes. The Getting Started guide is for newcomers to the library. If you found it to be confusing or lacking, please let us know.

  4. Answering questions on Stack Overflow. Alternatively, asking questions on Stack Overflow instead of opening an issue.

  5. Answering questions in our Reactiflux channel. Alternatively, asking questions in the Reactiflux channel instead of opening an issue.

  6. Providing feedback on the open PRs.

I will close this issue for now. Thank you all for your feedback. I strongly encourage anyone to help the library by doing one of the items mentioned above or fixing bugs/proposing changes via PRs. This will help take some of the weight off of the core contributors to give them time to resolve the biggest issues.

Member

matthamil commented Jul 2, 2017

@AlmogRnD Thank you for the list of examples you would like to see. I will work on making examples showing solutions to these common problems.

@prontiol I strongly encourage anyone to submit a PR if they are able to fix a bug or suggest a new feature. We are in the process of triaging issues and changes. We will be prioritizing bug fixes for now and resolving the issues that will bring react navigation to 1.0.

A lot of the open issues are common questions about the library that could be resolved with better documentation. If you find any part of the documentation lacking, please submit a PR or open an issue.

This library is a community effort. It can only be great if we all help out in one way or another 😄 . If you feel like you aren't experienced enough using react navigation to contribute, you can still make an impact by:

  1. Responding to one of the open Issues. Even if you can't resolve or fully answer a question, asking for more information or clarity on an issue is extremely beneficial for someone to come after you to resolve the issue.

  2. Creating public example repos of navigation problems you have solved.

  3. Documentation fixes. The Getting Started guide is for newcomers to the library. If you found it to be confusing or lacking, please let us know.

  4. Answering questions on Stack Overflow. Alternatively, asking questions on Stack Overflow instead of opening an issue.

  5. Answering questions in our Reactiflux channel. Alternatively, asking questions in the Reactiflux channel instead of opening an issue.

  6. Providing feedback on the open PRs.

I will close this issue for now. Thank you all for your feedback. I strongly encourage anyone to help the library by doing one of the items mentioned above or fixing bugs/proposing changes via PRs. This will help take some of the weight off of the core contributors to give them time to resolve the biggest issues.

@matthamil matthamil closed this Jul 2, 2017

@dmr07

This comment has been minimized.

Show comment
Hide comment
@dmr07

dmr07 Jul 3, 2017

@AlmogRnD Respectfully, I have to disagree with you. I admit the learning curve is a little steeper your typical framework, like Angular 1, but only by a little. I mainly take issue with your comment about this not being production ready. I'm currently working on an app about ready to ship with a fairly complex navigation: including modals, multiple stacks, tabs nested in stacks and vice versa, and redux integration, etc. On multiple occasions I expected this library to fail, but it has held its own.

If you compare the setup with the Wix project, there is little difference.

The areas I do concede is that the declaration for routes is a little verbose, and the documentation for complex behavior is scattered among issues, but given the effort, one can figure it out. I personally don't have a good solution for the former, but the latter requires better documenting, obviously.

dmr07 commented Jul 3, 2017

@AlmogRnD Respectfully, I have to disagree with you. I admit the learning curve is a little steeper your typical framework, like Angular 1, but only by a little. I mainly take issue with your comment about this not being production ready. I'm currently working on an app about ready to ship with a fairly complex navigation: including modals, multiple stacks, tabs nested in stacks and vice versa, and redux integration, etc. On multiple occasions I expected this library to fail, but it has held its own.

If you compare the setup with the Wix project, there is little difference.

The areas I do concede is that the declaration for routes is a little verbose, and the documentation for complex behavior is scattered among issues, but given the effort, one can figure it out. I personally don't have a good solution for the former, but the latter requires better documenting, obviously.

@dmr07

This comment has been minimized.

Show comment
Hide comment
@dmr07

dmr07 Jul 3, 2017

@matthamil My app uses react-navigation for routing, and once its up on the app store, you guys are welcome to list it as a production-example if it passes your level of quality. (It can illustrate working modals, tabs, nested routes, etc.)

dmr07 commented Jul 3, 2017

@matthamil My app uses react-navigation for routing, and once its up on the app store, you guys are welcome to list it as a production-example if it passes your level of quality. (It can illustrate working modals, tabs, nested routes, etc.)

@AlmogRnD

This comment has been minimized.

Show comment
Hide comment
@AlmogRnD

AlmogRnD Jul 4, 2017

@dmr07 I'm not saying the code is not ready or not good, I'm using it for a production app that is under development. What I'm saying that to be a good production lib. you must have good documentation and examples and right now that is no where as good as it should be plus I don't want to have to go thru Github issues that defeat the purpose.

I would also suggest that you might create a tutorial/ blog post on how you did things, I would be interested and that might actually be helpful.

AlmogRnD commented Jul 4, 2017

@dmr07 I'm not saying the code is not ready or not good, I'm using it for a production app that is under development. What I'm saying that to be a good production lib. you must have good documentation and examples and right now that is no where as good as it should be plus I don't want to have to go thru Github issues that defeat the purpose.

I would also suggest that you might create a tutorial/ blog post on how you did things, I would be interested and that might actually be helpful.

@vexsnare

This comment has been minimized.

Show comment
Hide comment
@vexsnare

vexsnare Jul 4, 2017

We can have a complex example application in this repo with login/logout and other complex navigations like jumping between drawer & tabs. It would surely help developers.

vexsnare commented Jul 4, 2017

We can have a complex example application in this repo with login/logout and other complex navigations like jumping between drawer & tabs. It would surely help developers.

@amanthegreatone

This comment has been minimized.

Show comment
Hide comment
@amanthegreatone

amanthegreatone Jul 4, 2017

https://gist.github.com/ronnyhartenstein/1ef30c90f530f99430969925198d6970

this post helped me setup parallel navigators with login password etc in one stack and the other is the drawer. hope this helps

amanthegreatone commented Jul 4, 2017

https://gist.github.com/ronnyhartenstein/1ef30c90f530f99430969925198d6970

this post helped me setup parallel navigators with login password etc in one stack and the other is the drawer. hope this helps

@joseph0x01

This comment has been minimized.

Show comment
Hide comment
@joseph0x01

joseph0x01 Jul 5, 2017

It could be helpful if the react navigation documentation provides a concise guide for those who are migrating from the old RN Navigator. For things like how to migrate from navigator.replace() etc.

joseph0x01 commented Jul 5, 2017

It could be helpful if the react navigation documentation provides a concise guide for those who are migrating from the old RN Navigator. For things like how to migrate from navigator.replace() etc.

@quadsurf

This comment has been minimized.

Show comment
Hide comment
@quadsurf

quadsurf Jul 11, 2017

this should help when comparing reactNavigation with react-native-router-flux...

  1. react native router flux (RNRF) is more mature and less buggy (only 7 out of ~1600 issues are open, versus reactNavigation that has 75% of their ~1000 issues that are still open)

  2. if you're just a programmer, reactNavigation is a great choice, but if you're a programmer and a businessman in need of efficiencies, then reactNavigation is not a practical choice (here's why: reactNavigation is more complicated than it needs to be, and has a much longer learning curve, especially for apps with complex nav requirements and its insufficient lib documentation leaves you needlessly experimenting for hours ( i agree with @AlmogRnD )... reactNavigation is great for the programmer looking for a challenge and wanting to improve their troubleshooting skills, but unacceptable for dev shops or business folk where time efficiencies are needed)

  3. reactNavigation, at it's core, does have a nice API, but it's needlessly complex... the purpose of the RNRF lib and what it's attempting with v4, is not to compete with or replace reactNavigation, but to abstract away all of reactNavigation's unnecessary complexity

  4. if you're a fan of conditional component/screen rendering, which is a very common pattern in React Native, then RNRF is more conducive to this pattern

  5. react native loses its right to call itself an un-opinionated framework when it chooses one library over another (like a government trying to pick corporate winners and losers in the marketplace)... but here we are, in a world where react native chose reactNavigation... i believe RNRF's decision to utilize reactNavigation's api in RNRF v4, was to create "association" with react-native's bias, and maintain that library's relevance... a good move i might add
    RNRF/react-native-router-flux#2001

  6. reactNavigation does not have a true modal implementation*, where as RNRF does (and by modal i'm referring to a prompt/alert style pop-up with grayed-out background), and when you call yourself a navigation library, this becomes a glaring/blatant omission i might add

quadsurf commented Jul 11, 2017

this should help when comparing reactNavigation with react-native-router-flux...

  1. react native router flux (RNRF) is more mature and less buggy (only 7 out of ~1600 issues are open, versus reactNavigation that has 75% of their ~1000 issues that are still open)

  2. if you're just a programmer, reactNavigation is a great choice, but if you're a programmer and a businessman in need of efficiencies, then reactNavigation is not a practical choice (here's why: reactNavigation is more complicated than it needs to be, and has a much longer learning curve, especially for apps with complex nav requirements and its insufficient lib documentation leaves you needlessly experimenting for hours ( i agree with @AlmogRnD )... reactNavigation is great for the programmer looking for a challenge and wanting to improve their troubleshooting skills, but unacceptable for dev shops or business folk where time efficiencies are needed)

  3. reactNavigation, at it's core, does have a nice API, but it's needlessly complex... the purpose of the RNRF lib and what it's attempting with v4, is not to compete with or replace reactNavigation, but to abstract away all of reactNavigation's unnecessary complexity

  4. if you're a fan of conditional component/screen rendering, which is a very common pattern in React Native, then RNRF is more conducive to this pattern

  5. react native loses its right to call itself an un-opinionated framework when it chooses one library over another (like a government trying to pick corporate winners and losers in the marketplace)... but here we are, in a world where react native chose reactNavigation... i believe RNRF's decision to utilize reactNavigation's api in RNRF v4, was to create "association" with react-native's bias, and maintain that library's relevance... a good move i might add
    RNRF/react-native-router-flux#2001

  6. reactNavigation does not have a true modal implementation*, where as RNRF does (and by modal i'm referring to a prompt/alert style pop-up with grayed-out background), and when you call yourself a navigation library, this becomes a glaring/blatant omission i might add

@matthamil

This comment has been minimized.

Show comment
Hide comment
@matthamil

matthamil Jul 11, 2017

Member

Hi @quadsurf , thank you for your feedback. If you have concerns with React Navigation's complexity, can you open a new issue with your concerns? What changes would you like to see? Documentation updates are one of my highest priorities currently, and I will be working to update them.

Member

matthamil commented Jul 11, 2017

Hi @quadsurf , thank you for your feedback. If you have concerns with React Navigation's complexity, can you open a new issue with your concerns? What changes would you like to see? Documentation updates are one of my highest priorities currently, and I will be working to update them.

@quadsurf

This comment has been minimized.

Show comment
Hide comment
@quadsurf

quadsurf Jul 11, 2017

thank you @matthamil

i would love to see some documentation on how to implement a prompt/alert style modal, with grayed-out background (typical in most navigation libs)

your TabNavigation example in your docs, is completely different than the Expo example, which causes confusion

the best documentation in my opinion, is one that possesses a more complex example app for reference... look to react-native-router-flux library for inspiration... they have an app that showcases all its capabilities, including structuring an app's flow with login, register, auth-protected content, etc ... this is highly needed for this lib... thank you for your contribution Matt :-)

quadsurf commented Jul 11, 2017

thank you @matthamil

i would love to see some documentation on how to implement a prompt/alert style modal, with grayed-out background (typical in most navigation libs)

your TabNavigation example in your docs, is completely different than the Expo example, which causes confusion

the best documentation in my opinion, is one that possesses a more complex example app for reference... look to react-native-router-flux library for inspiration... they have an app that showcases all its capabilities, including structuring an app's flow with login, register, auth-protected content, etc ... this is highly needed for this lib... thank you for your contribution Matt :-)

@dmr07

This comment has been minimized.

Show comment
Hide comment
@dmr07

dmr07 Jul 12, 2017

@quadsurf If you're looking for feedback, I have a few as well. I'm not sure what the solutions to these are, but these are just my pain-points.

  1. Uses cases: The examples in the documentation right now gave a pretty good overview of how simple navigations are built, but are not instructive when things become more complicated. In my case, I wanted to simulate a modal without actually using RN's Modal component (since they don't jibe well with this lib).

  2. I think this library is either over-ambitious in the features it attempts to provide or it fails to simplify complexity. Parts of the API breaks down in nuanced use cases, which aren't well documented. An example is that this.props.navigation.navigate is scoped; ideally the navigator is global and has access to all routes.

  3. Noticing my own pattern as a developer, I find myself scouring the issues more than most other libraries. In getting the modal background to be transparent, someone in the issues had to tell me to set the opacity in CardStyles to 1 - which is completely out of the blue. And likely in no other case would I have guessed that would have been the issue.

As a general observation, the libraries I've enjoyed using had APIs that were iron clad. This library seems rather unopinionated in the sense that there are multiple ways of achieving a desired effect. In doing so, these additional use-cases go untested and undocumented. I surmise that is the reason for the number of issues opened each day.

dmr07 commented Jul 12, 2017

@quadsurf If you're looking for feedback, I have a few as well. I'm not sure what the solutions to these are, but these are just my pain-points.

  1. Uses cases: The examples in the documentation right now gave a pretty good overview of how simple navigations are built, but are not instructive when things become more complicated. In my case, I wanted to simulate a modal without actually using RN's Modal component (since they don't jibe well with this lib).

  2. I think this library is either over-ambitious in the features it attempts to provide or it fails to simplify complexity. Parts of the API breaks down in nuanced use cases, which aren't well documented. An example is that this.props.navigation.navigate is scoped; ideally the navigator is global and has access to all routes.

  3. Noticing my own pattern as a developer, I find myself scouring the issues more than most other libraries. In getting the modal background to be transparent, someone in the issues had to tell me to set the opacity in CardStyles to 1 - which is completely out of the blue. And likely in no other case would I have guessed that would have been the issue.

As a general observation, the libraries I've enjoyed using had APIs that were iron clad. This library seems rather unopinionated in the sense that there are multiple ways of achieving a desired effect. In doing so, these additional use-cases go untested and undocumented. I surmise that is the reason for the number of issues opened each day.

@AlmogRnD

This comment has been minimized.

Show comment
Hide comment
@AlmogRnD

AlmogRnD Jul 12, 2017

Why was this issue closed?

AlmogRnD commented Jul 12, 2017

Why was this issue closed?

@RobIsHere

This comment has been minimized.

Show comment
Hide comment
@RobIsHere

RobIsHere Jul 16, 2017

What this project really needs is a skilled leading engineer who has enough dedicated time with this.

IMO the pulled-in stuff from other projects into this project have led to wrong software design patterns I'm seeing now.

Old Experimental, React-Native Drawer with react-native-drawer-layout-polyfill on iOS, react-native-tab-view have influenced and restricted design decisions. The biggest problem is the inconsistent code base and that there's no integral plan for important things like animations, at least I didn't find it here.

The wrong patterns lead to followup problems:

  • Invented an api based on what's possible with the foreign components, not on the developer's needs
  • Consistent design of animation support is simply not possible with the foreign components, to get animations right you need a good plan from start otherwise it will be hacks
  • Header only available in StackNavigator is a good example problem, too
  • Different structure of navigation state by Navigator type another
  • Hard to learn/make fit for your needs: TabNavigator, StackNavigator and DrawerNavigator work internally totally different. No common code base where you understand one and also bigger part of the others.
  • Hard to extend: you have to do the extension for every navigator again and again. Most things are only possible by forking, no drop in replacements/enhancements for simple things.

I think, the number of issues 1700 related to 330 commits=units of work at all are a symptom of this.
The 143 Contributors related to 330 commits are cool, because the community really drives the project. But it also leads to even more fragmentation without an integral plan.

I'm sure this project is the best navigation lib that existed till now. But if the fundamental problems don't get solved very soon, it will fail. At the moment I will continue using it. With mixed feelings in my gut.

RobIsHere commented Jul 16, 2017

What this project really needs is a skilled leading engineer who has enough dedicated time with this.

IMO the pulled-in stuff from other projects into this project have led to wrong software design patterns I'm seeing now.

Old Experimental, React-Native Drawer with react-native-drawer-layout-polyfill on iOS, react-native-tab-view have influenced and restricted design decisions. The biggest problem is the inconsistent code base and that there's no integral plan for important things like animations, at least I didn't find it here.

The wrong patterns lead to followup problems:

  • Invented an api based on what's possible with the foreign components, not on the developer's needs
  • Consistent design of animation support is simply not possible with the foreign components, to get animations right you need a good plan from start otherwise it will be hacks
  • Header only available in StackNavigator is a good example problem, too
  • Different structure of navigation state by Navigator type another
  • Hard to learn/make fit for your needs: TabNavigator, StackNavigator and DrawerNavigator work internally totally different. No common code base where you understand one and also bigger part of the others.
  • Hard to extend: you have to do the extension for every navigator again and again. Most things are only possible by forking, no drop in replacements/enhancements for simple things.

I think, the number of issues 1700 related to 330 commits=units of work at all are a symptom of this.
The 143 Contributors related to 330 commits are cool, because the community really drives the project. But it also leads to even more fragmentation without an integral plan.

I'm sure this project is the best navigation lib that existed till now. But if the fundamental problems don't get solved very soon, it will fail. At the moment I will continue using it. With mixed feelings in my gut.

@Noor0

This comment has been minimized.

Show comment
Hide comment
@Noor0

Noor0 Jul 20, 2017

i think they need to address the most common use cases of the library in the docs and follow a single pattern for code. You can define navigationProps at 2 or 3 places but in the docs it's a static prop on a component.

Noor0 commented Jul 20, 2017

i think they need to address the most common use cases of the library in the docs and follow a single pattern for code. You can define navigationProps at 2 or 3 places but in the docs it's a static prop on a component.

@allpwrfulroot

This comment has been minimized.

Show comment
Hide comment
@allpwrfulroot

allpwrfulroot Jul 20, 2017

I made a complex demo with:

  • Custom Drawer navigation
  • Tab navigation with nested and wrapped Stacks
  • Reset
  • Modal
  • Etc

If it's useful, how would people like to see it contributed back to the react-navigation team? Are there additional things that could be added? Improved?
https://github.com/allpwrfulroot/yaba-social

allpwrfulroot commented Jul 20, 2017

I made a complex demo with:

  • Custom Drawer navigation
  • Tab navigation with nested and wrapped Stacks
  • Reset
  • Modal
  • Etc

If it's useful, how would people like to see it contributed back to the react-navigation team? Are there additional things that could be added? Improved?
https://github.com/allpwrfulroot/yaba-social

@jfilter

This comment has been minimized.

Show comment
Hide comment
@jfilter

jfilter Jul 23, 2017

I don't see how a general "everything is shit" is going to help anybody. Due to the fast-paced nature of React Native, there is no proper stable navigation solution yet. If you don't like to work with cutting-edge technology, don't do React Native.

jfilter commented Jul 23, 2017

I don't see how a general "everything is shit" is going to help anybody. Due to the fast-paced nature of React Native, there is no proper stable navigation solution yet. If you don't like to work with cutting-edge technology, don't do React Native.

@quadsurf

This comment has been minimized.

Show comment
Hide comment
@quadsurf

quadsurf Jul 27, 2017

@matthamil i found a react-navigation boilerplate app by (SpencerCarli) that helped put this lib in more perspective for me, and is inclining me to revisit or give this lib another chance

https://github.com/spencercarli/getting-started-react-navigation

quadsurf commented Jul 27, 2017

@matthamil i found a react-navigation boilerplate app by (SpencerCarli) that helped put this lib in more perspective for me, and is inclining me to revisit or give this lib another chance

https://github.com/spencercarli/getting-started-react-navigation

@quadsurf

This comment has been minimized.

Show comment
Hide comment
@quadsurf

quadsurf Jul 27, 2017

@allpwrfulroot your example app, was the best and most thorough example I've seen... super clean, and covered some pretty complex nav flows necessary for structuring common apps... it was a godsend, thank you! (@matthamil this app converted me back to react-navigation)

a few questions though for @allpwrfulroot ...

  1. i didn't see the "Reset" feature in your example app, where is this example in your app?

  2. how do you refresh a component in place? (similar to how react-native-router-flux does it with:
    Actions.refresh({ param1: 'hello', param2: 'world' })

  3. i think adding in a react-navigation -powered lightbox modal in to your app demo, would be the perfect way to complete this amazing example app ... the react-navigation should 100% adopt this, and it would eliminate soooo much confusion and reduce this lib's learning curve and facilitate further adoption

quadsurf commented Jul 27, 2017

@allpwrfulroot your example app, was the best and most thorough example I've seen... super clean, and covered some pretty complex nav flows necessary for structuring common apps... it was a godsend, thank you! (@matthamil this app converted me back to react-navigation)

a few questions though for @allpwrfulroot ...

  1. i didn't see the "Reset" feature in your example app, where is this example in your app?

  2. how do you refresh a component in place? (similar to how react-native-router-flux does it with:
    Actions.refresh({ param1: 'hello', param2: 'world' })

  3. i think adding in a react-navigation -powered lightbox modal in to your app demo, would be the perfect way to complete this amazing example app ... the react-navigation should 100% adopt this, and it would eliminate soooo much confusion and reduce this lib's learning curve and facilitate further adoption

@RobIsHere

This comment has been minimized.

Show comment
Hide comment
@RobIsHere

RobIsHere Jul 27, 2017

My concern is that react-navigation is by far not complex enough. It's easy to understand, easy to reason about, ... but far too difficult to achieve beautiful things, because the structure of the code is so unstructured. I'm absolutely not in need of boilerplates or examples - I know every LOC and nearly every open and closed issue by now - that's where I learned the hard way, what's not possible ;)

I have been "hitting the wall" even in a 8 screens app constantly:

  • turning the Drawer animation into parallax, shifting the main screen away
  • opening modal overlays (having animation available to also animate screen content)
  • animating content inside of the screens synchronized with the route transition animation
  • use the same custom header in stacknavigator and in tabnavigator
  • doing transitions that originate from some element(s) or point (plus button) on the underlying screen
  • replacing routes with animations
  • configuring transitions independent of the position in the navigation stack and having different animations

I solved all of this on my own. But I thought that is, what a navigation is about?

RobIsHere commented Jul 27, 2017

My concern is that react-navigation is by far not complex enough. It's easy to understand, easy to reason about, ... but far too difficult to achieve beautiful things, because the structure of the code is so unstructured. I'm absolutely not in need of boilerplates or examples - I know every LOC and nearly every open and closed issue by now - that's where I learned the hard way, what's not possible ;)

I have been "hitting the wall" even in a 8 screens app constantly:

  • turning the Drawer animation into parallax, shifting the main screen away
  • opening modal overlays (having animation available to also animate screen content)
  • animating content inside of the screens synchronized with the route transition animation
  • use the same custom header in stacknavigator and in tabnavigator
  • doing transitions that originate from some element(s) or point (plus button) on the underlying screen
  • replacing routes with animations
  • configuring transitions independent of the position in the navigation stack and having different animations

I solved all of this on my own. But I thought that is, what a navigation is about?

@dantman

This comment has been minimized.

Show comment
Hide comment
@dantman

dantman Sep 15, 2017

Contributor

Combine props with navigationOptions to avoid hacky and unresponsive setParams to change Navigator configuration like the title

Is there an issue on this topic? More detail on this idea would be nice to see and discuss.

Testing suite and CI are broken

Not sure if you're also talking about the lack of tests for much of react-navigation that can only be tested while it's rendered. If so, I made some notes in my PR #1313 (comment) about the troubles with the current test renderers and some pending changes in react-native that should make it possible to write render tests for react-navigation.

Contributor

dantman commented Sep 15, 2017

Combine props with navigationOptions to avoid hacky and unresponsive setParams to change Navigator configuration like the title

Is there an issue on this topic? More detail on this idea would be nice to see and discuss.

Testing suite and CI are broken

Not sure if you're also talking about the lack of tests for much of react-navigation that can only be tested while it's rendered. If so, I made some notes in my PR #1313 (comment) about the troubles with the current test renderers and some pending changes in react-native that should make it possible to write render tests for react-navigation.

@sospedra

This comment has been minimized.

Show comment
Hide comment
@sospedra

sospedra Sep 18, 2017

@dantman

I didn't found an specific issue with the navigationOptions thing. But you can find it inside a lot of comments related to these issues

And the overall feeling that "dynamic", "changing", and words like these alongside with navigationOptions shouldn't be that hard. Or at least, no trigger that many issues.

About the testing. Agree with you. Actually, I tried to review your PR but I felt very unconfortable not being able to run some tests to see that any previous work was broken.

Hence, I change a bit the list with the last two contributions ;)

sospedra commented Sep 18, 2017

@dantman

I didn't found an specific issue with the navigationOptions thing. But you can find it inside a lot of comments related to these issues

And the overall feeling that "dynamic", "changing", and words like these alongside with navigationOptions shouldn't be that hard. Or at least, no trigger that many issues.

About the testing. Agree with you. Actually, I tried to review your PR but I felt very unconfortable not being able to run some tests to see that any previous work was broken.

Hence, I change a bit the list with the last two contributions ;)

@hysan

This comment has been minimized.

Show comment
Hide comment
@hysan

hysan Sep 22, 2017

Contributor

@spencercarli

I took some time today to get caught back up on the state of the issues I've been following, the new roadmap forward, and all of the discussions that have been happening the past couple of weeks.

First off, thank you for putting in the work and getting some long awaited PRs merged recently.

Second, while I agree that keeping things in a single issue would probably be better for discussion, I don't think this one should be closed with the V1 release. The issues being discussed here (compiled by @sospedra ) cover a lot more very important issues than what is targeted for the V1 release. In my opinion, this issue should be kept open to:

  • Serve as a larger milestone for react-navigation.
  • Prevent the issues discussed here from polluting the conversation in #2585 which itself is already quite ambitious and already growing more so as more PRs are mentioned for inclusion.
  • Give the community a place to discuss the importance of issues and how they should be prioritized post V1.
  • Lastly, be a reminder of what happened over the past few months; namely that #2476 happened.

I really appreciate all of the hard work everyone has and is putting into this project. I want this to succeed. However, right now I still do not have full confidence in the future of react-navigation. My greatest concern right now is that once V1 is reached, the issues discussed here will fall to the wayside or even worse, maintainers will step away again and we will be left to reopen this very same issue again.

I hope that the day this issue is closed will be the day react-navigation can live up to the official documentation's recommendation as the navigation library to use.

Contributor

hysan commented Sep 22, 2017

@spencercarli

I took some time today to get caught back up on the state of the issues I've been following, the new roadmap forward, and all of the discussions that have been happening the past couple of weeks.

First off, thank you for putting in the work and getting some long awaited PRs merged recently.

Second, while I agree that keeping things in a single issue would probably be better for discussion, I don't think this one should be closed with the V1 release. The issues being discussed here (compiled by @sospedra ) cover a lot more very important issues than what is targeted for the V1 release. In my opinion, this issue should be kept open to:

  • Serve as a larger milestone for react-navigation.
  • Prevent the issues discussed here from polluting the conversation in #2585 which itself is already quite ambitious and already growing more so as more PRs are mentioned for inclusion.
  • Give the community a place to discuss the importance of issues and how they should be prioritized post V1.
  • Lastly, be a reminder of what happened over the past few months; namely that #2476 happened.

I really appreciate all of the hard work everyone has and is putting into this project. I want this to succeed. However, right now I still do not have full confidence in the future of react-navigation. My greatest concern right now is that once V1 is reached, the issues discussed here will fall to the wayside or even worse, maintainers will step away again and we will be left to reopen this very same issue again.

I hope that the day this issue is closed will be the day react-navigation can live up to the official documentation's recommendation as the navigation library to use.

@sospedra

This comment has been minimized.

Show comment
Hide comment
@sospedra

sospedra Sep 23, 2017

I can clearly see your points @hysan

And I'm wondering if you have any suggestions for these:

  1. How we could manage better all the complex communication going on here?
  2. Any tips to avoid maintainers flying away after V1?

sospedra commented Sep 23, 2017

I can clearly see your points @hysan

And I'm wondering if you have any suggestions for these:

  1. How we could manage better all the complex communication going on here?
  2. Any tips to avoid maintainers flying away after V1?
@Etheryte

This comment has been minimized.

Show comment
Hide comment
@Etheryte

Etheryte Sep 27, 2017

I'd like to echo that in its current state, the documentation is confusing and lacking, rather than helpful and straightforward. Oftentimes it's easier to just grep this repository for the method names and figure out the logic from code instead of reading the documentation.

Etheryte commented Sep 27, 2017

I'd like to echo that in its current state, the documentation is confusing and lacking, rather than helpful and straightforward. Oftentimes it's easier to just grep this repository for the method names and figure out the logic from code instead of reading the documentation.

@hysan

This comment has been minimized.

Show comment
Hide comment
@hysan

hysan Sep 27, 2017

Contributor

@sospedra

I'm probably not the right person to ask those questions as this is the first open source project that I've actively tried to be involved in. But I can at least try to answer from the perspective of a user who would like to contribute back:

  1. The conversations haven't been difficult for me to follow. What has been a problem has been the lack of communication (and maybe transparency) from the project leaders about what is going on. This past month has alleviated this, but there's currently no guarantee that this will be continued. I have a guess as to why this happened which also loops into...
  2. How to keep maintainers from flying away post V1.

My guess as to why this happened and why it might happen again post V1 is:

  • Facebook's recommendation came way too early and caused a huge influx of redundant issues.
  • Burnout because the original contributor team was too small.
  • Lack of structured organization of the project (very much improved with the labels).
  • No one dedicated to keeping docs up to date (we have @spencercarli now).
  • No one dedicated to straight maintenance (bug fixing).

The new contributors are a great step in fixing things, but I still feel like the team is far too small for a project with such a big goal (support navigation everywhere; maybe not web depending on how the conversation in #2585 pans out). The current size seems just big enough to keep the project moving forward in a maintainable state. However, that doesn't account for contributor downtime (work, vacations, etc.) and one bump can lead the project to start spiraling downward. So, planning to expand the team in the near future might help greatly in the long run.

As someone who's actively interested contributing back, my greatest issues have been:

  • Trying to find some sort of style guide to code against.
  • These specific issues that have already been mentioned/discussed here that makes it scary to approach the codebase:
    • Be less opinionated and follow more general accepted Javascript design patterns
    • Make easier for community devs to help. Better code structur and quality. Simplify logics.
    • Improve docs: which components are exposed, which props can be override, add best practices, ...
    • Define and be consistent with the design patterns. Favour either stateless or classes components. Favour composition or FP. And so on
    • Testing suite and CI are broken. And very much missing.
  • Tracking discussions about core changes to the code. For example:
    • When all the breaking changes around navigation options were introduced in v1.0.0-beta.9 from #984.
      • Look at how the linked issue #48 had the bulk of the discussion around why this needed to changed, but it was closed as a no fix. Only to be reopened again and closed as fixed.
      • Don't get me wrong. This was a great fix and obviously a lot of work. My issue stems from this specific comment that recognizes how big of a change this is and that it should be accompanied by a blog post on release.
      • That blog post never came and it left me having to dig through all the linked issues to understand why things were changed. Release notes are fine, but for such a huge core change, a summary of the discussions was sorely needed in my opinion. Which also leads into...
  • Looping back to the first thing I mentioned, the lack of updates to the community.
    • As someone who is not a contributor nor a dedicated resource to react-navigation, it's hard to know if my time is best spent here (because help is needed) or elsewhere on smaller projects. Had a blog post been made simply saying, "We need help reviewing PRs and Triaging Issues!" I feel like most of this could have been avoided. I definitely would have jumped in to help (I already try to answer as many react-navigation questions as possible on StackOverflow after all) and others probably would have as well.

If something is done about those issues, I feel like there would be much greater community participation.

I don't think any of this helps to answer either of your questions, but it's all I've got as someone who's inexperienced in open source. I hope it helps.

Contributor

hysan commented Sep 27, 2017

@sospedra

I'm probably not the right person to ask those questions as this is the first open source project that I've actively tried to be involved in. But I can at least try to answer from the perspective of a user who would like to contribute back:

  1. The conversations haven't been difficult for me to follow. What has been a problem has been the lack of communication (and maybe transparency) from the project leaders about what is going on. This past month has alleviated this, but there's currently no guarantee that this will be continued. I have a guess as to why this happened which also loops into...
  2. How to keep maintainers from flying away post V1.

My guess as to why this happened and why it might happen again post V1 is:

  • Facebook's recommendation came way too early and caused a huge influx of redundant issues.
  • Burnout because the original contributor team was too small.
  • Lack of structured organization of the project (very much improved with the labels).
  • No one dedicated to keeping docs up to date (we have @spencercarli now).
  • No one dedicated to straight maintenance (bug fixing).

The new contributors are a great step in fixing things, but I still feel like the team is far too small for a project with such a big goal (support navigation everywhere; maybe not web depending on how the conversation in #2585 pans out). The current size seems just big enough to keep the project moving forward in a maintainable state. However, that doesn't account for contributor downtime (work, vacations, etc.) and one bump can lead the project to start spiraling downward. So, planning to expand the team in the near future might help greatly in the long run.

As someone who's actively interested contributing back, my greatest issues have been:

  • Trying to find some sort of style guide to code against.
  • These specific issues that have already been mentioned/discussed here that makes it scary to approach the codebase:
    • Be less opinionated and follow more general accepted Javascript design patterns
    • Make easier for community devs to help. Better code structur and quality. Simplify logics.
    • Improve docs: which components are exposed, which props can be override, add best practices, ...
    • Define and be consistent with the design patterns. Favour either stateless or classes components. Favour composition or FP. And so on
    • Testing suite and CI are broken. And very much missing.
  • Tracking discussions about core changes to the code. For example:
    • When all the breaking changes around navigation options were introduced in v1.0.0-beta.9 from #984.
      • Look at how the linked issue #48 had the bulk of the discussion around why this needed to changed, but it was closed as a no fix. Only to be reopened again and closed as fixed.
      • Don't get me wrong. This was a great fix and obviously a lot of work. My issue stems from this specific comment that recognizes how big of a change this is and that it should be accompanied by a blog post on release.
      • That blog post never came and it left me having to dig through all the linked issues to understand why things were changed. Release notes are fine, but for such a huge core change, a summary of the discussions was sorely needed in my opinion. Which also leads into...
  • Looping back to the first thing I mentioned, the lack of updates to the community.
    • As someone who is not a contributor nor a dedicated resource to react-navigation, it's hard to know if my time is best spent here (because help is needed) or elsewhere on smaller projects. Had a blog post been made simply saying, "We need help reviewing PRs and Triaging Issues!" I feel like most of this could have been avoided. I definitely would have jumped in to help (I already try to answer as many react-navigation questions as possible on StackOverflow after all) and others probably would have as well.

If something is done about those issues, I feel like there would be much greater community participation.

I don't think any of this helps to answer either of your questions, but it's all I've got as someone who's inexperienced in open source. I hope it helps.

@matthamil

This comment has been minimized.

Show comment
Hide comment
@matthamil

matthamil Sep 27, 2017

Member

Hi @hysan , you might have missed our recent blog post which addresses some of your concerns.

I'm not worried about the new maintainers stepping away. Expo is also interested in this project, so it's more than a few random community members wanting to keep it up :). Some of the original maintainers stepped away from the project in June (they have done some awesome groundwork and I greatly appreciate all they have done for the project!) and the new maintainers are a very recent addition to the project.

If you want to help get more involved with the project (we can use any and all help), feel free to reach out to me on Twitter @_matthamil or take a look at the roadmap to 1.0 and submit a PR 😄

Member

matthamil commented Sep 27, 2017

Hi @hysan , you might have missed our recent blog post which addresses some of your concerns.

I'm not worried about the new maintainers stepping away. Expo is also interested in this project, so it's more than a few random community members wanting to keep it up :). Some of the original maintainers stepped away from the project in June (they have done some awesome groundwork and I greatly appreciate all they have done for the project!) and the new maintainers are a very recent addition to the project.

If you want to help get more involved with the project (we can use any and all help), feel free to reach out to me on Twitter @_matthamil or take a look at the roadmap to 1.0 and submit a PR 😄

@davebro

This comment has been minimized.

Show comment
Hide comment
@davebro

davebro Oct 10, 2017

Genuinely curious, why does Facebook not include a built-in router within React Native? Why leave something as crucial as the router to ill-maintained third party libraries? I'm not trying to crush React Navigation contributors, really more directed towards Facebook, surely they have some kind of routing implementation we could benefit from.

I think others have stated it well, if you don't want to spend six months in pure agony trying to get every little thing to work and you have deadlines and targeted goals, don't use this, maybe something more like React Native Router Flux (that's where I'm headed back to). But, if you want to spend your Friday nights getting nerdy, by all means, don't let me stop you ;)

davebro commented Oct 10, 2017

Genuinely curious, why does Facebook not include a built-in router within React Native? Why leave something as crucial as the router to ill-maintained third party libraries? I'm not trying to crush React Navigation contributors, really more directed towards Facebook, surely they have some kind of routing implementation we could benefit from.

I think others have stated it well, if you don't want to spend six months in pure agony trying to get every little thing to work and you have deadlines and targeted goals, don't use this, maybe something more like React Native Router Flux (that's where I'm headed back to). But, if you want to spend your Friday nights getting nerdy, by all means, don't let me stop you ;)

@dantman

This comment has been minimized.

Show comment
Hide comment
@dantman

dantman Oct 10, 2017

Contributor

@davebro react-native did, NavigatorIOS, then Navigator, then NavigatorExperimental.

They were all some form of problematic (restrictive, too complex and hard to use, or both). Being part core react-native (a large repository, with a majority of contributors not working on navigation, and modifications requiring some level of Facebook approval) of course also makes development slow.

Ultimately navigation is a user-level feature that doesn't need to be part of react-native, so it's better off in a separate repository.

Contributor

dantman commented Oct 10, 2017

@davebro react-native did, NavigatorIOS, then Navigator, then NavigatorExperimental.

They were all some form of problematic (restrictive, too complex and hard to use, or both). Being part core react-native (a large repository, with a majority of contributors not working on navigation, and modifications requiring some level of Facebook approval) of course also makes development slow.

Ultimately navigation is a user-level feature that doesn't need to be part of react-native, so it's better off in a separate repository.

@RobIsHere

This comment has been minimized.

Show comment
Hide comment
@RobIsHere

RobIsHere Oct 10, 2017

Looking at FB is not fair. They have version numbers <1.0. So everything you can do is state your opinion and hope it gets better, or try to contribute if your time allows that - and that's true for everything in RN, not just react-navigation.

IMO this thread is not about complaining but about naming issues clearly. Because if the contributors know what's going on, they can react :) to it in a better way.

RobIsHere commented Oct 10, 2017

Looking at FB is not fair. They have version numbers <1.0. So everything you can do is state your opinion and hope it gets better, or try to contribute if your time allows that - and that's true for everything in RN, not just react-navigation.

IMO this thread is not about complaining but about naming issues clearly. Because if the contributors know what's going on, they can react :) to it in a better way.

@voidstarfire

This comment has been minimized.

Show comment
Hide comment
@voidstarfire

voidstarfire Oct 10, 2017

I would suggest https://github.com/wix/react-native-navigation
It's by far the best one I've used, it's really simple to use and has a good 'native' feel about it as it actually does the screen transitions natively loading a new React view state in a container. I've used 5 navigators and this one shines out from the rest.

voidstarfire commented Oct 10, 2017

I would suggest https://github.com/wix/react-native-navigation
It's by far the best one I've used, it's really simple to use and has a good 'native' feel about it as it actually does the screen transitions natively loading a new React view state in a container. I've used 5 navigators and this one shines out from the rest.

@agm1984

This comment has been minimized.

Show comment
Hide comment
@agm1984

agm1984 Oct 13, 2017

I posted an answer on stack overflow after my experiences over the past couple days. I think it illustrates how exactly to use react-navigation in an app that is ready to scale big-time horizontally.

https://stackoverflow.com/questions/42876690/react-navigation-with-login-screen

I read a lot of frustrated people's experiences, and I experienced the learning curve myself, so I posted a complete example.

If you are having trouble and you find this post, definitely give that SO answer a forensic skim.

After figuring it out, it's awesome, but there critically needs to be more full examples out there. I encourage everyone to make them and refer to them. I read hundreds of posts and articles over the past couple days, and my navigation is pretty badass now TBH, effortless nesting capability with Redux integration and require_auth HOC, can go backwards or forwards in the stack with next to nil imports or state mapping.

The problem with the docs is there are like 47 ways to wire it up, and as you get more advanced, you see it all circles around connecting it properly at the root level. The Redux integration was brain fryingly difficult to figure out because of all the logic in play, and its 100x worse if you get some bad logic in there and try to work around it. I would recommend piling out examples that have to do with organizing the root level. Feel free to paste my code. I don't have time to figure out how to make PRs. I will do that over the next few months.

This library is totally in line with the React and Redux philosphy, in my opinion. It's still a bit rough but only because it assumes you know what every part of react-navigation is doing. That will improve over time. I see the power in react-navigation. I wouldn't like to see people deviate from it at this point. I am well aware of the areas that will cause people to get jammed up for 5 hours. I'm talking about the root navigator, nav reducer, helpers, and the navigator configs. The learning curve is brutal for people looking to take 1 step away from browserHistory or react-native-router-flux. Every piece of those logicks needs at LEAST 5-10 examples in different context. That would make an epic size dent in the number of issues and confusion raised.

The library is actually really easy to use once you spend 30 hours studying its behaviour. That's how long it took me anyway. My most objective opinion is that its currently designed by and for highly-advanced users. One needs to assume zero knowledge and ask "what would I say if a person said 'what is that?' after every noun keyword in the docs?". The docs need to be double the size with 300% more example code for each part of the library. You can't give entry level users 5 different ways to wire it up. They need one that clearly works or doesn't. The docs do not currently do that. I pasted in the Redux integration example code and mine literally didn't even work in a standalone project built for the example. It didn't work until I used NavigationStack.router.getStateForAction(NavigationActions.init()) which is only mentioned once on one line in the docs. I found the answer in a YouTube video and it blew the doors open on my whole operation.

agm1984 commented Oct 13, 2017

I posted an answer on stack overflow after my experiences over the past couple days. I think it illustrates how exactly to use react-navigation in an app that is ready to scale big-time horizontally.

https://stackoverflow.com/questions/42876690/react-navigation-with-login-screen

I read a lot of frustrated people's experiences, and I experienced the learning curve myself, so I posted a complete example.

If you are having trouble and you find this post, definitely give that SO answer a forensic skim.

After figuring it out, it's awesome, but there critically needs to be more full examples out there. I encourage everyone to make them and refer to them. I read hundreds of posts and articles over the past couple days, and my navigation is pretty badass now TBH, effortless nesting capability with Redux integration and require_auth HOC, can go backwards or forwards in the stack with next to nil imports or state mapping.

The problem with the docs is there are like 47 ways to wire it up, and as you get more advanced, you see it all circles around connecting it properly at the root level. The Redux integration was brain fryingly difficult to figure out because of all the logic in play, and its 100x worse if you get some bad logic in there and try to work around it. I would recommend piling out examples that have to do with organizing the root level. Feel free to paste my code. I don't have time to figure out how to make PRs. I will do that over the next few months.

This library is totally in line with the React and Redux philosphy, in my opinion. It's still a bit rough but only because it assumes you know what every part of react-navigation is doing. That will improve over time. I see the power in react-navigation. I wouldn't like to see people deviate from it at this point. I am well aware of the areas that will cause people to get jammed up for 5 hours. I'm talking about the root navigator, nav reducer, helpers, and the navigator configs. The learning curve is brutal for people looking to take 1 step away from browserHistory or react-native-router-flux. Every piece of those logicks needs at LEAST 5-10 examples in different context. That would make an epic size dent in the number of issues and confusion raised.

The library is actually really easy to use once you spend 30 hours studying its behaviour. That's how long it took me anyway. My most objective opinion is that its currently designed by and for highly-advanced users. One needs to assume zero knowledge and ask "what would I say if a person said 'what is that?' after every noun keyword in the docs?". The docs need to be double the size with 300% more example code for each part of the library. You can't give entry level users 5 different ways to wire it up. They need one that clearly works or doesn't. The docs do not currently do that. I pasted in the Redux integration example code and mine literally didn't even work in a standalone project built for the example. It didn't work until I used NavigationStack.router.getStateForAction(NavigationActions.init()) which is only mentioned once on one line in the docs. I found the answer in a YouTube video and it blew the doors open on my whole operation.

@hengsoheak

This comment has been minimized.

Show comment
Hide comment
@hengsoheak

hengsoheak Oct 28, 2017

Finanlly React-native-navigation is better enough for production?

hengsoheak commented Oct 28, 2017

Finanlly React-native-navigation is better enough for production?

@spencercarli

This comment has been minimized.

Show comment
Hide comment
@spencercarli

spencercarli Oct 28, 2017

Member

@agm1984 thanks for you're in depth response & helping many in the community! Hopefully we can help reduce that learning curve :)

@hengsoheak this repo is react-navigation, which is different from react-native-navigation. Similar goals, different implementations.

Member

spencercarli commented Oct 28, 2017

@agm1984 thanks for you're in depth response & helping many in the community! Hopefully we can help reduce that learning curve :)

@hengsoheak this repo is react-navigation, which is different from react-native-navigation. Similar goals, different implementations.

@shauns

This comment has been minimized.

Show comment
Hide comment
@shauns

shauns Nov 23, 2017

I think a lot of frustration comes from things which should be 'easy' from a library user's point of view just not being there. Things like:

  • Is my component top of the stack/the active tab?
  • Can I wait for a navigation action to 'finish'/Can I know when navigation transitions are running?
  • What's the opinionated right way to handle modals? What's the right way to handle 'pre' screens like a login before the main app?

I understand these aren't easy to solve conceptually or in a performant way -- I've tried myself to dive in and submit a PR. The more I look at it though the more I think a lot of this comes from things being too flexible. Beyond Stack->Tab->Stack, how common are nested navigators? It's nice that any component can function as a route, but how often is it the case that something operates as a regular component and as a route? I think there's a space for a more opinionated, higher-level, API, that can use all the cool flexibility in the main project.

shauns commented Nov 23, 2017

I think a lot of frustration comes from things which should be 'easy' from a library user's point of view just not being there. Things like:

  • Is my component top of the stack/the active tab?
  • Can I wait for a navigation action to 'finish'/Can I know when navigation transitions are running?
  • What's the opinionated right way to handle modals? What's the right way to handle 'pre' screens like a login before the main app?

I understand these aren't easy to solve conceptually or in a performant way -- I've tried myself to dive in and submit a PR. The more I look at it though the more I think a lot of this comes from things being too flexible. Beyond Stack->Tab->Stack, how common are nested navigators? It's nice that any component can function as a route, but how often is it the case that something operates as a regular component and as a route? I think there's a space for a more opinionated, higher-level, API, that can use all the cool flexibility in the main project.

@mhaagens

This comment has been minimized.

Show comment
Hide comment
@mhaagens

mhaagens Nov 23, 2017

It's easy enough to use, but just adding a map to a screen made me have to switch over to react-native-navigation. The app became very unresponsive, lag when clicking navigation buttons, jank when swiping out of the screen etc.

mhaagens commented Nov 23, 2017

It's easy enough to use, but just adding a map to a screen made me have to switch over to react-native-navigation. The app became very unresponsive, lag when clicking navigation buttons, jank when swiping out of the screen etc.

@MoOx

This comment has been minimized.

Show comment
Hide comment
@MoOx

MoOx Nov 24, 2017

@mhaagens I encountered issue when using heavy native components like map (with react-native-maps). The best thing to do is to delay the display of the map until transition are finished. You now get your native feeling back. For UX point of view, just throw a empty view with a background color matching your map. That's what Apple Maps does for example (when you open the app, you get a empty view with a yellowish background for a few ms).

It's very easy when relying on InteractionsManager (and be sure to implement a setTimeout 1000 as a fallback since runAfterInteractions callback can be never called in some edge cases).

Here is the trick I am using to get a 100% sure runAfterInteractions execution

// @flow

import { InteractionManager } from 'react-native';

const maxDefaultDelay = 500;

export default {
  ...InteractionManager,
  runAfterInteractions: (callback: () => void, maxDelay = maxDefaultDelay) => {
    // ensure callback get called, timeout at 500ms
    // https://github.com/facebook/react-native/issues/8624
    let called = false;
    const timeout = setTimeout(() => {
      called = true;
      callback();
    }, maxDelay);
    InteractionManager.runAfterInteractions(() => {
      // already executed, don't do it twice
      if (called) {
        return;
      }
      // to be sure we don't have a race condition
      clearTimeout(timeout);

      // be sure to execute callback
      callback();
    });
  },
};

Hope that helps. In my case, it make app perfectly fluid even on shitty androids!

MoOx commented Nov 24, 2017

@mhaagens I encountered issue when using heavy native components like map (with react-native-maps). The best thing to do is to delay the display of the map until transition are finished. You now get your native feeling back. For UX point of view, just throw a empty view with a background color matching your map. That's what Apple Maps does for example (when you open the app, you get a empty view with a yellowish background for a few ms).

It's very easy when relying on InteractionsManager (and be sure to implement a setTimeout 1000 as a fallback since runAfterInteractions callback can be never called in some edge cases).

Here is the trick I am using to get a 100% sure runAfterInteractions execution

// @flow

import { InteractionManager } from 'react-native';

const maxDefaultDelay = 500;

export default {
  ...InteractionManager,
  runAfterInteractions: (callback: () => void, maxDelay = maxDefaultDelay) => {
    // ensure callback get called, timeout at 500ms
    // https://github.com/facebook/react-native/issues/8624
    let called = false;
    const timeout = setTimeout(() => {
      called = true;
      callback();
    }, maxDelay);
    InteractionManager.runAfterInteractions(() => {
      // already executed, don't do it twice
      if (called) {
        return;
      }
      // to be sure we don't have a race condition
      clearTimeout(timeout);

      // be sure to execute callback
      callback();
    });
  },
};

Hope that helps. In my case, it make app perfectly fluid even on shitty androids!

@MoOx

This comment has been minimized.

Show comment
Hide comment
@MoOx

MoOx Nov 24, 2017

Btw this should be probably explained in RNavigation docs somewhere!

MoOx commented Nov 24, 2017

Btw this should be probably explained in RNavigation docs somewhere!

@mhaagens

This comment has been minimized.

Show comment
Hide comment
@mhaagens

mhaagens Nov 24, 2017

@MoOx Thanks for the tip, looks like a solid workaround! Does feel a bit dirty to have to use setTimeout in something as important as a navigation lib, but I guess there's no way around it.

mhaagens commented Nov 24, 2017

@MoOx Thanks for the tip, looks like a solid workaround! Does feel a bit dirty to have to use setTimeout in something as important as a navigation lib, but I guess there's no way around it.

@voidstarfire

This comment has been minimized.

Show comment
Hide comment
@voidstarfire

voidstarfire Nov 24, 2017

@mhaagens use a different library, going to save you a lot of hassle! Also setTimeout is broken unless you use it with a Mixin that attaches it to the component. Don't recommend this way.

voidstarfire commented Nov 24, 2017

@mhaagens use a different library, going to save you a lot of hassle! Also setTimeout is broken unless you use it with a Mixin that attaches it to the component. Don't recommend this way.

@dantman

This comment has been minimized.

Show comment
Hide comment
@dantman

dantman Nov 24, 2017

Contributor

setTimeout is not broken in this context, runAfterInteractions itself doesn't have cancellation so rather than a timeout mixin you need to track whether your screen unmounts in between mount and when the transition finishes.

Although that's extremely unlikely anyways since for that to happen the user would have to press the back button before the transition finishes, and react-navigation would have to somehow abort the transition and immediately start transitioning back and unmount the screen before the transition finishes.

In any case, this is good practice no matter what library you're doing. Don't do heavy work on the device while the device is busy trying to animate between screens.

Contributor

dantman commented Nov 24, 2017

setTimeout is not broken in this context, runAfterInteractions itself doesn't have cancellation so rather than a timeout mixin you need to track whether your screen unmounts in between mount and when the transition finishes.

Although that's extremely unlikely anyways since for that to happen the user would have to press the back button before the transition finishes, and react-navigation would have to somehow abort the transition and immediately start transitioning back and unmount the screen before the transition finishes.

In any case, this is good practice no matter what library you're doing. Don't do heavy work on the device while the device is busy trying to animate between screens.

@walter211

This comment has been minimized.

Show comment
Hide comment
@walter211

walter211 Dec 26, 2017

Seriously, is this most issues lib in github!?

walter211 commented Dec 26, 2017

Seriously, is this most issues lib in github!?

@yordis yordis referenced this issue Jan 17, 2018

Open

RRN future #54

@brentvatne brentvatne closed this Jan 23, 2018

@react-navigation react-navigation locked as too heated and limited conversation to collaborators Jan 23, 2018

@brentvatne

This comment has been minimized.

Show comment
Hide comment
@brentvatne

brentvatne Jan 23, 2018

Member

closing because the issue tracker is for bugs well defined and reproducible bugs that we can fix. you can send general feedback to brent@expo.io if you like.

Member

brentvatne commented Jan 23, 2018

closing because the issue tracker is for bugs well defined and reproducible bugs that we can fix. you can send general feedback to brent@expo.io if you like.

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