Хвалебных слов не будет, ибо #ТоксикСреда. Но ребята и так знают, что они молодцы 🫡
Мой технический разбор из двух частей в дополнение к стриму:
🖼️ Массивы уже не айс. Всё-таки времена PHP 7.4 позади.
Обратите внимание на то, что параметры (params) очень хорошо ложатся на DTOшки. DTOшки тоже хорошо сериализуются и десериализуются, кладутся куда угодно, версионируются по semver.
Бонусы очевидны: типизация, автокомплит, не надо знать "путь" до нужного конфига во всеобщем
$params. В DTO также можно добавлять атрибуты для настройки мерж-планов или даже авторезолвинга альясов.# Было
/**
* @var array $params
*/
Foo::class => static function() use ($params): Foo {
return new Foo($params['foo/bar']['option']);
}
# Стало
Foo::class => static function(FooConfig $config): Foo {
return new Foo($config->option);
}
🖼️ Про кашу параметров и структуру: мы вынесли тезис, что в куче параметров чёрт ногу сломит. Хрен найдёшь то, что ищешь.
Однако, я знаю как этого избежать. Всё дело в структуре проекта!
Предлагаемая структура "как в Laravel" проклята. Группировка по типу классов, мол "тут контроллеры, тут хендлеры, тут ещё что-то", — тупиковый путь.
Вот если бы сразу сгруппировать по фичам или модулям, то что получится? Можно раскидать и перегруппировать не только контроллеры/сервисы/etc , но и параметры с конфигами DI.
Ребята, поработайте над структурой!
🖼️ Нельзя получить Request из контейнера: надо сначала получить RequestProvider, затем дёрнуть на нём метод get.
Оно понятно, почему так:
- Мало кто знает, но PSR контейнер по спеке должен быть идемпотентным: на один и тот же id возвращать всегда один и тот же результат. Там не предусмотрены non-singleton биндинги.
- А раз в контейнере всё синглтон, то реквест туда не положишь из-за его динамической натуры: в long running реквест будет каждый раз другой, также он может измениться в PSR мидлварях.
Но не понятно, почему платить за это должны разработчики. Как по мне, плата высокая.
Решить, кстати, эту проблему можно кучей разных доступных способов. Решайте! :)
🖼️ Чтобы уметь работать в неумираемом режиме, Yii опирается на два столпа: дедовские ресеттеры и иммутабельность. Ресеттеры полагаются на события PSR EventDispatcher.
Я доку не читал (а кто её вообще читает?), но надеюсь, что диспетчер событий не навязывается для использования в юзер-ленде.
И если ресеттеры — удел фреймворков, которые не смогли в архитектуру, и для исключительных случаев, то иммутабельность — очень хорошо. Я бы рекомендовал использовать больше иммутабельности и одноразовых объектов, чтобы стейты юзеров не текли, и им не приходилось писать ресеттеры, которые они всё равно писать не будут.
То, что мы видели на стриме мне не понравилось: стейт контроллера протекает. Да, я бы сам не писал такой код, но мы же говорим про фреймворк общего назначения уровня "домохозяйка+". Ну и напомню: если висит ружьё, то оно обязательно выстрелит.
