All language subtitles for 017 Building & Using a Custom Context Provider Component_en

Now a little enhancement to our context.

It is a good idea to also add your functions

like onLogout in my case to the default context

when you create a context.

And there you can just store a dummy function

which does nothing.

I'm doing this for better IDE auto-completion.

Because you will see that if I don't have this here

in the Navigation component,

here if I try to call onLogout,

I'm not getting any suggestion by my IDE.

It doesn't know that there is a onLogout prop.

On the upper hand you will see

that there is this isLoggedIn suggestion.

Now that's simply happening because the way React works

and the way Visual Studio Code at least works.

It's looking at this default context object

to find out what you are able to access on your context.

So for better IDE auto-completion,

it is a good idea to add onLogout here

in your default context object as well

just with a dummy function

because we're not going to use this anyways.

And then here you will see that now

I get to this onLogout auto-completion.

So that's just a tiny hint you might consider

because it can be helpful.

Another thing that you might consider

is depending on your application structure

and how you're managing your data,

you also might want to pull more logic

out of for example App component

and create a separate Context Management component

if you wanna call it like this.

How could this look like?

Well, maybe in our AuthContext store file,

we could create a AuthContexProvider component now actually

where we return AuthContext.Provider

and we accept props and simply pass whatever we got

on props.children between our provider.

And then here I don't just export AuthContext

as the default, but I also export my AuthContextProvider

in addition to the default as a named export.

Now, why am I doing that?

Because now we can actually also import useState here

inside of the auth-context.js file,

and manage the isLoggedIn state and setIsLoggedIn here

inside auth this AuthContextProvider,

add the logoutHandler function here

where setIsLoggedIn to false,

and also add the loginHandler function here now

so that we manage the entire authentication state

in this separate provider component.

And here I set IsLoggedIn to true of course.

And then I set the value here of course

to an object where I have isLoggedIn,

which is equal to the isLoggedIn state

where I have onLogout

which points at the logoutHandler.

And in addition where we now also have onLogin

which points at the loginHandler

and therefore, I will also add this

to my default context here onLogin with a dummy function,

just making it clear

that we there want the email and a password.

We're not doing anything with that data

but technically we would need it in a real app.

And now we have this standalone file

which manages the entire login state

in this AuthContextProvider component.

And which also sets up all the context.

And the advantage here could be, and I'm saying could

because this is something you can consider.

It always depends on your preferences,

the exact useCase, and the size of your app.

But this is something you could consider

because now we can strip that all out of App component.

We of course also though need to move over

our local storage access here.

So, clear data in the logoutHandler,

set our data in the loginHandler,

and of course also add our useEffect code here

that all now needs to go into our AuthContextProvider,

and therefore we also need to import useEffect here.

But with that all we can now clear all that logic here

from the App component, remove these hook imports here,

remove our AuthContext import here, remove all of that.

And therefore of course, bring back React Fragment

like this, and I'm doing this

because now we can wrap the App component as a whole.

So therefore an index component

which is where we rendered the app component

with AuthContext provider.

So with our AuthContextProvider component

which we just created an exported in the auth-context file,

and with that we have one central place

for the state management

for the off state management, I should say.

And that central place is now not the App component

but a dedicated context component

and a dedicated context file.

And this might be a structure you might prefer

because it is more focused

and gives you a leaner app component

which now is not concerned with app wide state management

but which now instead can just focus on

well, bringing something onto the screen.

Of course, since I'm using isLoggedIn here

I need to be able to get that information.

So now in the App component we wanna use useContext,

and pass our AuthContext, not the provider

but still the AuthContext object

which is our default export in the AuthContext file.

And therefore, we now got our context here as well

and hence we can access it here.

And now we could even remove the onLogin

and onLog out props here

because we're not managing the log out and log in handlers

and App component anyways,

and now tap into contexts in the Home and Login components.

So in the Home component we can also import useContext

and get access to our AuthContext

maybe to mix up the naming and make it clear what's in there

to which context we're listing here

by importing AuthContext and passing it to useContext.

Again, use AuthContext here not the provider.

And then here we can use authCtx.onLogout

and do something similar in the Login component.

Import useContext here,

and then in our component function

maybe here we can set up our AuthContext

by calling useContext and passing AuthContext to it.

For that make sure you are importing AuthContext of course.

And then we can use AuthContext when we need to log in.

So here it's not props onLogin, but authCtx.onLogin

to which we forward the email and password.

Now again, this is totally optional.

The advantage here could just be

that you have a leaner app component

which again is now just focused on returning JSX

and bringing something onto the screen.

And you have to actual off state management

and auth-context management all in one file.

And some developers including myself

often prefer this more focused and separated approach

where you have components,

where every component has one job essentially

and not a ton of jobs.

And therefore I'm a fan of this split,

but as often it's not the only way of doing this

and it's also not the only correct way.

It's definitely a practice that is worth looking into

though, a practice you might see in projects out there,

and therefore something that of course needs to go

into a course like this,

which has the job of turning you

into a real React developer.

And therefore you have to know patterns like this

which is why we refactored this.

With all of that out of the way

let's test our application to ensure that this still works.

And that all seems to work to me here.

Let's also check the Logout button here.

Yeah, that all works.

Now with one central context

with one central state management.