Repeating ourselves over and over again and setting the same difficult look over and over again is really
annoying and definitely not what we want.
Well, thus far we always worked with navigation options, which we set up right next to our components.
Now, you don't need to do that for settings, default settings, which you repeat over and over again,
let's actually remove this setting here from the category ML screen and only keep the Hattar title there,
because the header title, of course, depends on this screen and changes with the different values
we get in the screen.
Let's see if we remove the platform import and the color is constant import at the same on categories
screen there.
I will cut this so that I can still use it, but I will also remove it therefore from this screen and
only keep the header title here, which is specific to this screen and not the default for all screens.
So I'll keep that here and I can therefore also get rid of the platform important the color constant
import here as well.
And now let's go to the Meals Navigator, because besides setting up navigation options right next to
your components, which is the right place for any options that are specific to that component, you
can also set up options here directly on your navigator.
You got two different places where you can set them up.
One place is when you're using this more complex screen configuration here.
When you map a screen to your identifiers besides setting up the screen, what you want to load, which
is the must have value you have here, you can also add navigation options here and set up some navigation
options for this screen here.
So there we could also add the header style, the header tint color, and now we just need to add the
platform and the colors import here.
So let's quickly do that.
Let's import platform from react native here and let's also import Koller's from.
Constance Koller's.
And if we do that, what you'll see is that on the categories screen, we have no color because I only
set this coloring here on the category, Milt.
But if you go to that screen, therefore we have that coloring, so we have that same look we had before,
and now, of course, we could do the same here for the categories screen.
So there we can also now turn this into an object, hence add the navigation options and add the exact
same options.
So this same object here for this screen.
Now, if we do that, we also have to color back on the categories screen.
Now, the small advantage compared to the previous solution of setting this up in each component file.
Instead, we now at least have all the configuration in one of the same file.
Still, we're repeating ourselves.
So it's nice that you can set this up here.
And for example, this would be a good alternative to setting up our statically set header title for
a category's screen meal categories so we could set this up here instead of in the component because
it's static anyways.
Doesn't really matter where we set this up.
But besides, such a use case does isn't really an improvement because we still repeat ourselves.
So all again, cut this from here and instead we can now take advantage of a second argument you can
pass to create Stack Navigator.
The first argument is the object with your screens.
The second argument allows you to configure that navigator.
We haven't set up any configuration dairy yet and of course in the official box or as I get it here
by my idee, you find a list of all the settings you can set up there.
One important thing you can configure here are the default navigation options.
And as the name implies, this allows you to set up options that apply to every screen.
Now, this takes object with your navigation options, but now these options will be applied to every
screen in this navigator.
So to all three screens here so that you don't have to repeat yourself.
So now if you do that, you see that color header here, also here and also on the detailed screen if
you go there.
So now this is, of course, how you want to set up repeating configurations like the general style,
which typically doesn't change from screen to screen.
If it does change, that's fine.
You can set it up on a per component basis or here in the screen config, as I showed you.
But if it doesn't change, you can use default navigation options here.
Now, of course, this also brings up another question.
How are the settings set up here or here, merged with the settings here or inside of a component?
And the rule is very simple.
Their default navigation options get merged with your specific navigation options set up here or here
in the component.
And the specific options always win if you have one and the same key of the same name.
So if I would set up a default header title here, like a screen, which is of course very generic,
then you would still see middle categories here, Italian here.
But on the detailed screen where I said no specific header title, you would see a screen.
So your default navigation options are overridden.
Now, if you set up navigation options here, when you configure the screen and instead of the component,
they act on the same level and the settings here on the screen level actually win.
So if I said header title two categories with multiple exclamation marks here you see that here on the
categories screen and the title you set up in the categories screen component does not win.
Might be a bit counterintuitive, but this is how it is.
So if you set up.
Navigational options with the same title or with the same names here in the screen config than the screen
config wins, but no matter where you set it up, it always wins against default navigation options
if you use the same title.
So therefore, here, I'll also get rid of the navigation options on my category's screen, I don't
need that here.
I'm happy with setting this up, directing the screen component, but you could set it up in both places.
It's important that you always remember that default options are overridden, though.
Now, besides the default navigation options in this second object, which you pass to create a tech
navigator, you can also configure other things.
If you had control in space, you should see a list here or alternatively, consult the official docs.
Of course, now, typically, the defaults are just fine.
But there, for example, you can set up the mode and you could set this to model default as card.
If you said this, you'll get a mode like transition for loading a new screen, which means the screen
slides in from the bottom instead of using the normal animation on Android, you don't see a difference,
but on iOS you will.
That's just one thing you can change here to change the default animation in case you want a modal transition
instead of the normal push pop animation here.
You can also change the initial Routt name by default, I mentioned it would be the first key value
pair, but if you don't want to start on the categories screen, but for some reason on the detailed
screen, you could simply point at Mial detail here instead of categories which you don't need to set
up because it's a default and you would start on that screen as your starting screen.
Of course, you can't go back now because it's your initial screen, the only screen in the stack they
offer.
So going back won't work.
Now, again, I'll reset those two categories, and you don't need to add this because this is sort
of a default anyways.
It uses the first key value pair by default.
So with that, we had a brief look at some options you can configure and most importantly at navigation
options and devilled navigation options, which is super important to build nice looking and efficient
applications without repeating yourselves over and over again, which you, of course, don't want.
Speaking of efficiency, there is one other thing you want to do when working with react navigation
or you want to consider.
And that is that you installed one extra package, which is react native screens, which in XPO apps
should be included by default, but still it doesn't hurt to explicitly install it, which allows you
to actually ensure that under the hood.
React Navigation uses native optimised screen components provided by Android and iOS on Android, it
uses defragment defragment in case you're into Android development a bit and on issues, it uses the
UI view controller and that simply improves performance a little bit more here in this simple app.
You won't feel it, but it's good practice to use this special package or these special screens.
Now, to use that, you should go to a place that runs before you render your first screen, which is
the app charges filed in our case here and there.
You can now import use screens from react native screen.
So from this package you just installed and simply called that after your imports, before you do anything
else.
So before you render any JASE'S code.
Now important, if you're using the latest version of Expo and react native, which you most likely
are, this is no longer use screens but an able screens.
You still call it like this.
It's just a different name and that's the only change we need to make here.
Dismal assembly behind the scenes unlock D screens and you won't see a difference in this app, but
it's a little bit more performant.
So it is something I would recommend doing, especially in larger applications.
Again, here, you don't really see a difference, but behind the scenes, does this now a bit more
efficient?