Forem: anjushaKhandavalli

Auto setup remote branch with push.autoSetupRemote

anjushaKhandavalli — Wed, 21 Dec 2022 04:28:19 +0000

Whenever you create a new branch and trying to push the new commit then you will start seeing this error:

After this we often run:
git push — set-upstream origin <branch-name>

To get rid of doing this every time, git from version 2.37.0 gave us a configuration field called “push.autoSetupRemote” . More about this on git words :-)

push.autoSetupRemote

If set to “true” assume --set-upstream on default push when no upstream tracking exists for the current branch; this option takes effect with push.default options simple, upstream, and current. It is useful if by default you want new branches to be pushed to the default remote (like the behavior of push.default=current) and you also want the upstream tracking to be set. Workflows most likely to benefit from this option are simple central workflows where all branches are expected to have the same name on the remote.

In simple words to push the current branch and set the remote as upstream automatically every time you push, setting push.autoSetupRemote to true in git config once, is enough.

To do this just run this command in terminal:

git config --global --add --bool push.autoSetupRemote true

Then git push will automatically setup the remote branch.

Note: The --global flag means this will apply to all git commands on your machine (regardless of which repo it is), you can omit the flag to make it specific to a single repo on your machine.

Findings while upgrading React Navigation from 4.x to 5.x(Part-2)

anjushaKhandavalli — Wed, 05 Aug 2020 10:52:53 +0000

In Findings while upgrading React Navigation from 4.x to 5.x (Part-1) I explained a few findings our team had while upgrading React Navigation from 4.x to 5.x. In this part-2, I will share few more findings.

getParam:

Till React navigation 4.x we have used the getParam to set a fallback value of a param whenever the param is undefined. For ex:

If params is undefined this fails. To get rid of this we used getParam so that whenever the accessed param is undefined it will fallback to the default value that we pass as part of the getParam as follows:

so now if name or params are undefined, fallback sets the value to ram.

But now in 5.x there is no getParam to achieve this. Still we can achieve the same thing by using the optional chaining and null coalescing operators as:

Passing additional props to the screen:

In React Navigation 5.x specifying the screen in navigator will be like:

If we need to pass props to screens then inlining components as below is not preferred:

This is preferred:

Tab bar visibility control:

In version 4.x hiding the tab bar for specific screens can be achieved by setting tabBarVisible prop to either true or false as part of the Options for screens.

But in version 5.x hiding tab bar using tabBarVisible prop is not recommended as it is causing some glitches. So now this can be achieved by nesting the tab navigator inside the first screen of the stack instead of nesting stack inside tab navigator.

For example let’s say we have Home, Feed, Notifications, as three tabs and Profile ,Settings are the screens inside Home tab. So for this the structure will look like:

So now if you don’t want the tab bar to be visible for Profile and Settings screens then this can be achieved by nesting the tab navigator inside the first screen of the stack as follows:

Done now you won’t see tab bar for Profile and Settings without any usage of tabBarVisible prop.

Nested navigation with initial route:

By default, when you navigate a screen in the nested navigator, the specified screen is used as the initial screen and the initial route prop on the navigator is ignored. This behaviour is different from the React Navigation 4.

If you need to render the initial route specified in the navigator, you can disable the behaviour of using the specified screen as the initial screen by setting initial: false:

Hope this article helps you to figure out some of the issues while upgrading from React Navigation v4.x to 5.x. Happy Upgrade!

Findings while upgrading React Navigation from 4.x to 5.x (Part-1)

anjushaKhandavalli — Tue, 21 Jul 2020 17:41:47 +0000

As part of refactoring and upgrading the code-base, our team decided to upgrade the React navigation version from 4.x to 5.x. Now this 5.x has completely new API, so the old code using React navigation 4.x will no longer work with this version. Moving the entire code-base navigation version to 5.x can be a lot of work.

To achieve this we have used the compat library, So that we can reuse code using the version 4.x with minimal changes. Then slowly started moving each navigator to the version 5.x. As part of this we started a round of testing to see if everything works fine but surprisingly we encountered few problems which are not described in official documents. So, we took a deep dive and see what causes the problem and here are a few findings:

navigation.state is undefined in v5:

In React Navigation 4.x, the navigation prop has various helper methods as well as the current screen's state.But In 5.x, the navigation prop splitted into 2 props: navigation and route. navigation prop contains helper methods such as navigate, goBack etc., and route prop contains the current screen's data which we previously accessed via navigation.state.

In version 4.x:

In version 5.x:

Header null not allowed:

Header is a React Element or a function which is part of the navigationOptions that is used to configure the header (Also known as navigation header i.e the rectangle at the top of the screen). If you want the header to be null

In version 4.x we can specify it as:

But in version 5.x If we specify it as null causing crashes. So In 5.x it should be a function that returns an empty component:

navigationOptions -headerLeft, headerRight, headerTitle should be function:

In React Navigation 4.x these navigationOptions can be a element as follows:

But in 5.x if we are specifying any of these navigationOptions as a element then they are causing the crashes. So we finally fixed this problem by specifying these navigationOptions as a function that returns a React element as follows:

Finding routeName in v5:

In React Navigation 4.x routeName is part of the navigation prop and that can be accessed as:

But in 5.x routeName is now part of the route prop and that is renamed to name which can be accessed as:

Navigating to a screen in a nested navigator:

The difference is that in the previous versions, all configuration was static, so React Navigation could statically find the list of all the navigators and their screens by recursing into nested configurations. But with dynamic configuration, React Navigation doesn’t know which screens are available and where until the navigator containing the screen renders. Normally, a screen doesn’t render its contents until you navigate to it, so the configuration of navigators which haven’t rendered is not yet available. This makes it necessary to specify the hierarchy you’re navigating to. This is also why you should have as little nesting of navigators as possible to keep your code simpler.

In 4.x all the navigation configurations were static. So React navigation can find the specified screen by recursing the list of all navigators and their screens in nested configurations.

For example lets take the following in which SettingsNavigator is nested inside ProfileNavigator ( To show how nested navigation works I am using the navigator configuration in 4.x version)

So, to navigate to the EditProfileScreen in 4.x navigate will look like :

But with dynamic configuration in 5.x, React navigation doesn’t know which screens are available and where until the navigator containing the screen renders. Normally a screen doesn’t render its contents until you navigate to it, so the configuration of navigators which haven’t rendered is not yet available. This makes it necessary to specify the hierarchy you’re navigating to. So to navigate to the EditProfileScreen we have to do as follows:

These are the few findings that our team has while upgrading React Navigation from 4.x to 5.x and which are not described much in documentation. I will continue to add few more findings in part-2. Thanks for reading.