All language subtitles for 013 Introducing React Context (Context API)_en

[Maximilian Schwarzm�ller] So with useReducer

out of the way,

let's dive into a different problem you might face

in bigger React applications specifically,

but even in this tiny demo here, we already have it,

that can be solved in a more elegant way.

I'm talking about a problem, in quotes,

where you are passing a lot of data

through a lot of components via props.

And a good example here is our isLoggedIn state

and the login functions.

We're managing this state in the app component

because I lifted this state up to that component

because we basically need this state,

this isLoggedIn state and the functions to change it

everywhere in this application.

We use the logged in state in the header

to which I'm passing it through the isAuthenticated prop.

From there, we are able to logout.

So I passed the pointer at the logoutHandler

to my header on the onLogout prop.

And we also need the login state

to render different content here,

either the login or the home component,

and to those components,

I also passed the logoutHandler or the loginHandler.

Now the logoutHandler being passed to the home component,

that's something I'm doing here

so that we theoretically could add a button there

with our button component, for example,

to allow the user to logout there as well.

Not something we need in this app,

but something you could add here with props on logout

since we're getting a pointer to this handler anyways.

And if you do that, once you login here,

you all have the logout button here.

So long story short, we need, or we use this login state

in a lot of different places in the app.

Now, obviously this is a very, very, very simple app,

a very simple demo,

and here passing our state around like this

is not a huge problem.

Now it is quite common that you pass data

to components through props,

but it's always a problem if you forward state

through multiple components.

So if you basically just leverage props to forward data

to another component.

And that's actually something we're doing

in the main header.

Here in the app component,

I'm passing isLoggedIn through the isAuthenticated prop

to main header.

And I'm passing the logoutHandler

through the onLogout prop to the main header as well.

Now in the main header though,

I'm using neither of those two props.

I'm using them only to forward them again

to the navigation component

because it's the navigation component in the end,

which needs the isLoggedIn data

to render different links and which needs the

onLogout prop and the logoutHandler therefore,

to do something when the logout button is clicked.

So essentially what I'm doing here, is in the main header

I'm receiving props,

I'm receiving data through props

which I'm not actually using primarily in the main header.

Instead, I just forward that data.

That's not necessarily a problem,

but in big apps, that chain of forwarding

might become longer and longer.

Consider this example of a fictional app.

We could have an app with an app component,

with, let's say, an auth section,

with a login form,

with a shop section where we have a list of products

in which we render individual product items,

and with a cart.

Now in the login form,

we might have the login event when the user fills

out the form and submits the form,

and we validate the data and find out

that the user is logged in.

And we might need that login data,

So the login status,

the information that the user is logged in

in different parts of the app.

We might need it in the shop.

We might need it in the cart,

to show the cart to avoid that the user can go there

if he or she is not logged in.

It's easy to imagine that we need information

about the login status in different parts of the app.

And we have something similar.

Let's say the user adds a product to the cart.

We need that information in the cart component

to show the product there, for example.

But since the product is a direct child of products,

which is a child of shop, which is a child of app.

And since the login event happens in the login form,

which is a child of auth, which is a child of app,

we don't have those direct connections

to the other components where the data might be needed.

If a user clicks a button in the product component

to add a product to the cart,

the information needs to reach the cart component

but there is no direct connection

between the product component and the cart component.

And the same for the login.

And therefore, what we typically would do is

we would use props to pass a function handler

to the login form, for example,

so that in there we can call it.

But that essentially means

that we're forwarding data through our different components.

And the same, of course, if we add something to the cart.

Now, that means that this function that should be triggered

when the user adds something to the cart

would probably be managed in the app component,

because we lifted the state up to the level

where we have access to both the product component,

indirectly,

and the card component.

And that's only the case in the app component.

Only this component has at least indirect connections

to both components, product, and cart.

And therefore we would forward a pointer

to the add to cart function

through all those other components,

the shop component and the products component,

even though those components probably don't need

that function.

They only need it so that they can forward it

to the product component in the end.

So in the end here,

we have the same problem I described here

just on a larger scale.

Here, it's a very simple app

but even here we are forwarding data

through the main header to the navigation component

on props we receive in the main header

even though we don't really need the data there.

So therefore, in bigger apps,

you could easily build such prop chains,

which are used to forward data through components

to other components.

That's something you can do, and that's not necessarily bad

but the bigger your app gets,

the more inconvenient it is to do that.

Instead, it would be nicer if we could use props

in a component to only receive the data

this component really needs from its parent,

and not to forward our data through the parent

which the parent doesn't ever manage nor need itself.

And for that we got a component-wide,

"behind the scenes", State Storage, built into React.

We have a concept called React Context,

and this then allows us to, for example, trigger a action

in that component-wide State Storage,

and then directly pass that to the component

that is interested without building such a long prop chain.

And that allows us to solve our problem

in a more elegant way here.

So let's take a closer look at this now.