Comments 2
Статья на очень интересную тему, но написана очень неряшливо. Видно, что целью этого Леса является порекламировать Mercure, а не описать полезное решение существующей проблемы. В итоге включается наперсточник, "Кручу-верчу, запутать хочу, за хорошее зрение — денежная премия! Следите за руками!":
- описание проблемы
- ссылка на решение с помощью блокировок Доктрины
- Mercure
- Демонстрация (на редкость дурацкая, идея показывать онлайн уведомления статичными картинками вызывает удивление). Эээ… а демонстрация чего? Решения на основе Доктрины? По логике должна быть она, но вроде бы нет, это демонстрация решения на основе Mercure. Но мы же его еще не делали?
- Как это работает (кстати, двойка переводчику за "Как это реализовать"). Вообще ни слова про то, как это работает, а инструкция, как поднять образ.
- Реализация. Галопом по европам. Два абзаца, хотя эта часть должна бы по идее являться основной.
- Тестирование. Интересная тема, но блин, статья вроде не про Panther?!
- "Конечно, использование блокировки Doctrine было бы более надежным решением". Wait, wait, wait, а в каком месте мы потеряли Доктрину?! Где было сказано, что будет использоваться не Mercure с Доктриной, как логично предположить из построения статьи, а решение на одном Mercure? Зачем вообще тогда было рассказывать про Доктрину?
Конечно, использование блокировки Doctrine было бы более надежным решением. Мы рекомендуем консолидировать состояние данных, используя оба подхода
Мне кажется, это плохая рекомендация. Mercure точно имеет свои кейсы использования, но рекомендовать его там, где нужен просто бековый механизм версионного контроля c возвратом ошибки на фронт, кажется странным. Сложность системы с привнесением туда обмена сообщениями сильно вырастает. Это только кажется, что работать с Mercure просто как composer require mercure-bundle. И все ради чего? Ради красивого сообщения об ошибке на пару миллисекунд ранее?
Надеюсь, вы не включите эту рекомендацию в ваш курс.
EasyAdmin и Mercure: реальный юзкейс