Alright, let's talk about shared data. So if I open up Chrome DevTools, and we go to the Inertia root component, yeah, I can see this page property, or data property, and then in the props object, we have baz and foo that's being passed from the DashboardController, right? DashboardController, just as a little demo here. But then I also see auth, errors, and flash, and I'd like to figure out how that's being passed here. For example, if we go into auth, we have a user object, and their firstName and lastName. And I assume that's being referenced here.

name. And I assume that's being referenced here. In fact, why don't we just have a look at that navigation dropdown right now. So I will switch on back, and let's see, maybe in that layout view, let's have a look. And maybe, here it is. So this is the dropdown, right? So if I come back and remove it, it disappears. Okay. So this is that section there. And sure enough, page, props, auth, user, firstName, and then their lastName.

And I don't do a great job of it, but it's something I always have to deal with. And I do things very much like this, where we chop off certain parts if the screen size gets too low. Anyhow, we now see that we're fetching that from page, props, auth. And again, it seems like that's all coming from here. Page, props, auth. And I'm sorry, user, firstName, and last. Okay. So if we're not passing it from the controller, it's obviously being passed through some kind of presenter or probably the middleware.

So if we're not passing it from the controller, it's obviously being passed through some kind of presenter or probably the middleware. Now we already know. I think we've looked at this, right, a few episodes ago. This is one of the setup instructions for Inertia. You need to add this middleware. That you can generate with, what is it, php artisan. You can always grep to Inertia. Yeah, Inertia middleware will create that, and then you import it here, or you reference it here.

Yeah, Inertia middleware will create that, and then you import it here, or you reference it here. So if we have a look here, yeah, notice this share method. This seems to be how global shared data is passed to Inertia, so that you only have to do it once in a single location, versus passing through. Can you imagine if every time in your action you needed to pass through information about the current user? It would be a nightmare. You don't want to do that. So instead, it seems like it gets merged in here.

You don't want to do that. So instead, it seems like it gets merged in here. Let's see. Define the props that are shared by default. So parent share. Okay, so the parent automatically shares the errors. So this is going to resemble exactly how Laravel works, where you have that errors variable, regardless of whether there are validation errors on the page. You just always have access to that. And it seems like Inertia does that as well.

You just always have access to that. And it seems like Inertia does that as well. So for example, if I give this a refresh, what do I see? Page, props, errors. Yeah, it's just going to be an empty object, but if you had failed validation, that would be populated. Okay. But anyways, this means we always have errors, and then we add off, and then we add flash. So maybe next lesson will be dedicated to flash, because that's one of my questions. What is a good way to deal with flash messaging?

So maybe next lesson will be dedicated to flash, because that's one of my questions. What is a good way to deal with flash messaging? But for now, for this episode, let's talk about off. Okay, so a couple questions you might have. You might look at this and think, well, this is redundant. We're just getting the firstName, lastName, email, owner. Why don't we instead just get $request user? Because what it's checking here is, do we have a User associated with the request? Is somebody signed in? If so, get this subset of data, otherwise return null.

Is somebody signed in? If so, get this subset of data, otherwise return null. But if you're not signed in, it does return null. So you might just think, well, let's do that. And if we come on back, give it a refresh, oh, obviously we skipped something. User account. Okay. So what is the relationship here? A User belongs to an Account? So I could always just say request()->user() and eager load the account relationship.

A User belongs to an Account? So I could always just say request user and eager load the account relationship. Will that fix it? Yeah, it does. But anyways, you might think, well, why don't we just take that approach here? So if we have a look at props auth, we have the information about the user and we didn't have to manually recreate each field. So there will be situations when you can do that, but some things to be aware of, and this is a standard thing to keep in mind when you're passing server-side data to the client. When you do that, every single column as you see here, basically the entire database structure.

this is a standard thing to keep in mind when you're passing server-side data to the client. When you do that, every single column as you see here, basically the entire database structure for your table is then exposed to the end user. Now, of course, on an Eloquent model, you can elect to hide things, but still the side effect is that you may often be passing through data that is not used anywhere on the page. And the more data you pass, the slower things are. So for example, if you never referenced the rememberToken, and you're probably not, then why is it here? Why did you bother passing it through? So that's what Jonathan, who I assume wrote this, is doing here.

Why did you bother passing it through? So that's what Jonathan, who I assume wrote this, is doing here. You're only passing the specific data that is required here. And then of course, another side effect benefit would be you're creating a distinction between what the database column name is and what you expose to the end user. Because sometimes they will not be the same. How you want to present it to the user is not actually how you want to store it in the database. So if you instead cast the model to an array and you return it, again, there's a direct relationship there.

So if you instead cast the model to an array and you return it, again, there's a direct relationship there. And you lose a little flexibility to change what these keys that you present to the user are. But anyways, yeah, if we have some kind of subscription, it sounds like I could store that here. And, you know, maybe you have a requestUser, if you had some kind of subscription, requestUserPlan or something like that. I'm just going to hard code that. If they were on the monthlyPlan, this would be an easy way to expose that to your entire

I'm just going to hard code that. If they were on the monthly plan, this would be an easy way to expose that to your entire project. So let's see. If we go back, we give it a refresh page prompts off, like I said, user plan. So now I want to make sure I can access it. So if we go to dashboard view or what is it? dashboard index. Let's just put it right up here. You are on the and how do I access that?

So this is added. Let's see. Is this something Inertia does directly? It doesn't seem initial. There's the initial page. No, I guess Inertia does that behind the scenes. OK, so it sounds like I can say pageProps is a little verbose pageProps of User plan. All right, let's see if that's right. Refresh.

All right, let's see if that's right. Refresh. And there we go. You are on the monthly plan. And then if you want, let's reformat. What you could do is add a computed property for things like this, where you say plan should return this.$page.props.user.plan and then anywhere in the component, you can now just reference the plan name itself and that should do the exact same thing. OK, so I understand that piece of the puzzle. In the next episode, let's figure something else out.