*? *Про то, что такое Yii3?

Везде пишут, что Yii3 это фреймворк (см. заметку Про понятие «фреймворк»), но на мой взгляд это нечто большее.

⭐️ 1. Набор библиотек

С одной стороны, Yii3 это широкий набор пакетов, покрывающий большинство типовых задач в веб-разработке. Это полноценные библиотеки, каждая из которых релизится независимо и предполагает использование вне Yii.

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

Где-то это уже реализовано хорошо, например, в валидаторе: ставим пакет и можем сразу использовать валидатор.

(new Validator())\->validate($data, $rules);

А где-то ещё нужно поработать над кодом, как, например, в роутере: использовать вне Yii его можно, но это требует довольно трудоёмкой настройки.

⭐️ 2. Шаблоны приложений

С другой стороны Yii3 — это шаблоны приложений:

• классическое веб-приложение,
• API-приложение,
• консольное приложение.

Сейчас их 3, но, думаю, в будущем будет больше. Фактически, вот эти шаблоны с предлагающейся к ней документацией и есть фреймворки. Берём шаблон и добавляем в него свой код.

*⭐️ *Что такое Yii3?

Выходит, что Yii3 это не только фреймворк (скорее даже набор фреймворков), но и конструктор для их создания. Такой себе набор юного фреймворкостроителя ?

P.S. Релиз близко ?

*? *Про форму вспомогательных функций (хелперы) в PHP

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

*⭐️ *Функции

```
namespace App\Helper;

function isAssociativeArray(array $array): bool
{
// ...
}

// Использование
$result = App\Helper\isAssociativeArray($array);
```

*⭐️ *Класс с динамическими методами

```
namespace App\Helper;

final class ArrayHelper
{
public function isAssociative(array $array): bool
{
// ...
}
}

// Использование
$arrayHelper = new App\Helper\ArrayHelper();
$result = $arrayHelper->isAssociative($array);
```

*⭐️ *Класс со статическими методами

```
namespace App\Helper;

final class ArrayHelper
{
private function __construct()
{}

}

// Использование
$result = App\Helper\ArrayHelper::isAssociative($array);
```

Вариант с функциями имеет сразу несколько минусов:
• файл с функциями нужно ручками подключать в composer.json;
• файл загружается всегда, даже если не используется.

В случае с динамическими методами класса перед использованием метода нужно создать экземпляр данного класса. Лишние действия.

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

*? Про принцип инверсии зависимостей и контейнер внедрения зависимостей*

Часто встречаю, что понятия DI и DI-контейнер используют как синонимы. Но это совсем не так.

Принцип инверсии зависимостей (dependency inversion principle, DIP) — принцип ООП, гласящий, что верхнеуровневый код не должен зависеть от низкоуровневого, и зависимости должны быть направлены на абстракции, а не на конкретные реализации.

Контейнер внедрения зависимостей (dependency injection container, DIC) — инструмент, позволяющий удобно создавать объекты через автоматическое разрешение зависимостей, конфигурирование, управление жизненным циклом и прочие возможности.

Использование контейнера не значит, что код соответствует принципу инверсии зависимостей.

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

```
class MyService {
public function __construct(
private LoggerInterface $logger,
) {}
}

$myService = new MyService(
new NullLogger(),
);
```

Таким образом, это абсолютно разные понятия, не стоит их путать.

Более подробно про контейнеры и инверсию управления можно почитать у Мартина Фаулера в статье «Inversion of Control Containers and the Dependency Injection pattern».

*? Cycle Typecast *2.2

Добавлен обработчик приведения типов AttributeTypecastHandler, получающий информацию из атрибутов свойств сущности.

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

```
#[Entity(
// ...
typecast: AttributeTypecastHandler::class,
)]
final class User
{
// ...

```

Из коробки идут следующие типы (подробнее в документации):

• ArrayToStringType
• DateTimeImmutableToIntegerType
• IntegerEnumType
• StringEnumType
• UuidStringToBytesType

Можно сделать свои типы, реализовав простой интерфейс:

interface TypeInterface { public function convertToDatabaseValue(mixed $value): mixed; public function convertToPhpValue(mixed $value): mixed; }

*? Про журнал изменений библиотеки (changelog)*

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

К сожалению, разработчики зачастую уделяют слишком мало внимания журналу изменений в своих библиотеках. Или вообще его не ведут, или пишут не все изменения.

Эта проблема касается даже крупных компаний. Взять, например, Symfony Mailer, в корне лежит CHANGELOG.md, но информации о патч-версиях там нет. Можно пойти посмотреть в релизы, но там мне предлагают только ссылку на список коммитов.

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

*? Полнота* — все изменения (в том числе рефакторинг) по всем версиям библиотеки.

? Существенность — описание изменений только публичного кода (никаких изменений в тестах, CI, документации и прочее).

? Лаконичность — краткое описание сути изменений.

*? Упорядоченность* — версии в хронологическом порядке с указанием даты релиза.

*? Единообразие* — единый формат представления информации.

*? Сегментация* — явное разделение изменений по типу (исправления, добавления, улучшения, удаления).

*? Перелинковка* — ссылки на PR или тикеты, касающиеся изменений.

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

? Podlodka PHP Crew #4 — «Работа с базой данных»

22 апреля начинается очередной сезон, на мой взгляд, одной из лучших русскоязычных конференций о PHP — Podlodka PHP Crew. Конференция проходит в онлайн формате в течение 5 дней. В этот раз тема конференции — работа с базами данных.

Доклады:
• Redis или Memcached: На кону кэш!
• Redis как внешняя память для PHP-приложений
• Уровни изоляции транзакций
• Тонкости работы с postgreSQL
• Миграции, фикстуры, и слепки данных в тестировании и разработке
• Ускоряем и масштабируем проекты с PHP от А до Я
• Как перестать бояться и полюбить Doctrine?

Воркшопы:
• От теории к практике: Разработка и оптимизация баз данных
• Основы Elasticsearch: понимаем, создаём, исследуем

И на вкусное батл «ORM vs Clean SQL».

Есть что посмотреть и обсудить, мероприятие обещает быть насыщенным и интересным.

⚡️ Вся информация на сайте https://podlodka.io/phpcrew — расписание, спикеры, билеты.

—————

И, конечно, приятные бонусы ?

⭐️ PREDVODITELEV — промокод на скидку 500 рублей.

⭐️ Бесплатная проходка для одного из читателей.

Чтобы получить проходку нужно:

1) Рассказать со ссылкой на этот пост о розыгрыше билета на подлодку в своих соцсетях или любом паблике/чате/канале о PHP.

2) Скинуть ссылку на созданный пост в комментарии к этой записи.

Победителя выберу случайно-субъективно в субботу, 13 апреля.

Новая статья в блоге *?*** React Select c бесконечной прокруткой
Появилась задача реализовать элемент Select с асинхронной загрузкой и «бесконечной прокруткой» элементов. Ситуация позволяла использовать любой фреймворк, но прям хорошего готового решения из коробки не нашёл. В итоге выбирал из следующих библиотек:

• jQuery Select2
• Vue Select
• React Select

Мне показалось, что компонент для React самый живой и взрослый. В итоге остановился на нём, а реализацию «бесконечной прокрутки» на базе React Select описал в статье.

*? *Про аргумент в пользу того, что PHP процветает

Coludflare Radar выпустил обзор за 2023 год, в рамках которого представлены тенденции и закономерности, наблюдаемые в интернете. Информация собрана с помощью сети Cloudflare (охватывает более 120 стран и обслуживает более 50 миллионов HTTP-запросов в секунду) и других их инструментов.

На основании анализа Топ-5000 наиболее посещаемых сайтов, видно, что самый популярный язык программирования — PHP, который используют ~55% сайтов.

Там же представлена занятная статистика по фреймворкам, где Yii с долей в 4.2% (первый из PHP-фреймворков) существенно опережает Laravel и Symfony, у которых по 0,6%.

Это достойный контраргумент к моему вчерашнему посту о том, что PHP умирает ?

*? *Про аргумент в пользу того, что PHP умирает

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

На днях они разослали письма разработчикам PHP-пакетов, что выплаты будут снижены до базового уровня (25$ в месяц за пакет), так как у разработчиков корпоративных приложений PHP уже не пользуется такой популярностью как раньше. Клиенты Tidelift, как правило, работают в основном с Java, JavaScript и Python и в более редких случаях с C# и Go.

Хороший аргумент в копилку людям, поддерживающим идею о том, что PHP умирает.

*⭐️ *Обсуждения по теме

Sebastian Bergmann (создатель PhpUnit): https://phpc.social/@sebastian/112211953974965066

Ben Ramsey (создатель ramsey/uuid): https://phpc.social/@ramsey/112165306934938166