Flying

Вы вызываете EntityManager::flush() внутри обработчика события, который сам вызывается в процессе работы
EntityManager::flush() (а точнее UnitOfWork::commit()), разумеется вы получаете бесконечный цикл.

Корректным подходом будет реализация, которая накапливает информацию об изменениях и передаёт их для дальнейшего сохранения. Это можно сделать с помощью Doctrine event listener'а, который содержит в себе обработчики следующих событий:

1. preFlush
   
2. postPersist, postUpdate, postRemove
   
3. postFlush
   

Также, хотя механизмы сохранения изменений могут быть разными, с точки зрения уменьшения времени обработки запроса, логично отложить сохранение изменений "на потом", воспользовавшись поддержкой асинхронных очередей в Symfony Messenger.

Таким образом ваш обработчик должен действовать примерно следующим образом:

1. На событие preFlush вы очищаете внутреннюю переменную (например private array $changes = []), в которой будет
   накапливаться информация об изменениях
   
2. Обрабатывая события postPersist, postUpdate, postRemove вы сохраняете в $changes
   информацию об изменениях, которую хотите сохранить
   
3. В обработчике postFlush вы передаёте накопленные изменения, формируя message, для которого настроен роутинг в async транспорт. Обработчик этого message сможет спокойно сохранить все накопленные изменения, не мешая runtime коду.
   
   

На StackOverflow есть прекрасный ответ, описывающий причину и решение (точнее хак, но он помогает).

Если вкратце - добавьте к вашей анимации микроскопический rotate:

@keyframes animStar {
	from {
		transform: translateY(0) rotate(0.05deg);
	}
	to {
		transform: translateY(-200vh) rotate(0.05deg);
	}
} ;

UPD: Вот bugreport (до сих по откытый) по этому поводу и объясение от разработчика почему rotate() помогает.

Я бы использовал service locator для формирования списка сервисов и передавал его в конструктор фабрики.

Альтернативно можно определить фабрику как service subscriber, тогда формирование service locator'а будет, возможно, ещё проще.

Если же каким-то образом (например через общий интерфейс или статический метод класса-фабрики), определить список сервисов, которые умеет создавать фабрика, то можно создать compiler pass, который будет формировать service locator на этапе компиляции контейнера через анализ их зависимостей. Это чуть сложнее, но не потребует править код при расширении списка создаваемых фабрикой классов.

Информация об этом есть в документации.

Если вкратце - разница состоит в том, как будет использоваться результат трансформации.

• ModelTransformer преобразует данные элемента формы для сохранения в модели или получения данных из модели в форму,
  
• ViewTransformer преобразует данные элемента формы для рендера во view или получения данных из запроса в форму,
  

Это совсем разные вещи.

?? - это null coalescing operator
?: - это ternary operator с первым выражением, эквивалентным выражению в левой части оператора.

В Symfony по-умолчанию используется Doctrine, для неё есть Doctrine Migrations.

Поскольку Doctrine - data mapper, то вам не нужно "добавить к таблице колонку / индекс / поменять тип колонки", вместо этого вам нужно менять свои entities и mappings для них (подробнее здесь), а затем создать для неё миграцию, используя команду doctrine:migrations:diff для Symfony console. Т.к. команда работает на сравнении схем базы данных - в итоге вы получите миграцию с SQL скриптами для применения и отката изменений, внесённых в ваши mappings.

Собственные исключения необходимы в случаях, когда вы хотите обрабатывать (или, в случае если вы автор библиотеки - предоставить возможности обработки) какой-либо исключительный сценарий специальным образом. К примеру посмотрите, как организована работа с exceptions в Doctrine.

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

Спецификаций CSS занимается рабочая группа в составе W3C. Там же есть и информация о том, как принять участие / предложить свою идею.

К примеру вы можете создать issue в репозитории рабочей группы.

Однако вам стоит понимать, что работа над спецификацией уровня CSS Grid - это многолетний труд сотен людей для того, чтобы довести её до реального использования. Если вы предполагаете что за всё это время никто из них не додумался до этой идеи - то вам стоит подумать ещё раз.

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

За примерами далеко ходить не нужно: parent selector - мечта уже нескольких поколений разработчиков и тема постоянных вопросов. Однако его нет в спецификации (хотя он был в первых драфтах CSS 3 насколько я помню) и скорее всего не будет. Причину, если интересно, попробуйте поискать сами.

Или, к примеру, такое очевидное, казалось бы, опущение как отсутствие аналога :hover для "stuck" состояния элемента с position: sticky. Ведь его явно не хватает почти любому кто использовал этот стиль. Однако его не будет, о причинах (логичных, но далеко неочевидных) можно почитать в соответствующем issue.

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