So, you want to learn about contexts. I can't blame you, because if you've looked at the documentation, it's very clear as to how to use contexts. It's not very clear as to why you would want to use contexts, or really what context is. And, you know, when I think of context, or at least the concept of it, it's a lot like a session. In fact, you can think of it as a session for an individual request. So, what is a session? It is a centralized data store that we can put stuff, and then we can access that stuff throughout the entire application. So, a context is the same thing, except that it is for an individual request. So, it's a centralized data store that we can put stuff in. We can access that stuff throughout our entire application, but only for a single request.

So, it's a centralized data store that we can put stuff in. We can access that stuff throughout our entire application, but only for a single request. So, whatever stuff we put in the context is going to be completely forgotten for another request. And that's fine, because that gives us really all that we need to do really a lot of things. And this is one of those features that you might scratch your head and think, why would I want to use that? But I guarantee you, you will want to use contexts. So, I have a little application that we could think of it like an investment portal. So, a User would sign in. They might have multiple investment accounts.

So, a User would sign in. They might have multiple investment accounts. So, they would go to the accounts page, and then they would want to see the information for a particular account. So, they would set that account as active, and then they could go and look at the data for that account. It is basic stuff. I mean, if you've built any kind of application for investments or things like that, this is normal. So, of course, that means we need to be tracking what account a User has selected. So, if we look at the AuthenticatedSessionController, when a User signs in, we authenticate them. We regenerate the session. We get the default account.

We regenerate the session. We get the default account. Really, the important part is we store that default account inside of our session as the active account, so that we can start to access that whenever we need to, like inside of the AccountController. Because the index method is, well, it's responsible for this page. It is for listing all of our accounts so that we can select whichever account we wanted as the active account. So, for that to work, we fetch all of the accounts for the given User. We get the active account from the session, and then we pass those pieces to the view as the model. So, if we take a look inside of the index.blade.php view, really the important part is this right here, where we check if the ID of the active account is the same as the account that we are iterating on right now,

So, if we take a look inside of the index view, really the important part is this right here, where we check if the ID of the active account is the same as the account that we are iterating on right now, because we are inside of a foreach for our accounts. And if it is the active account, then we just say, hey, this is the active account. Otherwise, we present them with a button so that they can set the active account. So, it's very basic. And, of course, if we go back to the controller, the code for setting the active account is very simple. We get the active account ID from the request. We make sure that we have an account for that given user for that given account. And if so, then we set that account as the new active account in the session.

We make sure that we have an account for that given user for that given account. And if so, then we set that account as the new active account in the session. So, easy stuff. So, what we're going to do is look at how we can use the context, kind of get an idea of why we would want to use that. And we will also look at the built-in logging feature. In fact, let's just start with that. So, whenever a user sets the active account, I want that to be in the log so that I can track the user's movements. This user selected this account so that they could start looking at that information.

I want that to be in the log so that I can track the user's movements. This user selected this account so that they could start looking at that information. So, what we could do to make that happen is, of course, we could log it. We can make this info in that user changed account. And then we could supply the userId, because without the userId, it's kind of pointless. So, we can get the user from the request and get that ID. And then we could say the accountId is, well, we could do a couple of things. We could fetch the account here. And actually, let's do this inside of here so that we are only logging it when the account is changed. So, here we could just use our accountId variable, and that's going to be fine.

And actually, let's do this inside of here so that we are only logging it when the account is changed. So, here we could just use our accountId variable, and that's going to be fine. We, of course, need to load up the log. So, let's do that. Let's delete all of that stuff so that we have a clean log. And whenever we, well, whenever we try to select an active account, object of type setActiveAccountRequest is not callable. And, of course, it's not because I did that. Okay, so with that done, let's clear out the log because now our log looks like that. And let's go back.

Okay, so with that done, let's clear out the log because now our log looks like that. And let's go back. Let's set one as active. And here we can see that the User changed the account. The User ID was 3. The account ID was 10. That's great. Except that we don't necessarily have to be explicit as to what we include with the log because anything that we add to the context is going to automatically be added to the log whenever we log something within that given request.

because anything that we add to the context is going to automatically be added to the log whenever we log something within that given request. So, let's look at what that looks like. Before we write to the log, we are going to use our Context facade. And we will call the add method. And we just want to add the accountId. And we will just use the accountId variable just like we did whenever we were logging it, except that now it is going to automatically be added to our log. So, let's clear out the log once again. And let's set one of these as active.

So, let's clear out the log once again. And let's set one of these as active. So, now we will still have the same information, but it's going to look a little bit different. So, here we can see that the user changed the account. The userId is 3. That is, of course, the user we are signed in with. But now there's this metadata or this contextual data that goes along with this particular request. And we can see that the accountId was 7. Except I guess we don't really want to use that variable because that's technically a string, isn't it? So, let's do this.

Except I guess we don't really want to use that variable because that's technically a string, isn't it? So, let's do this. We will just use our account variable then ID so that now we can see that it is an actual numeric value. Yes, there we go. So, anything that we add to the context by default is going to appear within the log. Now, we can get around that by essentially using a hidden key or a hidden value. So, let's look at what that looks like. Back inside of our controller, let's log some information here. But in this particular case, we're just going to say user viewed accounts. We don't have a request object here, but, you know what, let's use the auth facade.

But in this particular case, we're just going to say User viewed accounts. We don't have a request object here, but, you know what, let's use the auth facade. But now let's do this. Instead of getting our active account from the session and passing that as part of the model to the view, let's add this to the context so that it will look like this. We will have context, but instead of calling add, we're going to call the addHidden method. This is essentially adding a hidden value. It's still there in the context, but it is hidden from the log. So, it won't appear inside of the log, which in this particular case, yeah, we don't want to do that. But we'll do the same thing.

So, it won't appear inside of the log, which in this particular case, yeah, we don't want to do that. But we'll do the same thing. We will have this activeAccount that we can then access inside of our view. Even though it is not being passed as part of the model, we just need to access the context here. So, we will use our context. And because the activeAccount is hidden, we will call the getHidden method. We will use the same key, activeAccount. Then we will get that ID and compare it to the ID that is being iterated on. So, now inside of the browser, we will see the same behavior that we saw before. So, we can change our activeAccounts, and that's great.

So, now inside of the browser, we will see the same behavior that we saw before. So, we can change our active accounts, and that's great. But if we look at the log, we are going to see, well, I shouldn't have done that so many times. But if we scroll down to the bottom, we can see that the user changed the account. And we can see, of course, that the new account id is being included. But if we look at the entries for viewing the accounts, we can see that the user id is still included. But now the account id or the account information is not. So, we can use the context strictly as a centralized data store for an individual request. Or we can use it as a centralized data store for a request with the added benefit of logging all of the contextual information with that request. But this particular example is kind of contrived.

Or we can use it as a centralized data store for a request with the added benefit of logging all of the contextual information with that request. But this particular example is kind of contrived. It's really not a great example. So, in the next episode, we will look at how you would really want to use the context in your application. I like it. I love it. I want some more of it. Yeah. All right.

All right.