Комментарии 41
Можно использовать соглашения об именовании и использовать именованный роутинг всегда.
Тогда для всех ресурсов будут автоматом создаваться имена для роутов. 99% роутов и вообще функционала в приложении - это обычный круд (или то, что ляжет на круд).
К сожалению, в Laravel нет всех фишечек из Ruby On Rails. Например в рельсе можно создать одиночный ресурс или root для неймспейса\модуля (условно для / или /admin). Но можно также использовать ресурсный нейминг с одним роутом.
Не очень понял, что делает библиотека. Почему просто не проименовать все роуты? В чем разница будет между обычным обращением вида foo/bar/baz и boo.bar.baz если имя роута создается из uri?
Тем, что foo/bar/baz - это uri, а foo.bar.baz - имя маршрута по которому определяется URL при обращении через хелпер.
Так а разница? Давай с точки зрения разработчика.
Почему вообще нужны именованные роуты? Например если изменится uri, то имя роута сохранится. Плюс само имя роута не влияет на uri (и обратно).
Получается, что никакого преимущество создание имени роута из uri не дает.
Ну давай с точки зрения архитектуры и разработчиков.
С точки зрения архитектуры правильно говоришь, имя роута никак не должно жёстко связываться с конечным URI и наоборот.
А вот с точки зрения разработки названия в большинстве случаев повторяют то, что в URI находится, так как именно такой подход является интуитивно понятным. И точно также при корректировке URI, например, из api/page в api/pages и имена меняются из api.page в api.pages, что никак не противоречит архитектуре, зато сохраняет юзабилити.
Таким образом, всё же имеем некую привязку URI к неймингу и наоборот.
Почему не проставить имена? Можно и вручную проставлять, но именно данный метод позволит значительно сократить время на внедрение автоматики.
Для примера, у меня проект на рефакторинге с 1233 маршрутами.
Можно использовать соглашения об именовании и использовать именованный роутинг всегда.
В идеале не просто можно, а нужно. А для облегчения процесса можно прикрутить хелпер к проекту.
А не проще всегда использовать:
action([Controller::class, 'methodName']);IDE в таком случае позволяет прыгать в эти методы.
Можно, но тогда возникает необходимость всегда использовать конструкцию данного вида. Куда проще и быстрее имя роута прописать нежели вспоминать в какой контроллер он смотрит.
Laravel Idea позволяет по имени роута ходить в нужные методы.
Плагин платный. Мой вариант работает нативно, без плагинов для laravel вообще.
Кстати, вроде даже старый плагин laravel, который бесплатный, для шторма в это умеет.
Имена для роутов, задаваемые вручную, делаются для того, чтобы при изменении структуры маршрутизации не менять код нигде кроме самого роута.
Имена дают возможность в коде обращаться к роуту по имени, не зная о его структуре. В результате, если позже структура uri поменяется - имена заданные вручную останутся прежними, менять ничего кроме файла роута не нужно будет.
В данной библиотеке, если позже api/pages изменится на api/docs - поменяется и автоматическое имя маршрута и придётся менять обращение к маршруту в коде. При использовании вручную прописанных имён маршрутов - этого не потребуется.
Например:
# routes/web.php
Route::get('pages/{page}', [PageController::class, 'view'])
->name('view_page');
# PageController.php
return view('page', [
'current' => route('view_page', $page),
]);И теперь, если мы хотим поменять маршрут, код контроллера не изменится.
Есть же route resource и нейм из коробки!
use App\Http\Controllers\AuthorController;
use App\Http\Controllers\AuthorBookController;
use App\Http\Controllers\BookController;
app('router')->resource('authors', AuthorController::class);
app('router')->resource('authors/{author}/books', AuthorBookController::class);
app('router')->resource('books', BookController::class);Дефолтный нейминг:
GET|HEAD authors authors.index
POST authors authors.store
GET|HEAD authors/create authors.create
GET|HEAD authors/{author} authors.show
PUT|PATCH authors/{author} authors.update
DELETE authors/{author} authors.destroy
GET|HEAD authors/{author}/edit authors.edit
GET|HEAD authors/{author}/books books.index
POST authors/{author}/books books.store
GET|HEAD authors/{author}/books/create books.create
GET|HEAD authors/{author}/books/{book} books.show
PUT|PATCH authors/{author}/books/{book} books.update
DELETE authors/{author}/books/{book} books.destroy
GET|HEAD authors/{author}/books/{book}/edit books.edit
GET|HEAD books books.index
POST books books.store
GET|HEAD books/create books.create
GET|HEAD books/{book} books.show
PUT|PATCH books/{book} books.update
DELETE books/{book} books.destroy
GET|HEAD books/{book}/edit books.editАвтоматический нейминг:
GET|HEAD authors authors.index
POST authors authors.store
GET|HEAD authors/create authors.create
GET|HEAD authors/{author} authors.show
PUT|PATCH authors/{author} authors.update
DELETE authors/{author} authors.destroy
GET|HEAD authors/{author}/edit authors.edit
GET|HEAD authors/{author}/books authors.books.index
POST authors/{author}/books authors.books.store
GET|HEAD authors/{author}/books/create authors.books.create
GET|HEAD authors/{author}/books/{book} authors.books.show
PUT|PATCH authors/{author}/books/{book} authors.books.update
DELETE authors/{author}/books/{book} authors.books.destroy
GET|HEAD authors/{author}/books/{book}/edit authors.books.edit
GET|HEAD books books.index
POST books books.store
GET|HEAD books/create books.create
GET|HEAD books/{book} books.show
PUT|PATCH books/{book} books.update
DELETE books/{book} books.destroy
GET|HEAD books/{book}/edit books.edit@Aidar87, что Вам мешает использовать дефолтный нейминг с ресурс-контроллерами?
Ну так я про это и написал
Нет, Вы написали что он есть с претензией на описанный в посте расширяющий его функционал. А мой вопрос был касательно дефолтных: что мешает Вам их использовать?
Зачем ставить лишний пакет когда есть тот самый автоматический гибкий нейминг из коробки?
Нет, не автоматический. Из коробки имена вручную прописываются, но к вопросу присоединюсь: зачем ставить лишний пакет? Не ставьте его)
А если без ёрничества, то никто не заставляет его ставить. Пакет есть. Вот он. Это факт. А использовать или не использовать его личное дело каждого.
А Вы взамен внимательнее прочтите здесь.
Видите коллизию?
Лучше с компа откройте ссылку, так весь текст будет правильно структурирован и сразу заметите различия между коробкой и пакетом.
Я так понял, теперь вы согласны с тем, что Route::resource ставит Route Name.
У вас ссылка на свой же коммент. Про какую коллизию идет речь? изначально мой комментарий был, что есть Route::resource и он ставит имя из коробки и если что-то надо кастомизировать, это делается тоже все из коробки, поэтому мой вопрос актуален так как статья называется "Автоматические имена роутов Laravel", а в итоге про Route::resource даже не упоминалось
В данной статье ресурсный роут и не должен упоминаться, так как это есть в официальной документации. В очередной раз говорю, что данное пакетное решение - это улучшение коробочного функционала, а не его добавление, как в комментариях пишут.
И да, ссылка на мой комментарий, так как именно в нём наглядно показана коллизия использования коробочных ресурсных роутов, а именно создание абсолютно одинаковых имён маршрутов при разных URL. Данное пакетное решение, в том числе, исправляет данную проблему. О чём тоже в статье написано.
Все же было бы намного полезнее, если бы этот код скайфолдил исправления, тогда это бы имело смысл и вообще назначение имен роутов, грубо говоря ты открыл какой то старый проект - где вообще не именовали и просто сгенерил
Автоматические имена роутов Laravel