All right, so at this point we've learned how to register our route and then load a corresponding view in response to that. But what about situations where you need to pass data to that view? Well, here's how. If we're using the rot view syntax, we send it through as the third parameter like this. I will pass through an array where each key represents a variable that will be extracted into that view.

where each key represents a variable that will be extracted into that view. So if we did something like the typical or obligatory, hello world, uh, greeting, we might do something like this. Alright, so now the variable will be greeting. Let's open our welcome view and we will echo out the greeting as you've learned right here. All right, let's have a look In the browser,

as you've learned right here. All right, let's have a look In the browser, we visit our homepage and sure enough, we are passing data to our view. Just to prove it to you. Let's return to the routes file and say, what is, uh, Lyrica folks? And if I spell that correctly, alright, now if I come back and refresh, yep, it's working. So why don't we tweak this greeting will be hello. And then the person, um, will be

So why don't we tweak this greeting will be hello. And then the person, um, will be John or something like that. Okay? So now within our view, we will have access to a greeting variable and a person variable. And we can do something like this greeting comma person. All right, let's come back, give it refresh. And now we get Hello John. Okay, but now what about situations where maybe, uh, the,

And now we get Hello John. Okay, but now what about situations where maybe, uh, the, the name or the person should be passed through the query string, right? Maybe something like this person equals Frank. Well, maybe for our demo, it would be cool if we could read that and then echo it. Well, let's do that. If I come back, let's return to our routes file, and now the person is going

If I come back, let's return to our routes file, and now the person is going to come from the request or the query string. We can access the query string by doing request, and we just reference the name. So in this case, it's called person. Okay? So now if I come back and give it a refresh, sure enough, we are reading that value from the query string and then sending it to the view. Let's change it to Sarah and now it says, hello Sarah.

and then sending it to the view. Let's change it to Sarah and now it says, hello Sarah. Very cool. So now in addition to this, we get some security outta the box. If you've ever built a traditional PHP app, this is actually a little bit dangerous. And here's what I mean. If I were to come back, uh, let's fix that. If I were to go into my view and not use blade syntax, but instead a traditional PHP syntax,

If I were to go into my view and not use blade syntax, but instead a traditional PHP syntax, Well yes, that's still going to work. We get the same thing. However, we don't have any protection in place, which means if I were to update this query string, let's swap this out with a script tag that maybe alerts, uh, yo something like that. Now, even though we didn't explicitly trigger the alert, the user still sees one

Now, even though we didn't explicitly trigger the alert, the user still sees one because of this vulnerability, right? And this is PHP 1 0 1 stuff. So that's why we either have to use a filter or something like HTML's special, uh, special charge, right? Uh, to get around that issue. However, when we use Blade, it does it for us automatically. So I can say person with the assurance that I have instant protection, as you see right here,

So I can say person with the assurance that I have instant protection, as you see right here, this is exactly what we want. However, there are situations where you don't want this. Uh, you actually, uh, trust whatever data you are echoing, in which case you can use brace, uh, double exclamation. So now this will echo it, but not, uh, perform any escaping. So we'll get the exact same issue as we had before, which means it's not a good choice in this case. But yeah, there are situations where you trust the, uh,

before, which means it's not a good choice in this case. But yeah, there are situations where you trust the, uh, the referenced value and it's, it's fine and it's actually what you wanna do in that case. Nonetheless, in our situation, we're gonna stick with this. Very cool and very good to know. Okay, so now in this lesson you've learned that when you load a view, you can optionally pass data to that view. Each key will be extracted into its own variable.

you can optionally pass data to that view. Each key will be extracted into its own variable. And also notice, uh, in many situations, you're not gonna use route view. So if instead you're using Route get, you would write it like this, here's our closure. You're going to return a view called welcome. And now the second argument to the welcome function is where you would reference, um, your, your data. So if I were to copy that, I could paste that in here

where you would reference, um, your, your data. So if I were to copy that, I could paste that in here and this is functionally identical. I can remove this and we get the exact same thing come back just to be sure. And yeah, it works. Okay. So finally to wrap up, what about situations where no person, uh, query string key is declared something like Well, now we have the situation where we say hello

query string key is declared something like Well, now we have the situation where we say hello to nobody to undefined. So in these cases, the second argument to request can be the default. So what we could do is say the default is just going to be world all right, hello world, but if you override it, person equals um, let's do Simon in this case. Now we get Hello Simon.

let's do Simon in this case. Now we get Hello Simon. Alright, so I hope you're starting to feel a little bit more comfortable and you should in the next episode, we're gonna keep going.