This context feature is aptly named because it allows us to capture and use data that is contextual to a single request. And as I've mentioned, we can use that data really anywhere within our application. We can use it inside of controllers, services, views, but we can also use them inside of any jobs that we might dispatch from a request. And let's look at how we can do that. Now, off screen, I have implemented more of this application. There is this contact us page, and this is only for signed in users, but I want it to be as easy as possible so that all they have to do is type in their message and then send it. They don't have to provide a name, email address, or anything like that because we already have that information. We know who is signed in. We know what's going on. We know what's going on.

We know what's going on. We know what's going on. We know who is signed in. We know what account they currently have active. So I want to pull that information from the context so that all we have to do is get that message, and then we could dispatch a job. So we could do something like this to where we have a ContactUsJob for the lack of a better name, and then we could dispatch that. We could pass in the contactMessage from the request, and that would get us basically everything that we would need. Now, let me back up a second, because if you remember, this idea of a context is, well, it's contextual. We can add whatever data that should be or can be considered a context for a request, and we could make the argument that this message coming from the user is contextual.

We can add whatever data that should be or can be considered a context for a request, and we could make the argument that this message coming from the user is contextual. I mean, it is part of the request, and it is, well, very important. So let me back up a second. So instead of passing the message to the job, we could just add the contact message to the context, and therefore we would have access to that inside of the job. We could go back and forth on whether or not that's really a good idea. I don't really know. I know that in this particular case, it makes a lot of sense to just pass the message to the job. But we could also use the context.

I know that in this particular case, it makes a lot of sense to just pass the message to the job. But we could also use the context. It's really up to you and how you want to approach that. Now, of course, I don't have that job, so let's make it. We'll call it ContactUsJob, and let's open it up. This is going to be a very simple job in that all we are going to do is use the Mail facade to send a new ContactUsNotification to where we will pass in that contactMessage, which means that we need access to that. So here for our constructor, let's just make this easy on ourselves. Let's have public string contactMessage.

So here for our constructor, let's just make this easy on ourselves. Let's have public string contactMessage. That way, we will have this contactMessage property that we would then pass here. That would be it as far as this job is concerned. It's very simple. Let's make sure that this is going to work. Let's import this ContactUsJob class so that that is going to work. I think we're done with the ContactController, so we can close that. For the most part, we're done with our job, but we do need this ContactUsNotification. Now, of course, we're going to need to do two things here. We will first of all need to implement this ContactUsNotification.

Now, of course, we're going to need to do two things here. We will first of all need to implement this ContactUs notification. I think we're done with the job. We can close that. Let's just open up that notification class now. We need to make a few changes here, and then we will create the view for this email. Now, we don't really need to do anything special as far as the to and the from emails. They're going to come from the account manager. Rather, they are going to go to the account manager, and they are going to be from. We'll add a new address. Wow, there's a lot of faker addresses. I could have just typed that out, but why do that? We have our new address where the email address is going to be

I could have just typed that out, but why do that? We have our new address where the email address is going to be Investor Relations. I've just decided that this is an investment portal, and then we will have Investor Relations as the name. It's going to go to the account manager. It's going to come from the Investor Relations, and we'll just change the subject to Contact Us. Now, we do need that contact message, so before we do anything else, let's go ahead and do the same thing here, and then that is going to automatically be passed to our view. So we don't have to do anything there, but let's say that we are going to have a view called Emails Contact, and we want to include other things. Now, of course, we need to know who this message

but let's say that we are going to have a view called EmailsContact, and we want to include other things. Now, of course, we need to know who this message is coming from, so we will need the user information from the context. It also wouldn't hurt to have the account that the user currently has selected. We will include both of those to use inside of the view, so let's use with. Then we will have a user, and we will reach into the context and get the user. We will do the same thing for the account, and let's just make this simple and just call it Account so that inside of our view, we don't have to say ActiveAccount, but in the context, it is known as the ActiveAccount, so we will need to use that key to get that value. But as far as our content, that's really all that we need. We have the user

it is known as the Active Account, so we will need to use that key to get that value. But as far as our content, that's really all that we need. We have the User information, we have the account information, and we have the message that is coming from the form, so we just need to implement our view. So let's go to our Views folder, except that's the wrong Views folder. We need to go down here to Resources, Views, and let's create Emails/contact.blade.php. Is that what we called that? Let's go back, and yes, Emails/contact. So let's get some boilerplate HTML. As far as the title is concerned, we'll just say Contact Us. And then for the body, we don't really need anything special. We'll say Contact Us from User, and then we just need

is concerned, we'll just say ContactUs. And then for the body, we don't really need anything special. We'll say ContactUs from User, and then we just need to include the user information. So we can start with the user, and let's do this. Let's have the userId followed by the userName, because it could be useful to have both of those things. Of course, the ID is really the identifier for the user, because users can have the same name, but the ID will at least give us something to go on if we need to view a log for the user or find records in the database. Now for the account, it's going to be simple. We now have account, because that is what we are passing to the view right there, and we have the ID, and we also have a name property. So that was easy. And then we

account, because that is what we are passing to the view right there, and we have the ID, and we also have a name property. So that was easy. And then we just need our message. So let's just put this inside of a <p> element, and we will include the contact message. I think we should be ready to go. We just need to make all of this work. So let's go to the command line. We want php artisan queue:listen, and we should now be listening for new things. Now this is going to be written to the log, so let's open up laravel.log so that we can see that, and let's do this. Let's open up web.php, because I log other things. Like for anything for the accounts, I'm logging those with that middleware. So let's just do

Let's open up web.php, because I log other things. Like for anything for the accounts, I'm logging those with that middleware. So let's just do this. We don't need to log those requests anymore, so we'll just take that out so that the only thing that we are logging is those emails. So let's go back, and let's just send a message. Hopefully we won't get any errors. It looks like that did okay, so let's take a look at the command line. It ran. It was done. So let's look at the log, and sure enough, we can see we have our email from investor relations to the account manager. The subject contact us, but really the most important thing is down here in the body. So we have the user information, our test user with an ID of 3.

The subject contact us, but really the most important thing is down here in the body. So we have the user information, our test user with an id of 3. We have selected the account with Moe's Hudson. So let's do this. Let's clear that out. Let's select a different account, and let's just go with Kane here. So let's select that one. Let's go to the contact page and another message. If we send that inside of our log, we should see another email. But once again, the most important thing is down here in the body. So of course, the user is the same, and now we can see that the account is Kane. The account id is 75. But you know what? Instead of using the id for the account, let's use the account number because I prefer to do it that way. Now,

is 75. But you know what? Instead of using the id for the account, let's use the accountNumber because I prefer to do it that way. Now, we're going to run this again, but let's just do this. Let's go back to the ContactController, and instead of passing the contactMessage to the Job, which then passes it on down, let's use the context. So we will simply use our context to add, and let's just call it the same thing, contactMessage. But let's do this. Let's make this hidden just to have something a little bit different, and I'm not necessarily sure we would want that to be logged anyway because the message could be rather large. So we're going to add that as hidden. The key is contactMessage, which means that we need to go back to the ContactUsJob so that

could be rather large. So we're going to add that as hidden. The key is contactMessage, which means that we need to go back to the ContactUs job so that we can take out the contactMessage property. We don't need to pass that to the notification because inside of the notification, we will grab that information from the context. So once again here, we will take that out of the constructor, and then when it comes time to pass that information, we will have our contactMessage, and we are going to pull that from our context. But this was hidden, so we will call the getHidden method. The key was contactMessage, and now let's run that again. So let's go back to the accounts. Let's select something different like Abigail. Let's go to the ContactUs and say this message is in the context.

run that again. So let's go back to the accounts. Let's select something different like Abigail. Let's go to the contact us and say this message is in the context. Before I send this though, let's go to the log. Let's clear that out so that we can easily read it. Let's send the message. We don't receive any errors. If we take a look at the console, we can see that there was no errors as well, so everything should be good. The log though is really the place we should have checked to begin with, but here we can see the user information, the account information, and now we are using the account number as opposed to the account ID, and we can see that the message is different. The message is in the context. Now of course, because this is being written to the log, we also have all of the contextual information that is not hidden written for this log.

The message is in the context. Now of course, because this is being written to the log, we also have all of the contextual information that is not hidden written for this log entry. So the context is a fantastic feature. It allows us to capture contextual information for a request. We can use that data anywhere, literally anywhere within our application, our controllers, our services, our views, our jobs, anything, and that's awesome.