I see a lot of folks in the react-navigation issues section using this.props.navigation.dispatch to programmatically navigate. Is there any specific reason or use case to use that over this.props.navigation.navigate?
It seems like you can pass more options to the dispatch function? Is there anything else? Can you use dispatch without explicitly tying react-navigation into your apps redux store? Right now I have an app that has redux, but I dont explicitly configure my redux setup to know about react-navigation (and would prefer to keep it that way if I can).
From github 👇🏻:
This is the code of navigate function which reuses navigation.dispatch.. And remember:
Code Don't Lie
Then, navigation.navigate(...args) is an alias of navigation.dispatch(NavigationActions.navigate(...args))
From the React Navigation docs The Navigation Prop chapter (https://reactnavigation.org/docs/navigators/navigation-prop#dispatch-Send-an-action-to-the-router):
...The other navigation functions use dispatch behind the scenes...
Also parameters for NavigationActions.navigate and this.props.navigation.navigate are the same. There should be no difference which one you use. In my opinion, this.props.navigation.navigate is shorter and more readable.
Related
I would like to know if it's possible to change the bottom tab icon dynamically, I mean, I'm interested to change one of the tab icons when an event occurs...
I have read the documentation but couldn't find any related info about it...
The only solution that I can think of is using a global store variable to control it when it's defined in the bottom tab navigation, using a solution similar to what react-navigation docs proposes here.
I would also think of using a global state management API such as Context API (https://reactjs.org/docs/context.html#dynamic-context), redux (https://redux.js.org/tutorials/quick-start), recoil (https://recoiljs.org/docs/introduction/installation/), etc.
and then set the global state variable on event handler, as well as in the ternary operator in the react-navigation example you provided (in the place
of "focused")
I am using componentWillReceiveProps in many places in my application. Now, I have to replace them with either getDerivedStateFromProps() or componentDidUpdate(). First I thought of using getDerivedStateFromProps as it s alternative of componentWillReceiveProps as suggested react-native docs. But some people are highly recommending not to use this method, Instead suggesting to use componentDidUpdate. But for my requirement all new props must be set with the state before render. getDerivedStateFromProps is the best place to do so.
Hence, which one to use between getDerivedStateFromProps and componentDidUpdate?
From the React docs
https://reactjs.org/docs/react-component.html#static-getderivedstatefromprops
getDerivedStateFromProps is invoked right before calling the render method, both on the initial mount and on subsequent updates. It should return an object to update the state, or null to update nothing.
Deriving state leads to verbose code and makes your components
difficult to think about.
Make sure you’re familiar with simpler alternatives:
If you need to perform a side effect (for example, data fetching or an animation) in response to a change in props, use componentDidUpdate lifecycle instead.
If you want to re-compute some data only when a prop changes, use a memoization helper instead.
If you want to “reset” some state when a prop changes, consider either making a component fully controlled or fully uncontrolled with a key instead.
Can it be possible to make dynamic routes in bottom tab navigator of React Navigation.If Possible then how to do that?
As mentioned in the React Navigation docs, it requires you to define routes statically, and there's no officially supported way to define dynamic routes. There are existing workarounds (see the link in my comment under your question), but these workarounds are pretty awkward.
React Navigation 5.0 was announced recently, and it promises to bring dynamic configuration support, which might mean dynamic routes as well.
I came across a bug in a React Native app that makes use of a native view component, and tracked it down to the order of execution of the property settings methods (e.g. #ReactProp methods on Android).
I found that I had to put the prop method that needed setting first as the last prop in the component's JSX declaration, which is a little counter-intuitive.
Is there a way to enforce this order?
Although this doesn't specifically answer the question, one way around this, when specific props are dependent on each other like this, is to bundle them in an object, which on Android would be passed to the native method via a ReadableMap. That way all the dependent data is in one place and can be handled in the correct order.
It's easy to get a reference to navigator in the renderScene function, so calling navigator.push(newRoute) is simple when responding to an event that happens from within the JSX tree.
In my case, though, I want to call navigator.push(newRoute) from an external event. My app signs the user in with Google and fires an event when the sign-in is complete, and I want to navigate to a new route in that case.
How can I get a reference to the navigator? Is there any way to get it besides as a parameter to renderScene?
You can get the navigator through refs property: https://facebook.github.io/react/docs/more-about-refs.html. It's part of react (not specific to react native). It's not obvious from the react-native docs that there is a number of 'react' features that can be used in react-native, so i'd really advise to take a close look at react in general.
Note however, there is a good reason Facebook does not mention refs explicitly and loudly. Refs is really not a "go-to" way of accessing component. Your case might be of course different, but it's likely that the Google sign-up is not in-fact "external". It might actually be part of one of the components in the hierarchy tree above the navigator (in which case you can pass the state change down the tree).
Quoting from the summary of the "More about refs" document above:
If you have not programmed several apps with React, your first
inclination is usually going to be to try to use refs to "make things
happen" in your app. If this is the case, take a moment and think more
critically about where state should be owned in the component
hierarchy. Often, it becomes clear that the proper place to "own" that
state is at a higher level in the hierarchy. Placing the state there
often eliminates any desire to use refs to "make things happen" –
instead, the data flow will usually accomplish your goal.
Again - your case might be different and using refs might be perfectly justified, but if you are tempted (for example) to separate out all the Google-related stuff to separate object and if that makes the sign-up "external" - think twice. React really encourages putting all things related to a "component" logic in one place (the component) - even if that includes various technologies and external APIs.