Обзор Spatie route attributes - пакет для маршрутизации в Laravel
HTML-код
- Опубликовано: 10 сен 2024
- В этом видео мы сделаем краткий обзор пакета от spatie - route attributes и рассмотрим подход к объявлению роутов через атрибуты которые стали нам доступны с приходом php8. Рассмотрим подробно как работает пакет, а также какие в нём плюсы и минусы.
github.com/spa...
#spatie#laravel#cutcode
---------------------------------------------------------------------------------
❗️❗️❗️Присоединяйся к нашему комьюнити в телеграм - там и советом помогут и много интересного - t.me/laravel_chat
🤖🤖🤖Мой помощник Тэйлор готов выдать тебе подарок. Забирать тут - cutcode.ru/cha...
---------------------------------------------------------------------------------
Всех поклонников laravel я приветствую на канале CutCode! Сегодня в видео мы сделаем краткий обзор пакета от spatie и рассмотрим подход к объявлению роутов через атрибуты которые стали нам доступны с приходом php8. Взглянем как это работает под капотом у пакета, какие минусы и плюсы в себе таит и заодно давайте подумаем - нужна ли рубрика с обзором различных пакетов на нашем с вами канале. Ну не будем тянуть резину - пальцы на старт! Погнали!
Для начала друзья давайте разберемся с концепцией и правилами установки. Здесь все крайне просто нам больше не потребуется объявлять роуты в файлах которые у нас по умолчанию в директории routes всем известный web.php и его друзья. А мы с вами просто в контроллерах, в экшенах добавляем аннотацию с php 8 атрибутом и таким образом объявляем роуты. Пишем контроллеры и сразу указываем Route, выглядит удобно согласитесь. В плане установки все еще более просто - устанавливаем зависимость и публикуем конфиг. Давайте взглянем на конфиг - здесь мы с вами указываем все директории где будут располагаться наши контроллеры, а также указываем все мидлвары которые будут применяться к нашим новым объявленным роутам. По умолчанию здесь только Middlewar substituteBindings, на это стоит обратить внимание если вы тоже знакомитесь с пакетом того же самого старта сессии здесь нет, поэтому стоит либо добавить необходимые для веб-приложения MiddleWar, либо изменить здесь и добавить сюда группу мидолваров web. Либо мы можем добавлять мидлвары или группы прямо в перечне директорий. Пример у нас уже здесь указан иначе наткнетесь на ряд проблем.
Возвращаемся к пакету, он у нас крайне простой по реализации и вся логика таится в классе RouteRegister. Исходя из содержимого мы понимаем что spatie в сервис провайдере будет проходить по всем директориям рекурсивно и где есть контроллеры через reflection API собирать атрибуты и на их основе строить роуты. Тут сразу возникает вопрос "А как это повлияет на производительность?" ведь контроллеров может быть огромное множество и раскиданы они в дереве директорий. Но с другой стороны Роуты и кэшируются и проблем быть не должно. Но ради интереса давайте взглянем на таймлайн по бутингу приложения до пакета и после.
---------------------------------------------------------------------------------
📹 делитесь этим видео с друзьями:
• Обзор Spatie route att...
🔔 подпишитесь на RUclips-канал: www.youtube.co...
📼 Курс по Laravel с нуля:
• Курс по Laravel 8 обуч...
Обзор Spatie route attributes - пакет для маршрутов в Laravel
---------------------------------------------------------------------------------
🔗 наш сайт: cutcode.ru/
📱 Наш telegram-канал: t.me/laravel_c...
Голосую за продолжение рассмотрений разных пакетов для Laravel. Это весьма полезно
однозначно будем продолжать)
рубрика классная, хотел бы дальше видеть такое). Подход как по мне не привычный(понятное дело) ну и странный, я бы не хотел использовать так атрибуты, т.к. что бы отыскать логику работы какого-нибудь роута, я должен просмотреть (ну или просто пройтись поиском, что тоже не так удобно) кучу контроллеров, стандартный подход более удобен в этом плане, хотя порой кол-во роутов может достигать десятков, даже в этом случае удобнее разделить их на файлы по бизнес логике или пр., чем опять же копаться в контролерах
Полностью согласен. Новым разработчикам на проекте придётся постоянно использовать поиск, когда можно было бы всё посмотреть в отдельных маршрутных файлах/классах. Когда ты один разрабатываешь проект и всё там знаешь, возможно, такой подход и увеличивает скорость разработки. Но, как по мне, когда мы все стараемся облегчить контроллеры, такой подход их только усложняет.
@@user-gg5im6bz2z routes:list
Не очень пакет, что он дает? Мне например удобно видеть все роуты в одном файле.
routes:list
Что-то многовато всего для контроллера, как правило там еще и дока описана через атрибуты. Так же надо больше описывать если это api-resource. Я за привычный роутинг через файлы.
мне кажется, такой аннотацией удобно добавить к методу что угодно, но только кроме объявления самого роута. само объявление полезнее в общем месте.
Особенно, когда тебе потом нужно лезть в проект что-то "подправить" и ты понятия не имеешь что за метод и контроллер ипользуется
Все как в Spring Framework :)
спасибо) насчет этого пакета, чего только не придумают)))
Ну роуты через атрибуты это частое явление в других фреймворках
в Symfony еще 10 лет назад были роуты через аннотации. после перехода на лару, отсутствие аннотаций было одно из самых больших разочарований...
попробую использовать в следующих проектах.
в комментах все говорят что неудобно, что роуты размазаны по файлам. но на самом деле чаще удобно видеть роут в контроллере, рядом с методом.
а общий список смотреть командой routes:list если надо будет.
Принцип solid не нарушается, когда в контролер добавляется еще одна ответсвенность?
SPATIE НЕ НАДО ЭТОГО !!! я замахаюсь с поддержкой таких проектов
а рубрика нужна
👍
Нужна такая рубрика)
💯
А потом сидишь пару часов в поисках нужного роута
Через анотации обьявляли роунинг в Symfony
Как-то не очень удобно) я наоборот от этого хотел в ноде уйти и сделать как в ларавель
рубрику пакетов в студию
рубрика пакеты в плейлисте на канале
а если допустим нужен какой-то префикс для группы контроллеров? его получается нужно в каждом контроллере прописывать... а если потом нужно что-то поменять в этом префиксе? и вообще получается что мы на контроллеры скидываем объявление роутов, и получается нарушение принципа единой отвественности же
в симфони, если не ошибаюсь, префикс указывался в аннотации к классу.
Для меня список роутов это как оглавление в книге, которым я, кстати, пользуюсь. Взять и выдрать из книги оглавление выглядит как глупость, но может я чего-то не знаю, может есть другой способ поиска маршрутов... я искать нужный контроллер поиском по проекту не готов, пусть сами едят кактус.
Из ларавел потиху пытаются симфони сделать?
Нет, это уже будет не ларавел тогда) но есть вот такое пакет ( не популярный) позволяющий обьявлять роуты через аттрибуты
Это дело вкуса. В симфони насколько я помню маршруты можно тоже в отдельных yaml файлах хранить.
Как это документировать?
По мне так не удобно, вот допустим мы знаем что у нас есть определенный поинт, но не помним его название, открываем api.php и начинаем искать. А в даном решение, это нужно прыгать по контроллерам и искать его.
Ну либо route:list
@@CutCodeRu тоже не вариант, допустим 1000 или более поинтов, в route:list поиска то нет =)
@@spbskull "php artisan r:l | FINDSTR Spatie" и будут выведены только те строки, где есть слово spatie. Если делется в Linux, то grep вместо findstr
Рубрика нужна. А пакет в помойку. Роуты гораздо удобнее объявлять в одном месте. Носиться по контроллерам в поисках нужного - идея так себе.
надо же
синтаксис атрибутов как в шарпе 🙄
Рубрика хорошая, а пакет отвратительный. Декларирование должно быть где-то в одном месте. Это как метро. А теперь представьте, что вместо единой карты метро, у вас тысячи кусочков бумажки каждой станции.
учитывая, что многие пакеты стали делать свои роуты, то это уже не в одном месте. Так же если используется DDD (как например на курсе Интернет-магазин), где свои роуты у каждого Domain. Зато сразу видно, что данный метод отвечает за это и не надо искать в каком файле он объявлен