0

I am using Redux and React Navigation in my app where I am making some API calls, I have a question that after successful completion of my redux cycle which lifecycle method of react component I should have to use for navigation to the next screen and why?

  • The user has clicked on the login after putting his credentials on Login Screen.
  • Executed the login redux action and returned a success
  • After success, my Login screen props get changed and I want to redirect to the next screen.
  • In which method I should have to put the navigation code like

this.props.navigation.navigate("DashoardScreen');

When I have gone through the different searches and I found that componentDidUpdate() or shouldComponentUpdate() will be the right method to execute this stuff. Which method should actually I have to consider and why?

Hardik Virani
  • 1,687
  • 7
  • 23
  • 36
Bhagwat K
  • 2,982
  • 2
  • 23
  • 33

3 Answers3

0

You probably want to use componentDidUpdate, because that's the last thing being called when there is an update happened.

On the other hand, shouldComponentUpdate is used to optimize the render frequency of your component, e.g. how do you REACT to the props/state changes by returning true if the update should trigger a rerender or false otherwise.

karlmarxlopez
  • 1,019
  • 1
  • 8
  • 16
0

It normally shouldn’t be called in any lifecycle method, but should be inside your loginHandler(handler for clicking the login button), right after the async login action returned success.

Howard Wu
  • 57
  • 4
  • If that is the case then how I will do UI updates on login such as closing the UI loader? – Bhagwat K Jan 13 '20 at 15:10
  • you can update the state (that control if UI loader should show or close) right after success returned, and before navigate to other screen. if this may cause updating state on unmounted component warning (mostly likely on android sometimes), you can setTimeout of a few mili seconds for navigating to other screen – Howard Wu Jan 13 '20 at 16:59
0

You don't need (and ideally shouldn't) put your navigation logic inside Login component. What if there are multiple login screens? You don't want to copy that navigation code everywhere. What if you will want to put intermediate screens after Login but before navigating to the app? What if you want, under certain conditions, intercept login, e.g. to run some async checks before navigating? If you keep adding this logic inside components it will quickly become a mess

You want to call navigate in your thunk or saga (or any other handler you have) after you are done with logging in. Usually you indeed only access navigation from this.props which is only available in component but that is not the only way to access navigation. To be able to navigate outside of component, use Navigating without the navigation prop

Max
  • 4,473
  • 1
  • 16
  • 18
  • If I have multiple login screens then I will put that code in one helper function and can call that function the same as action. Also, the use of the NavigationService will be a tricky part for me to manage the navigation Stack when the application grows. – Bhagwat K Jan 13 '20 at 15:30
  • Helper function like this has more downsides than may seem. What if you need some parts of redux state to run this logic? Will you just connect all these components with these parts of redux state even though these parts don't directly belong to components? And then update this connection in every component every time something changes? What if your components are unmounted before this function has finished running? I didn't understand last part too, navigating from NavigationService is barely different from navigating from props – Max Jan 13 '20 at 16:31
  • It can be a pure function where you can pass all the data from the component and navigate, also if we are calling this function from particular the component then we can pass state mapped with that component to this function. so only the calling component of the function will be in memory and only that component will update. – Bhagwat K Jan 13 '20 at 17:53