ИЛ
Особенно в API-only приложениях
Size: a a a
2020 January 24
AH
Если я захочу туда добавить новый неймспейс?
Что такого ты должен туда засунуть?
На моей практике еще ни разу не сталкивался с таким, что бы подходило под директиву
На моей практике еще ни разу не сталкивался с таким, что бы подходило под директиву
App\Http\View.ИЛ
Мб тебе нужно один композер
ИЛ
А всё остальное - апи
ИЛ
Смысл городить неймспейс View отпадает
AH
А всё остальное - апи
Если основная приложуха - апи, то там вообще вью композер не нужен - контент из контроллера будет отдаваться, а блейды, как таковые, не будут использоваться. А вью композер нужен только для блейдов.
ИЛ
Если основная приложуха - апи, то там вообще вью композер не нужен - контент из контроллера будет отдаваться, а блейды, как таковые, не будут использоваться. А вью композер нужен только для блейдов.
Не факт, что даже при условии апи как основного приложения тебе не понадобиться юзать несколько статик вьюх, в которых тебе нужны одинаковые данные
AH
Интересно то, что относительно недавно (год, может два назад) в доке был неймспейс
App\Http\ViewComposers, а вчера в доке увидел разделение пространства имен.AH
Не факт, что даже при условии апи как основного приложения тебе не понадобиться юзать несколько статик вьюх, в которых тебе нужны одинаковые данные
В случае с апи я вообще вырезаю все обращения к блейдам)
А так да, смысл понял.
А так да, смысл понял.
ИЛ
В случае с апи я вообще вырезаю все обращения к блейдам)
А так да, смысл понял.
А так да, смысл понял.
Это если приложение полностью разделено пополам
ИЛ
А иногда SPA держат внутри файлов лары
AH
Тем не менее, считаю дополнительное пространство необоснованным.
AH
В крайнем случае, в плагине каждый может для себя изменить путь сохранения файлов - плагин такое умеет.
Но дефолтным, всё же, считаю лучше вывести
Но дефолтным, всё же, считаю лучше вывести
App\Http\ViewComposersA
Семантически верным кажется второе.
Почему? Нет такого понятия Http/View отдельного. Только композеры.
С
Вот тогда и стоит задуматься о View\Composers
Смотри, надо написать максимально гибкое решение.
Что мы получаем, делая View\Composers:
1. Хорошая семантика;
2. Гибкое решение — теоретически вероятность мала, но она может быть;
Что мы получаем при юзании ViewComposers?
Что мы получаем, делая View\Composers:
1. Хорошая семантика;
2. Гибкое решение — теоретически вероятность мала, но она может быть;
Что мы получаем при юзании ViewComposers?
С
Не факт, что даже при условии апи как основного приложения тебе не понадобиться юзать несколько статик вьюх, в которых тебе нужны одинаковые данные
ты прав, да
ИЛ
Смотри, надо написать максимально гибкое решение.
Что мы получаем, делая View\Composers:
1. Хорошая семантика;
2. Гибкое решение — теоретически вероятность мала, но она может быть;
Что мы получаем при юзании ViewComposers?
Что мы получаем, делая View\Composers:
1. Хорошая семантика;
2. Гибкое решение — теоретически вероятность мала, но она может быть;
Что мы получаем при юзании ViewComposers?
Отсутствие лишних неймспейсов под маловероятный функционал, идентичная семантика
С
Отсутствие лишних неймспейсов под маловероятный функционал, идентичная семантика
Ну аргумент нормальный, пожалуй ты прав.
AH
Смотри, надо написать максимально гибкое решение.
Что мы получаем, делая View\Composers:
1. Хорошая семантика;
2. Гибкое решение — теоретически вероятность мала, но она может быть;
Что мы получаем при юзании ViewComposers?
Что мы получаем, делая View\Composers:
1. Хорошая семантика;
2. Гибкое решение — теоретически вероятность мала, но она может быть;
Что мы получаем при юзании ViewComposers?
Если бы что-то можно было засунуть в Http/View, то да, разделять нужно, но в данной ситуации неймспейс отсутствует и в проектах нет ничего такого что под него может попать. Следовательно, это неоправданное создание пространства имен. Если проще - нахер надо)
А так, заходя в Http и видя папку ViewComposers разраб сразу четко будет знать что лежит внутри и для чего это нужно.
А так, заходя в Http и видя папку ViewComposers разраб сразу четко будет знать что лежит внутри и для чего это нужно.
С
Если бы что-то можно было засунуть в Http/View, то да, разделять нужно, но в данной ситуации неймспейс отсутствует и в проектах нет ничего такого что под него может попать. Следовательно, это неоправданное создание пространства имен. Если проще - нахер надо)
А так, заходя в Http и видя папку ViewComposers разраб сразу четко будет знать что лежит внутри и для чего это нужно.
А так, заходя в Http и видя папку ViewComposers разраб сразу четко будет знать что лежит внутри и для чего это нужно.
Ну вот, выбирайте ViewComposers тогда. Выявили объективные причины и плюсы-минусы :)