Евгений Педя

Я не смогу ответить на ваш вопрос профессионально. Я не решал подобных задач.

Я уверен, что мы точно не знаем сколько из заказов на адfl.ru фейковые (что бы отвечать нужна оплата, а значит нагоняем фейками народ, анализируя популярные по ответам проекты) и никогда не могут быть исполнены.

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

А что вас именно интересует?

Да. В начале в методе сlient() мы получаем объект редиректа из функции и тут же его возвращаем из метода (return). Далее в index() мы так же его возвращаем.

https://laravel.com/docs/5.7/responses

Ничего вы не поняли. Как не грустно.
Не нужно связывать this и редирект.
В обоих случаях this используется для обращения к текущему объекту для вызова его метода. И этим они одинаковы.

есть какое-то преимущество с константой? $user->isClient() проверил работает

По имени константы кто-то другой или вы сами (через пол года) можете понять смысл кроющийся в числе 10.
Или вы думаете, что будите помнить что скрывается за числом 10 и другими числами?
Кроме того в коде может быть куча чисел 10 с разными смыслами, а вам вдруг понадобилось сменить 10 на другое число для одного из контекстов. По имени константы можно сменить в любом нормальном IDE автоматом, а вот при замене 10ки можно зацепить и что-то не связанной в данном случае с типом пользователя.

И можно сделать вывод, что this Laravel не запускает метод (как в Vue), а запрашивает объект метода (но это не точно))

Нет! Я описал всё в комментарии к другому ответу подробно.

значит способы сослаться this в Vue и LAravel разные

В данной ситуации - одинаковые.

class FooController
{
    public function client()
    {
           return redirect('/clients');
    }

    public function index()
    {
        //...
        if ($type == 10) {
           return $this->client();
        }
        //...
    }
}

Можно переписать

class FooController
{
    public function client()
    {
           return redirect('/clients');
    }

    public function index()
    {
        //...
        if ($type == 10) {
           $redirect = $this->client();
           return $redirect;
        }
        //...
    }
}

Я уже выше написал, что метод контроллера в laravel должен вернуть в приложение которое его вызвало объект ответа (response). Функция хэлпер redirect() возвращает такой объект, а не выполняет редирект немедленно. Вы запихнули получение этого объекта в отдельный метод. Но без return он не покинет index(). И значит метод объекта возврата отвечающий за его выполнение не будет вызван.

Почему не выполняется редирект сразу, а возвращается какой-то объект из метода контроллера, отвечающего за ответ?
Это особенность реализации laravel и не только. В фреймвоке предусмотрена необходимость выполнения кода как до выполнения бизнес логики (в данном случае она в методе index()), так и после.

В Vue редирект, например, window.location = 'https://foo.bar' вы запускаете в том месте (методе) где решили, а ничего не возвращаете.

В смысле "способ сослаться"? Можно человеческим языком?) Вызывает он метод на исполнение или запрашивает инфу из метода?

Откуда php по вашему знает как вызвать нечто с именем client()?
Это может быть функция. Это может быть метод другого класса.
Это может быть метод данного класса.

php.net/manual/ru/language.oop5.basic.php

узнал, что в Laravel есть трейты.

Они есть в языке php, а не в laravel.

php.net/manual/ru/language.oop5.traits.php

Трейты - это один из способов избежать дублирования кода. Может быть несколько классов, которые не имеют к друг другу отношения прямого, но в них могут использоваться схожие методы реализующие нечто. Иногда их проще вынести в трет и подключить в начале классов. Но это не идеальное решение. Оно подходит если нет смысла в создании отдельного объекта или наследования от общего класса.

По редиректам в laravel.
Смысл создания метода для редиректа есть если в redirect('/clients') может изменится '/clients' (правим в одном методе - работает везде). Но это легко решается именованными роутами. Имя в редиректах сохраняется, а правится url роута, если нужно.
По этому я считаю метод избыточным.
Да и при нормальной IDE найти и заменить redirect('/clients') скажем на redirect('/customers') довольно легко. А лишний метод заставит через некоторое время себя искать, что бы посмотреть, для чего он создан.

это очень удобно делать много методов

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

jazzus, в Vue редирект не то же самое, что редирект в Laravel.
В Laravel метод контроллера отвечающий за какое либо действие должен вернуть объект ответа. Этот объект может будет выполнен позже.
В Vue редирект выполняется в том месте, где он вызван.
И редиректы эти разные. Тот что в Vue выполняется на уровне браузера, а второй ещё и сервер.

На самом деле вам рано ещё заниматься подобной разработкой.
Вы не знаете основ. Работы HTTP и работы JS в браузере.

Ниже избыточная информация - размышления над кодом.

Да и магическое число 10 лучше заменить на константу, которую прописать в модели User.

if ($user->type === User::ROLE_CLIENT) {
    // ...
}

Но не идеально.
В идеале (но не совсем) бы было красивее.

if ($user->isClient()) { // На самом деле customer :)
    // ...
}

Как вариант, если речь идёт о ролях, то возможно.

if ($user->isRole(new RoleClient)) {
    // ...
}

Это уже зависит от сложности проекта и возможности развития или изменения ролей.

И метод client имеет странное название, не отражающее его смысл. :)
Может проще redirectToClientsProfile() или что-то подобное или хотя бы goClients().
Впрочем всё относительно.
По мне метод вообще избыточен и следовательно не нужен.
Достаточно просто return redirect('/clients'); , ведь данный метод ничего другого не делает.

if ($user->isClient()) {
    return redirect('/clients');
}

Ну и $user = User::where('id', Auth::id())->firstOrFail(); то же избыточно
Достаточно $user = Auth::user();
Ведь речь идёт о Laravel и текущем авторизованном пользователе.

// В файле контроллера

    public function index()
    {
        $user = Auth::user();
        if ($user->isClient()) {
           return redirect('/clients');
        }
        // ...
    }

// В файле модели пользователя
class User extends Authenticatable
{
    const TYPE_CLIENT = 10;
    // ...
    public function isClient()
    {
        return (self::TYPE_CLIENT == $this->type);
    }
}

И если проверка делается во всех методах контроллера (контроллер не работает с клиентами),
то проще вынести проверку в миделвея и прикрутить к роутам с контроллером. :)

$this это способ сослаться на текущий экземпляр объекта, для вызова его метода или атрибута.
В данном случае $this позволяет обратится к методу client() (включил режим гадалки) контроллера.

SmInc, а вы поделитесь ресурсом (например результатом поиска или результатом фильтрации) без GET. Тогда станет понятно, почему POST не везде.

Браузер безусловно указывает мне, в какой строке находится синтаксическая ошибка.

И тогда в чём проблема? Вы знаете ошибку. Исправляйте.

И что Вы бессмысленным текстом называете?

Ошибка соединения с MySQL-сервером.
Ошибка при выполнении запроса к базе данных.

Для пользователя скрипта это бесполезно, так как излишне и не понятно.
Для разработки это бесполезно. Посмотрите в сторону mysqli_error().
И вообще не плохо настроить логирование ошибок.

Антон веб-мастера лиды не волнуют. Веб-мастера волнуют задачи по клиентам и их оплата. Это в трелло хорошо организуется. Впрочем если вы сеошника сюда же, то опять же это не для него. CRM по эффективности сайтов - это не для веб-мастера, а их владельца. Там другое. А тут контекст разработка и наполнение. Впрочем может подтвердить только ТС.

А чем Trello для CRM не подходит?
Для каждого бизнеса своя CRM.
Я сомневаюсь, что ТС нужно лиды получать и на звонки отвечать. И воронка ему не нужна. И повторные звонки.

Ему достаточно ведение списка задач с заказчиками. Это есть.

Как он отлично заметил - есть только ваш опыт. Непосредственный опыт.

Роберт Мартин - Чистая архитектура. Искусство разработки программного обеспечения.
Она не о DDD, но без неё DDD изучать трудно.
По DDD на русском выходили три основные книги:
Эванс - Предметно-ориентированное проектирование (Eric Evans - Domain-Driven Design)
Вернон - Реализация методов предметно-ориентированного проектирования (Vaughn Vernon - Implementing Domain-Driven Design)
Вернон - Предметно-ориентированное проектирование (Vaughn Vernon - Domain-Driven Design Distilled)
В электронном виде на русском проблемы с их получением. Первую можно ещё найти в качестве пиратки. Остальные две есть только на складчинах. А в бумаге на периферии книги в будут дорогими. И мне трудно прокомментировать перевод.

Так же есть ещё две книги со спецификой на языки:

Jimmy Nilsson - Applying Domain-Driven Design and Patterns: With Examples in C# and .NET (есть перевод и можно в электронном виде пиратку найти).

Scott Millett, Nick Tune - Patterns, Principles, and Practices of Domain-Driven Design (есть перевод, но получить только через склатчины в электронном виде)

Carlos Buenosvinos, Christian Soronellas, Keyvan Akbary - Domain-Driven Design in PHP (перевода не видел, изначально публиковалась на Leanpub, но потом переехала на Packt Publishing)

Все книги можно найти на английском в электронном виде. Пиратки. Или купить. Из-за кучи терминов книги по DDD читаются трудно и медленно. Понимаются так же. :)

прошлый урок был на 7 с лишним часов

Это свидетельствует о не профессионализме преподавателя.