Level 14
@kimmer in the controller that renders the page/view, are you passing through a "user" property at all? This could be overriding the $page.props.user data.
1 like
Nov 13, 2021
14
Level 4
Inertia Jetstream question about $page.props.user
Here's something I don't really understand and I'm wondering if I'm doing the right thing.
I'm using Laravel with Jetstream/Inertia.
By default Jetsream (or Inertia) returns a user object in the $page.props.
I am building a backend where user account details can be updated.
Mostly the $page.props.user object contains the data fro the logged in user. However when I'm on an account update page the $page.props.user object contains the data of the user to be updated and no longer the logged in user.
The Applayout.vue component renders the users profile photo (in the header). this should, obviously, always be the profile photo of te logged in user. But since this profile image is gathered by taking the $page.props.user.profile_photo_url value the image in the header changes whenever an account/update page is showing.
To solve this I updated the share function app\Http\Middleware\HandleInertiaRequests.php to also share the Auth::user() object. Like this...
public function share(Request $request)
{
return array_merge(parent::share($request), [
'flash' => function () use ($request) {
return [
'success' => $request->session()->get('success'),
'error' => $request->session()->get('error'),
];
},
'auth' => Auth::user(),
]);
}
This gives me access to the Auth object to solve this image issue described above.
However, I am wondering if I'm doing the right thing. Shouldn't the $page.props.user object always contain the data for the logged in user? Or is it normal this data changes when a detailed page of any user is called?
Thanks!
Level 4
Thansk for your reply @fueltheweb
This is the code in my controller that renders the User Edit page
public function edit(User $user)
{
return Inertia::render('Administration/Users/Edit', [
'user' => User::with('roles', 'ban')->withTrashed()->find($user->id),
'roles' => Role::get(),
]);
}
I think I see what you mean. Should I not use "user" as a variable for the to edit user opject? Seems rather counter inuitive.
1 like
Level 102
@Kimmer You need to make a choice. Either user is always the authenticated user, and you select some other name in all controllers.. Or the authenticated user is always inside auth or similar.
Level 4
Thanks @Sinnbeck , I think I'm starting to understand what's happening now.
Is there a way to have Inertia output the logged in user by default as $page.props.auth? So the Auth info will never be in $page.props.user. Seems a lot more logical to me.
Level 102
@Kimmer You have already done it in you original post. That is how I do it as well :) Just be sure that you have no vue files that reference $page.props.user
1 like
Level 4
Ah ok, @Sinnbeck. It just seems a bit clumsy to sometimes have the logged in user info in $page.props.user and sometimes the not logged in basic user info. I like to have things seperated, it triggers my OCD ;-)
But it is good to know my solution is acceptable. That was mainly what I wanted to know.
Level 102
@Kimmer And you will. There should never come a point where the signed in user is in $page.props.user
This is the default that inertia shares https://github.com/inertiajs/inertia-laravel/blob/master/src/Middleware.php#L47
Level 102
Ah. Just noticed that it is indeed in the jetstream version :/ So either dont use that one, or live with having to use user as auth user
https://github.com/laravel/jetstream/blob/2.x/src/Http/Middleware/ShareInertiaData.php
Level 4
@Sinnbeck I see. Weird decision to use "user" for auth data but I guess it is what it is. However, maybe it is possible to overwrite that "ShareInertiaData" middleware? Need to look into that.
Level 102
@Kimmer Check your app\Http\Kernel.php file. It must be loaded from in there. (or manually applied in web.php)
Level 4
@Sinnbeck Ah cool thanks. I'll take a look later on (doing some payed work now ;-)but this means we should be able to change that logic to something a bit more logical ;-)
Level 102
@Kimmer Yeah I would personally use my own middleware (I personally dont use Jetstream and therefor already have my own)
Level 4
@Sinnbeck I thought it was a good idea. Not so sure anymore ;-) Thanks a lot for your help! It really cleared things up for me.
Level 4
Aparently it is not as simple as just chaning the call to a service provider or Middleware.
More people noticed this... https://github.com/laravel/jetstream/issues/317 https://github.com/laravel/jetstream/pull/323
An update was planned but then they forgot. Not sure what to think about that ;-)
I descided to change the "user" variable in my controller to "user_data" which I consider soewhat of a dirty fix but it works and keeps the auth data in the "user" variable.
1 like
Please or to participate in this conversation.