So, in the previous episode, we talked about the context. Of course, we talked about the context. We talked about what the context is. It's a centralized data store for an individual request. And we talked about the basics of how to use the context. We didn't really talk about why, which we need to talk about why. And we didn't really talk about the best way of loading data into the context. I mean, yeah, we did that inside of the controller, but the controller isn't the best place to do that. Because that would mean inside of every controller method, we would have to load essentially

do that. Because that would mean inside of every controller method, we would have to load essentially the same data into the context. And that's tedious. We don't want to do that. So before we get into that, let's talk about the why. Why would you want to use the context? And let me put it like this. So the concept of this application is that a User will sign in, they will go and select whatever account that they want to view, and then they would view the information for that

So the concept of this application is that a User will sign in, they will go and select whatever account that they want to view, and then they would view the information for that account. So that means I need to keep track of that active account so that whenever they go to a different page to show the financials or whatever, I have the account information so that I can pull whatever I need and display that to the User. Now, yes, I have that with this session. But there are some issues with the session because it is, well, the data doesn't exist in memory. It resides in the database or a file or a Redis cache or something.

in memory. It resides in the database or a file or a Redis cache or something. So our application is going to have to fetch that information from whatever is storing the session so that we can work with it. Now, Laravel does a very good job of caching session information. It makes it very efficient. But nothing is as efficient as memory. And that is what the context is. It is a data store in memory. So anything we put inside of the context is going to be stored in memory.

It is a data store in memory. So anything we put inside of the context is going to be stored in memory. And we can access that data throughout our entire application. So in the case of our accounts, whatever the $user has selected as the active account, I want to be able to use that data inside of a controller, inside of a service, and inside of a view. Throughout our entire application. And the context makes that very easy to do. Like, for example, I want to display the name of the account when the user signs in. Right here inside of the dashboard, you're logged in.

Like, for example, I want to display the name of the account when the User signs in. Right here inside of the dashboard, you're logged in. Great. And I would like to say end viewing and have that account information. Now, of course, we could go to that route. And we could very easily pull that out of the session and then pass that to the view or something along those lines. But if it's in the context, all we really need to do is use the context facade inside of the dashboard view to get that information. But we need to load that data inside of the context.

of the dashboard view to get that information. But we need to load that data inside of the context. And really the best place to do that is with middleware. So let's make some middleware called AddContext. And we're not going to be, you know, checking if a User has access to do something or anything like that. The purpose of this middleware is to just load data into the context. So that's here. We will have the context facade. We will call the add method.

We will have the context facade. We will call the add method. And you know, we would need to make the decision, do we want this information to be logged into our log or do we want it to be hidden? I'm not going to worry about that particular decision here. I'm just going to choose add because it's easier to type. So we are going to add the activeAccount and that data is going to come from the session. So we are essentially taking it from the session and putting it inside of the context to make it easily accessible. But you know what?

it easily accessible. But you know what? There's something else that we typically always need access to. And that is the signed in user. So we could do that as well. Let's use the Auth facade. Let's call user. So now we have the active account as well as the user object in the context. Now let's step back. You know, I've mentioned that the context is a memory data storage.

Now let's step back. You know, I've mentioned that the context is a memory data storage. That's what it is. So because it is memory, we have to be very careful as to what we put in the context. It's very easy to get into that mindset of, I'm just going to put it there and we do that. But just be aware this consumes memory. And if you have an application that's being used by hundreds and thousands, maybe even millions of people, then yeah. So just be aware. If you can get away with storing smaller pieces of information, like if all you need is the

So just be aware. If you can get away with storing smaller pieces of information, like if all you need is the accountId, then you know, just store the accountId. But in this particular case, the account and the user objects are very small. So I'm not concerned about that. Now one thing we can do here is we can simplify this. We have two statements. We can combine these into one by just calling the add method once and then passing in an array where the keys are, of course, the keys of the data that we want inside of the context. And then the values are, well, of course, the values for those keys.

array where the keys are, of course, the keys of the data that we want inside of the context. And then the values are, well, of course, the values for those keys. So here we still have the active account and the user keys, except that now we are just passing an array instead of calling the add method multiple times. Now that we have this middleware, we just need to apply that and we can do that right here. So all of the routes for the auth middleware are all grouped together. So that means the dashboard is here, the profiles, which I haven't done anything with, but also the account stuff, all of that is here as well. So for our middleware, we of course want to use auth, but here we can also say add context.

the account stuff, all of that is here as well. So for our middleware, we of course want to use auth, but here we can also say addContext. So now our context is being populated for every request that we make for these routes. And that means we can go to the dashboard view and right here where we tell the user that they are logged in, which hopefully that they would know that, we can say and viewing the account of, and then we will use the context facade, we'll call get because we used the add method here, not addHidden. So we will just call get. We want the active account and we want the name of that account. So now inside of the browser, we see that the account's name is Abigail Shone.

We want the active account and we want the name of that account. So now inside of the browser, we see that the account's name is Abigail Shone. I don't know. I butchered that. I know I did. But if we change this to something else that I can pronounce, like Mr. Maurice. So let's set that as active. We can go back to dashboard and there it is. We didn't have to modify anything as far as that route is concerned. Of course we could have.

We didn't have to modify anything as far as that route is concerned. Of course we could have. We could have used the context inside of this route to get the object and then we could have passed that object as the model to the view. But you know, there was really no reason to do that. I think that this is perfectly acceptable. So now though, we can close that. We can go back to our AccountController and we can change our index method. Now that we have our active account in the context, we don't need to add that here. We can get rid of that.

Now that we have our active account in the context, we don't need to add that here. We can get rid of that. Now it is going to log this. So let's get rid of that. We don't really need to log that we are viewing accounts here. But we do need to change this index view because our active account is not a hidden value. It is just a normal value. So we will still retrieve that. Let's do a sanity check and make sure that our accounts page still works. Let's set something else as active.

Let's do a sanity check and make sure that our accounts page still works. Let's set something else as active. Okay, that is still working. Let's go back to our AccountController. Now we don't really need this line here where we are adding the account ID to the context. That was just for an example purpose. There's really no reason to do that here because we're not going to use that data really anywhere else in this request. So we'll just take that out. We could though add that here as part of the log because I still want that information.

So we'll just take that out. We could though add that here as part of the log because I still want that information logged but it just makes more sense to do it this way. Everything else should be fine. So we're good to go. Now one thing we could do if we wanted to is instead of getting the user from the request, we could use the context to get the user. I don't really know if that gains us anything but let's go ahead. Let's do that. We have it available so we might as well do it.

Let's do that. We have it available so we might as well do it. Well that ends up being more things to type. Oh well, it works. So we're still going to keep that but I say it works. Let's make sure that it, yeah, it works. Of course it does. But you know what? Something else that we can do right up here, this testUser. Now that we have the User in the context, we can change that.

Something else that we can do right up here, this test User. Now that we have the User in the context, we can change that. What view is that? Let's go to the layouts, navigation I believe. Somewhere the Auth facade is being used, right there, auth()->user()->name. We can use the context to get the User and then display the name because now that is available in the context and the username is still there. So as I mentioned before, once you realize that the context is there so that you can store request contextual information and you can access that information throughout the entire application, then it starts to make sense as to why you would want to use.

store request contextual information and you can access that information throughout the entire application, then it starts to make sense as to why you would want to use the context. Now I don't mean to imply you would want to use it for everything and in fact you don't because remember, it uses memory. Anything you store in the context is consuming memory. So don't go overboard, don't go wild, but store the things that you would need regular and repeated access to because really that is the most efficient way to work with that data.

data.