Использовать ли Blade такую конструкцию?

Question

[chelkaz]

Все советуют использовать Blade по максимуму. Вот есть условие у меня, использовать его так или все таки нативным способом через <?php ?>. Краткую запись if не нужно предлагать, так как код с присваиванием переменной длинный, например:
$UserPhoto = '/images/user_profile/'.\App\Models\Question::find($quest_id)->user->UserPhoto->image_url.'.jpg';

Вот как сейчас через Blade:
@if( $a == $b )
{{-- */ $a = 1 /* --}}
@else
{{-- */ $a = 0 /* --}}
@endif

Answer 1

[chelkaz]

Не знаю что решение логичнее, но я сделал следующее:
Для того что бы избежать постоянное обращение к базе за информацией о пользователе и к таблице за фото, я воспользовался:

$AllQuestions = Question::with('user', 'file')->get();

В итоге в $AllQuestions формируется массив из 3-х таблиц.
В модели Question
Сделал следующее:

class Question extends Model
{
    //
    public function user()
    {
        return $this->belongsTo('App\User');
    }

    public function file(){
        return $this->hasOne('App\Models\File','user_id','user_id')->where('module_id', 'user_profile');
    }
}

И я явно указал для таблицы files поля для связи!
'user_id','user_id'
Иначе по умолчанию связи не будет!
После чего в представление можем передать рабочий массив:
return view('questions.index', compact('AllQuestions'));
Запросы уменьшились до 6 вместо почти 70 если например 20 юзеров.
На мысль навела доку. Eager Loading Multiple Relationships

Answer 2

[Евгений Перин]

{{ $user->photo or 'дефолтное фото' }}

Answer 3

[Suinly]

В файлах blade только конструкции blade. Большую часть логики, тем более присваивания каких-либо значений переменным, все же рекомендуется выполнять до рендеринга представления (View) и вне его, что бы не усложнять.

По сути, просто готовите нужные переменные в контроллере, передаете в представление:

$a = ($a == $b) ? 1 : 0;
return render('someview')->with(['a' => $a]);

Comments

[chelkaz]

Возможно ли сделать до ренденга тогда? Если в цикле вывода например новостей нужно еще узнавать фото пользователя. Заранее ведь его не присвоить, а только в форейче.

[Suinly]

chelkaz: вы можете использовать для поиска фото по автору, например, эвенты (Events, https://laravel.com/docs/5.2/eloquent#events), связи с базой фоток (https://laravel.com/docs/5.2/eloquent-relationship... или даже методы в модели.

[chelkaz]

У меня и есть связи в моделях через hasOne. У пользователя может быть, а может не быть фото. Поэтому условия делается в цикле во вьюхе.
@if(\App\Models\Question::find($quest_id)->user->UserPhoto)
есть фото и его вытягиваем
@else
нет фото и отдаем пустую картинку
@endif

[chelkaz]

А как могут тут помочь эвенты? Я например их использую для уведомлений. Но разве к данному случаю их можно и логично применить? Если да то какая логика?

[Suinly]

Рекомендую выполнить запрос к базе один раз для того, чтобы вытащить все данные и связанные с ними пользователей. А потом просто передайте массив в представление и выполните проверку по данным из массива/объекта, вместо того, чтобы выполнять запрос к базе из представления каждый раз, когда нужна фотография:

\@foreach ($questions as $q)
@if ($q->user->UserPhoto)
{{ $q->user->UserPhoto }}
@endif
@endforeach

[Suinly]

Эвенты в данном случае чтобы вытащить сразу фотографии пользователей, если они есть, при поиске данных. Но в вашем случае связи моделей лучшее решение.

[chelkaz]

То есть я правильно понял, что лучше в контроллере сделать форейч и создать новый массив со всеми данными, а затем его уже передавать представлению?

[Suinly]

Во всяком случае, это будет лучше, чем дергать базу в представлении :)

[chelkaz]

Ну как я понимаю это повсеместно требуется везде. Как делают те, кто уже отточил этот процесс? Какой подход будет максимально идеальным во всем. С точки зрения экономии процессов и скорости и других факторов?

[chelkaz]

Просто не ясно разницы пока, если количество обращений из вьюхи будет такое же если я сформирую массив этот до вьюхи. Все ровно придется пробежаться циклом по всем элементам и повытаскивать нужные данные.

[Suinly]

chelkaz: тут вам необходимо изучить практики highload и использовать профайлер для понимания производительности кода и конструкций.