@makerkz а вы видимо не понимаете, что вам всеравно придется переписывать логику инициализации всего этого добра вне зависимости от решения, ибо у вас DOM постоянно перекалбашивается.
@makerkz если бы был pure js то все бы зависило от поддержки браузерами. Если у нас только актуальные версии браузеров можно было бы использовать Mutation Observer, либо пилить свой кастыль с querySelectorAll. Но вам всеравно придется пилить логику инициализации свою и вручную все инициализировать. Так что вам так или иначе придется писать что-то вроде директив.
Так что хватит тратить время на поиск кривово решения, при том что объем работы в самом простом случае будет не настолько уж и меньше чем написать пару десятков директив.
@makerkz директива toggle покрывает уже кучу вещей, не находите? Это своего рода селектор который будет срабатывать в случае если такой элемент будет появляться и ищезать. Так или иначе через директивы придется делать. Либо кастыли с отслеживанием элементов через querySelectorAll возвращающий вам кошерный NodeList от документа (он всегда в актуальном состоянии, можно один раз вызвать и там всегда будут все элементы подпадающие под селектор) либо декораторы сервисов типа $parse и т.д. но это уже изврат.
@Fly3110 что? Постарайтесь раскрыть мысль более очевидно. Вы хотите переопределить entityManager/twig_environment для приложения? Зачем если вы можете просто настройки поменять (и да, можно указать сколько угодно энтити менеджеров). с твиг энвайрментами уже будет сложнее, нужно будет сервис перерегистрировать с новым именем и своими настройками). Либо заменять через параметры глобально, но тогда старый экземпляр канет в лету и тогда проще будет через конфиг это сделать.
Имхо мне кажется вы делаете какую-то ересь. Либо я все еще не понимаю что вы хотите сделать. Если можно, чуть более подробно с описанием того как вы это собираетесь использовать и почему возникла такая необходимость.
@Hazrat и давайте все же попробую объяснить почему статика это плохо, и почему с использованием фасадов (как это любят делать в laravel) это допустимо.
Допустим у вас есть библиотека ваша для маршрутизации. Router. Ее стоит покрыть тестами. Возможно в будущем она должна расширяться, возможно кто-то пожелает свою реализацию сделать. Но это будет проблемно, так как весь код завязан на имя класса. Это связывает систему и мешает взять и заменить реализацию.
Так же есть нюансы с покрытием кода тестами. Статику вообще можно покрыть тестами, но опять же это не удобно. Еще хуже дело обстоит с моканьем статики - не замокать ее видишли (либо с кастылями). И тестить клиентский код уже будет проблемно.
Статика нужна там, где она нужна. Если честно... она редко когда нужна и я сходу даже придумать не смогу таких случаев. Те же фасады в той же ларавельке используются что бы упростить доступ к компонентам, но они лишь возвращают инстанс класса. Причем что именно они возвращают можно подменять (обычно там регламентируется что должен отдаваться класс реализующий конкретный интерфейс).
@Fesor уточню по сингелтонам - они являются нормальной практикой, просто их частенько пихают туда, где они не нужны. Сингелтоны нужны довольно редко, но почему-то все наровят работу с базой туда завернуть. Им видимо в голову не может придти что одно приложение может иметь два соединения с двумя базами данных.
@Hazrat да. Использования статики такое как у вас - говнокод. Есть фасады, есть сингелтоны (которые так же считаются плохой практикой), но то что пишите вы вне зависимости от контекста - говнокод.
@Hazrat обновил свой ответ косательно вашей проблемы, что бы он небыл таким уж бесполезным.
Что до статики - зачем вам вообще классы если вы оперируете "данными и функциями"? Вам нужен процедурный подход, функции могут иметь состояния, есть замыкания. Что до "проектов полностью на статике"... ну так говнокод везде есть и ничего. Живут люди. У меня же от таких подходов типа "работает и хер с ним" рвотные позывы.
@vasIvas вне js от промисов толку не особо много. В php они вообще по большей части бесполезны, в других языках где есть асинхронные операции, есть свои варианты...
Да и.. блин... кода мало, так почему вы не можете сами то реализовать? И да, промисы это не паттерн, это механизм управления потоком.
