jazzus

Насколько я помню, ->get() делает запрос к базе и возвращает коллекцию. А это куча данных и ваш проект будет умирать, пользуйтесь groupBy как часть запроса и расчитывайте на стороне БД до вызова get(), а не после, когда вы уже работаете не с квери билдером, а с огромной коллекцией.

Если нам нужно прокинуть данные от родителя к ребенку на сколь угодно глубокий уровень, мы можем воспользоваться provide/inject, а если нам надо в обратную сторону?

Точно так же. "Прокидывайте" с помощью provide метод компонента - "в обратную сторону" сведётся к его вызову.

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

ТДД про то, что бы писать тесты до кода.
Зачем это надо? Потому что такой подход помогает лучше структурировать в голове необходимую функциональность перед написанием непосредственно кода.
Такой подход позволяет избегать избыточного усложнения кода, потому что подход "tests first" не позволяет написать полотнище сложного кода, не проверив правильность его работы.
Плюсов достаточно.

Теперь по поводу того, нужно ли ТДД всегда.
ТДД нужно не всегда, как и красивый, производительный и правильно работающий код.
Иногда, нужно закостылить MVP, проверить бизнес-идею и продолжить жить. В таком подходе 20% времени, потраченные на юниты - непозволительная роскошь.
Иногда, вы пишете систему, сложность которой такова, что держать в голове матрицу состояний даже одного модуля не представляется возможным. И тут уже без юнит-тестов никак. Тут ТДД будет полезно.

Резюмируя. ТДД - отличный инструмент. Он позволяет не откладывать на потом написание юнит тестов, добиваться хорошего покрытия и, что важнее всего, контролировать изменения, вносимые в систему. Любая неожиданная ветка поведения приведет к падению тестов.
Как и любой инструмент - ТДД хорошо тогда, когда ты применяешь его своевременно, правильно и по назначению.
Писать тесты когда продакшен в огне, а компания терпит крах - плохая идея. Везде нужен здравый смысл.

Передать-то можно:

$data = $api->getJson();
$model = new YourModel($data);

Но только проще создать свои модели, не связанные с Eloquent (можно в них добавить трейт HasAttributes, если нравится его поведение), а не пытаться натянуть ужа на ежа. В "стандартной" модели очень много всего завязанного на Eloquent и подменить его будет сложно, лучше потихоньку добавлять нужную функциональность руками.

Ну а контроллерам вообще всё равно с какими объектами работать.

А как одно другому мешает? В общем случае guards и policies позволяют использовать кучу хелперов (в шаблонах, в контроллерах, в т.ч. ресурсных, в middleware) а откуда они там будут брать для этого данные (поле в модели пользователя, поле в отдельной таблице ролей, поле в таблице модели прикладного объекта, некая комбинация этого (например автор + модератор)) - это все описывается уже кодом.

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

Надо просто добавить какой-нибудь last_activity_at и при каждом запросе юзера ставить туда текущую дату.

При выборе уже выбираете тех у кого last_activity_at > now()->subMinutes(5) например.

Это и будут онлайн пользователи.

У Laravel есть Laravel Mix в комплекте, который спокойно позволяет оптимизировать все ваши махинации.
Запускаете команду npm run watch и спокойно пишете код, если нужно обновление страницы при изменениях - подключаете browserify.

Смотрите в сторону Laravel Envoy, настраиваете все данные для деплоя на сервер. Все это деплоится с git-репозитория вашего проекта.

В итоге весь маршрут от выполнения правок до деплоя проекта состоит по сути из следующих этапов:
1. Выполняете правки, просматриваете через npm run watch
2. Комитите все в свой репозиторий.
3. Выполняете команду envoy run deploy и все изменения с репозитория подтягиваются на сервер.

На этом все.

preg_replace_callback(
    '~[А-ЯЁA-Z]{2,}~u',
    function ($match) {
        return mb_strtolower($match[0], 'utf-8');
    },
    'Товар "Диван Амстердам" МИКС, акция, ОГРАНИЧЕННАЯ ПАРТИЯ'
);

https://github.com/vuejs/awesome-vue
выбирайте любой
https://github.com/vuejs/awesome-vue#loader

https://drawsql.app/templates

Collection of real world database schemas from open-source packages and real-world apps that you can use as inspiration when architecting your app.

На любой вкус.

Вы можете валидировать данные, которые приходят в контроллер через кастомные Request-классы. Там вы можете указать такую конструкцию:

public function rules()
    {
        return [
            'slug' => [
                'string',
                'unique:posts,slug'
            ],
        ];
    }

Если при проверке Slug он уже есть в базе, то выводится ошибка валидации.

Чтобы слаг генерировался на лету, можете в том же кастомном Request реализовать метод:

protected function prepareForValidation() :void
    {
        $this->merge([
            'slug' => ($this->slug) ?? \Str::slug($this->title, '-')
        ]);
    }

То есть перед самой валидацией ваших данных к этим данным добавится сгенерированный из заголовка слаг, если поле осталось пустым, либо тот слаг, что вы указали