react-navigation / react-navigation.github.io Goto Github PK
View Code? Open in Web Editor NEWHome of the documentation and other miscellanea
Home Page: https://reactnavigation.org/
License: MIT License
Home of the documentation and other miscellanea
Home Page: https://reactnavigation.org/
License: MIT License
What limitations do we have around this?
Hi. In my team we’ve struggled to implement conditional child navigation, where a branch of the navigation depends on user data (e.g. data in Redux and/or received from an API). In pseudo-code:
const Section1Default = StackNavigator(/* Some screens */)
const Section1Onboarding = StackNavigator(/* Different screens */)
const RootNavigator = TabNavigator({
section1: Section1Default OR Section1Onboarding,
section2: …,
section3: …
})
The idea is that when clicking on a specific tab, the user should see either a series of "onboarding" screens or the feature’s screens. (Both options are navigators themselves, but could be single screens too.)
@brentvatne & @ericvicenti Do you think that’s a use case worth addressing in the docs?
I think I could contribute a page section or a page on this, but I’m not sure what solution to offer.
So far we’ve only found hackish workarounds, such as: a wrapper component which has a StackRouter with the two navigation branches, and which navigates to the correct branch on willFocus
. It works, but the trick falls short when using the Android back button.
Hi, I noticed a discrepancy between the documentation and implementation of keys used for navigation, for example in the case of navigating backwards from a specific screen in the stack using goBack(key). The documentation, especially the code examples, make it seem like the key is the route name, however this is not the case and does not work. The documentation should be updated to reflect this, currently it is very misleading and the code examples provided do not work in practice.
Using navigation events. See react-navigation/react-navigation#2803
Moved from react-navigation/react-navigation#3890
Using multiple Navigators inside a DrawerNavigator, where the subnavigators shared a route name, led to unexpected (undocumented) behavior
software | version |
---|---|
react-navigation | 1.5.9 |
react-native | expo@26 |
I was an early user of @expo/ex-navigation, and have recently been upgrading to react-navigation. I came across some faults in either the DrawerNavigation documentation or in the general mental framework of react-navigation.
When nesting navigators inside a DrawerNavigator, duplicated route names behave unexpectedly (in my mental model).
Expo Snack repro
const WidgetStack = StackNavigator({
Widget: {
screen: WidgetScreen,
},
// This is very easy to get wrong, it is not clear in the Drawer documentation
// that this route name should be distinct.
Settings: {
screen: SettingsScreen,
},
});
const SettingsStack = StackNavigator({
Settings: {
screen: SettingsScreen,
},
});
const DrawerApp = DrawerNavigator({
Widget: {
screen: WidgetStack,
},
Settings: {
screen: SettingsStack,
},
}, {
initialRouteName: 'Widget',
});
When tapping on the "Settings" drawer item, I expected the currently selected "tab" in the drawer to be "Settings", I expected no routes to be "pushed" onto my stack navigator. Instead, the "widget" tab stays selected, and a settings route is pushed onto the WidgetStack.
There were no pieces of documentation to warn me of this behavior, and it was actually very difficult to even tell this is what was happening (it was much easier when I decided to build the minimal repro).
My mental model for react-navigation was previously that each nested navigator was a "subtree". With that model, I saw no issue with a duplicated route name.
DrawerApp
/ \
WidgetStack SettingsStack
| | |
/ \ Settings
Widget Settings
I'm not here to debate whether this is the correct model, but a simple piece of documentation would have saved me about an entire day :(
I would be happy to submit a PR to address this, but it appears with the 2.0 push, this might be out of date, and furthermore - I am not sure if my current model is correct enough to even write docs.
Is there any plan to support multilingual for the website? I guess it'd be very useful if we do.
There's this gist I just shared. It's based on a running project I'm working on.
https://gist.github.com/sidferreira/72e17d29b224ca93cf86901ed1ceb032
Feel free to link or copy.
In any way, a mention will be acceptable
Suggestions are welcome
ps: I still tweaking it, so, if you prefer, I can beep when I feel it a bit more "done"
My related StackOverflow question is at https://stackoverflow.com/questions/48830648/how-to-define-a-route-and-then-create-a-simple-crosslink-to-that-route
How do I simply define/register a route such that I can call navigation.navigation('Someroute')? And how do I do this without an approach like StackNavigator or TabNavigator that also impacts the UI?
Is it possible in React Navigation to simply load a screen (component) according to a route?
Thank you.
I assume that the intended functionality was actually to link to the react-navigation repo, not GitHub itself. If so, I can submit a PR
Is there a public API for jumping to some path, like what happens when the app is opened by a deep link? would it just be Linking.openURL
? https://github.com/react-navigation/react-navigation/blob/c72b44ce104e5fbeb67624c44b792eca82285119/src/createNavigationContainer.js#L75-L84
Can the documentation be updated to explain about route keys. Various parts of the API (Reset, Back) refer to them. However, there is no description of what these are or how they are set on the routes.
Linear gradient, translucent, transparent, etc..
Documentation for transitionConfig
mentions:
take a look at TransitionConfig in type definitions
The link to type definitions is dead. Where would I find a reference to the default transitionsConfig
?
Moved from react-navigation/react-navigation#1439
cc @ericvicenti
Followed the instructions and yet:
Custom header:
const stackNav = StackNavigator({
shiftsList: {
screen: ScreenShifts,
path: 'list',
navigationOptions: ({navigation}) => ({
header: <Titlebar showSettings={true} showNotificationCenter={true} navigation={navigation}>
<ShiftToggler />
</Titlebar>
}),
},
Wrapping the TabNav with SafeAreaView solves this but introduces a huge bottom margin. The TabNav is probably wrapped internally with SafeAreaView.
Wrapping the ScreenShifts with SafeAreaView does not solve this.
Any ideas?
About order of
navigationOptions
. From the code, the order of overwritten isStackNavigatorConfig
->Component's static config
->RouteConfigs
Moved over from react-navigation/react-navigation#3003
@spencercarli came up with this solution: https://snack.expo.io/SyJKMkFUM
We might need to change the API a bit to make it cleaner but we can document this approach for now!
It would be great to get documentation done for this "open modal from tab bar" layout. I've seen it asked a bunch of times in different places as it's a very common/popular requirement.
While not as helpful as writing documentation myself, here are some of the places this was asked, to show it would be useful to have it in the official docs:
@TomAtterton seems to have a solution in this issue
react-navigation/react-navigation#1576
He also left the same comment here:
Anyway, best practice or not, Tom seems to have the only solution? Maybe he could give a slightly longer form answer and that can be used for docs? @spencercarli
I will try to write something up potentially.
When I run the simulator, I am seeing a message suggesting that TabNavigator is deprecated. Is this true? Here is what I see in the terminal if I run the simulator with react-native run-ios:
9:19:29 AM: Finished building JavaScript bundle in 8834ms
9:19:34 AM: TabNavigator is deprecated. Please use the createBottomTabNavigator or createMaterialTopNavigator instead.
- node_modules/react-navigation/src/react-navigation.js:52:6 in TabNavigator
* App.js:50:17 in <unknown>
- node_modules/metro/src/lib/polyfills/require.js:213:12 in loadModuleImplementation
- node_modules/react-native-scripts/build/bin/crna-entry.js:7:11 in <unknown>
- node_modules/metro/src/lib/polyfills/require.js:213:12 in loadModuleImplementation
- node_modules/metro/src/lib/polyfills/require.js:140:45 in guardedLoadModule
* null:null in global code
This has some people pretty frustrated and rightfully so as we don't indicate upfront anywhere that they will run into blockers on this. See: react-navigation/react-navigation#717
For example, react-intl uses context: react-navigation/react-navigation#2770. @satya164 gives a very good answer here
Explain that we only support a few of the possible combinations:
Stack->Tabs->Stack
Stack->Stack->Tabs
Drawer->Tabs->Stack
Drawer->Stack
For example, we do not properly support putting drawers inside of a stack: react-navigation/react-navigation#374
This is a general question to all who are using react navigation, there is no documentation as to navigate to particular screen when user receives a notification
export const createRootNavigator = (signedIn = false) => {
return StackNavigator({
Login: screen: Login,
Welcome: screen: Welcome,
Loading: screen: Loading,
SignedIn: screen: SignedIn,
});
};
export const SignedIn = TabNavigator ({
Home: screen: HomeNavigation,
FeedBack: screen: FeedBackNavigation,
Search: screen: SearchNavigation,
Me: screen: ProfileNavigation,
});
I am using 'react-native-fcm' to receive the notification when app is in foreground or closed. How should I structure the code to navigate to specific screens upon receiving notification?
Shall I subscribe to onNotification in every screen and then navigate to specific screen or have it at a centralized place? Has anyone tackled this before? sample code would be great
software | version |
---|---|
react-navigation | 1.0.0-beta.26 |
react-native | 0.49.3 |
react-navigation/react-navigation#3143 shows that there is some confusion about nesting navigators as screens. This will probably require improving the API to make this more ergonomic, but for now we should at least make this super clear.
react-navigation/react-navigation#3692
Seems like a reasonable thing to document
I think we need to still do more thinking about the right way to handle this in the library. Blocking a second action is wrong (hard to understand when you actually want to do this why it didn't work) and our current solution of using idempotent pushes (provide a key) isn't as ergonomic as it could be.
Should have docs for new state persistence stuff
The preferred pattern for handling dialogs and menus don't seem to have been discussed yet.
Menus that open from a menu button are a fairly common pattern.
I can see 2 possible ways they might be implemented:
setParams
to set a param indicating the menu is open and that param is passed to whatever prop on the menu indicates it is open. Closing the menu is another setParams
. One would have to either use <Modal />
or manually register a BackAndroid
(now BackHandler
) to handle the Android "back button closes menu instead of navigating backwards" pattern.navigator.navigate('MenuName')
and exited using navigator.goBack()
.Dialogs are another modal type to consider (given the drawer is already considered a navigator).
Drawers make less sense as part of props but there are still 2-3 patterns I can think of for them:
navigator.navigate
to open a specific dialog from the associated screen.navigation.navigate
calls more complex in any scenario, opening a dialog by navigating to it is simple, and closing a dialog via navigator.goBack()
is built-in. Also this would already handle full-screen dialogs pretty well and handle the tablet+mobile environment where a route may be a full-screen dialog with a header in the stack route on mobile but be a dialog on a tablet without a header.Full-screen dialogs themselves are probably a separate more precise discussion.
While going through the documentation I found that drawer navigation is lacking snack expo example, unlike other navigation.
I know that it is obvious at that point on how to use the navigation but I think it would be of great help if there was a working example that we can edit on the fly.
Thanks.
Be sure to include any limitations/bugs
The website documentation has a section on "Opening a Full Screen Modal" (here).
The method described is to have two child Stack Navigators with a shared parent. The children are created with mode: "modal"
and mode: "card"
, respectively.
Given this setup, let's assume a user opens an app to a card
Screen. As soon he navigates to a modal
screen, wouldn't the modal
StackNavigator contain an unwanted screen at the root of its stack -- the screen that StackNavigator created by default as the initial route? Of course it's possible to provide an initialRouteName
, but in this scenario, it doesn't make sense to do so. The modal
navigator's screens are not meant to be shown in succession, and hence, this navigator has no conceptual initial route.
Is there a way to address this that I am missing? It seems like the documented approach would create problems with back behavior given the existence of the initial screen at the root of the modal
StackNavigator.
We expose routers independently from react-navigation, but they aren't documented
https://snack.expo.io/@react-navigation/custom-header-title-component
is the exact same as
https://snack.expo.io/@react-navigation/overriding-shared-header-styles
I believe https://snack.expo.io/@react-navigation/custom-header-title-component needs to be changed.
Hey people, especially @ericvicenti, @brentvatne
First of all I would like to tell you that I'm extremely grateful for your work, I know that open-source projects are based on developers free-time, and this doesn't force to give any guarantees.
I'm also a member of this community. I just want to improve the software and make him more accessible to people that are using it.
It's been 3 weeks that I'm stuck for building a huge application for my client working in the medical (great company). My brain is boiling, I tried to turn the problem in all directions. I always face the failure. I've been forced to hack the library and the behavior in many way but I can't escape anymore and I would like to do the right things to have a top quality product.
Samples & even demonstration are cool, but I can't find anywhere (and god knows I tried everywhere to ask some help and tried so many things) to render a complete routing for a great application.
I would be really graceful to you if you can light me up, also the community and I would be really pleased to improve the documentation from the point of view of a man that is not part of the library core (and you can trust me this is important that the documentation is from that point of view...)
Below is a representation of my application screens as I structured them in my mind (I might be wrong):
Looks simpIe on the paper, right ? But not so easy in fact...
This is just so hard to represent and make it work... WHY ? What is the purpose of such a library if we can't use it for great companies that require complexe UI. For you consideration, you concurrents already show a way to deal with that case such as HERE.
What I would like you to do is the following:
Can you provide an (or some) examples that shows :
TabNavigator
All of this without broking the navigation state because I need to both:
I think this is a top priority, not only because I need it but because if people can't understand how you were thinking when you designed the library, they won't be able to realize great things using it and will probably go somewhere else to achieve what they have to...
I wish you a great day,
Best regards.
Andréas
PS : If I can help you for that in any way, just tell me.
Hello,
I am really new to this library and working on my app to replace old deprecated navigator with this one.
I got stuck when i need to verify authentication with deep linking.
May be we can put it in the docs on how to handle authentication flow with deep linking.
Thanks
D
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.