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

> Сама идея вынести стек из роута в отдельный диспетчер мне нравится
Ипать я уже пол года пишу об этом...

Так надо объяснять нормально)

Welcome, Matodor @Matodor!

Это официальная группа "Yii 3 PHP Framework Community"!

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

▪️ Документация: https://github.com/yiisoft/docs

▪️ Текущие задачи: https://trello.com/b/GiAnIAir/yii-3

▪️ Поддержать Yii материально: https://www.yiiframework.com/news/204/preparing-yii-for-the-long-run

Чат Yii 2:  @yii2ru
Чат Yii 1.1: @yii1ru

Он вроде всегда норм объяснял :)

только дальше чата дело не пошло...

а так идея-то норм, конечно

по-хорошему, роут - это DTO-ха

Ну вот я не совсем тогда понял, как это планируется реализовать)

Как реализовать не обсуждали, насколько помню :)

Но что надо бы говорили.

Ну в этом случае не совсем будет, если добавить ему диспетчер. Просто в методе addMiddleware он будет вызывать
$this->dispatcher = $this->dispatcher->withMiddleware(...)
А после матчинга

$response = $matchedRoute->getDispatcher()->dispatch($request);

Кстати, при использовании рр можно кешировать матчинг запросов, это должно еще ускорить роутинг

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

Так... сек. Handler-и - это то, что раньше было middlewares, я просто название поменял, так как технически они как бы не миддлверы, но могут быть любого формата/типа (любого, который поддерживаются диспетчером). Эти так называемы handler-и (то есть middleware-и) можно добавить, как на отдельный маршрут, как группу маршрутов, так и для всего роутера или конкретного диспетчера. И в окончательном итоге все handler-и как мержаться в правильном порядке. Все маршруты из себя представляют DTO имутабельный без особой логики, группы - стали коллекциями (опять без особой логике, это просто список маршрутов, с которым можно будет удобно работать). А вот так называемый ДИСПЕТЧЕР - это единственное звено, которое отвечает, за то, что и как надо делать с матченным маршрутов. Диспетчер по умлочанию оставлен в роутере, чтоб повысить юзабельность, как отдельный пакет. Но в любой момент времени можно переопределить диспетчер как для всего роутера, так и  опять можно переопределить диспетчер для единственного маршрута или одной группы (коллекции).

Про кеширование, или как я высказывался компилирование я уже писал и в issue и в описание PR. Именно для этого в первую очередь Route стал ДТО-хой.

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

Ну ДТО-хой он не стал, там и хендлеры и диспетчер, а они еще зависимости подтянут. Сериализуй роут и увидишь

я постарался в кейсах показать. Добавлю еще пару нормальных тестов, который будут показывать весь use case. Там главное одно - handler это тот же middleware (мидлвер для роута, ну или группы, ну или всего роутера), что был раньше. Диспетчер это уже Executor, который решает, что и как делать со стэком миддлверов для сматченного маршрута.

Ну да, для этого у меня там отдельно RouteDefinition, который просто ДТО без миддлверов и хендлеров. Если захотеть в принципе можно, как то по особому и мидлверы и хендлер сериализировать, только FQCN или callable в каком, то текстовом формате, так как в Route они всего лишь в массиве сидять и никак не вызываются, проверяются или обрабатываются, пока этот маршрут не сматчится и потом этим займется диспетчер.