Тебя никто и не завставляет вроде. сложно.... нет, интерфейс такой же простой как и был, только теперь не надо следить что там вызывается из твоего контролера

если тебя не интересует другое мнение, то и не стоило кидать

как ты по роуту найдешь js который надо подключить на форму которая используется в 20 разных контролерах? Интересно посмотреть на код

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

пусть в качестве зависимости у нас и выступает статика

ну как бы понятно что любую задачу проще решить в лоб, никто и не спорит собственно

ладно, чтобы было понятно, пусть будет другой пример. Вот есть допустим виджет (ну представим что у нас HMVC модель), в нем есть своя логика и сложный js, однако базовую форму он не наследует ибо виджет, и может использоватmся на N разных страниц. И таких виджетов у нас M. Как предлагаете подключать статику? Либо собирать большой jsник который будет реально большим, а главное не нужным на больше части страниц, либо подключать всю статику где нибуь в теле html что тоже нифига не хорошо. А потом допустим вам нужно сделать условную подгрузку этого виджета (если заходит человек грузим аяксом, если бот просто грузим на страницу, мы же хотим чтобы все индексировалось). И опять те же 2 варианта, либо собираем бооооольшой jsник и грузим его на все страницы, либо адаптируем весь наш js код чтобы не дай бог не выполнялся 2 раза. И все это не мои больные фантазии а реальные тикеты с прошлой работы. Вот чтобы быстро и красиво решать подобные проблемы и нужен данный бандл.

Едем дальше, до пустим у нас появляется второй проект, похожий, и мы хотим подтянуть часть виджетов с первого. В случае подключения в шаблоне виджета мб и не придется ничего менять, а вот в случае с большим jsником и cssником придется сидеть выковыривать только нужную статику. Потом рано или поздно, нам захочется выделить этот виджет в отдельный пакет чтобы менять его независимо синхронизировать изменения на двух проектах сразу, и опять тот же выбор между двумя безальтернативными сущностями. Если же все зависимости по статике привязаны к шаблону виджета и просто собираются в нужных местах, все просто.

А сейчас кто-то ещё использует twig для фронтенда?
Особенно со «своей логикой и сложным js»

нит

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

Мне попадаются проекты админок с твигом

а что с твигом не так?))

server-side с ним не так) Клиентское приложение лучше бы делать независимым от php

так на роуте может быть неизвестное количчество виджетов, например.

в целом кейс понятный, имеет место быть

ну я и говорю, что от обратного - на стату указывать список роутов, а не на роуты список статы

я понял идею, но это не всегда возможно. если список виджетов строится из данных из БД, допустим

ну и связывать роуты с js я бы не стал

М... Но у нас статика не привязаны к росту, зависит от нее не роут а виджет

У виджета класс есть? Или это просто шаблон?

а виждет ты дергаешь аяксом как?