Пробрасываем роуты Angular 2 через роутер Laravel 5

[ivanuzzo]

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

(раньше я тоже таким занимался, когда пытался наладить связь angular + Symfony, в итоге мне подсказали интересную идею, которую я описал выше. Правда, для работы приложения придется дополнительно настроить CORS, но конкретно в Симфони с этим проблем нету)

[ElianL]

Можно так же поднять для фронта маленький сервачок на node.js — использовать как проксю(отпадает необходмость в CORS) и, если нужно, ддя серверного рендеринга.

Хотя если все на одно домене то ни прокси, ни CORS вообще не нужны.

Первую схему мы юзаем для dev окружения, то есть мне как фронтеннд разработчику не нужно поднимать локально бекенд, вторая схема для production

[vintage]

Есть решение проще: просто не вводить своими роутами ни пользователя, ни браузер, ни бэкенд в заблуждение, а использовать # — с ним у вас не будет никаких проблем.

[4ertovo4ka]

Спасибо! Такого примера не хватало, когда я делать начинала.
Почему-то все всегда опускали этот момент.
Но разделение на фронт и бэк, сейчас думаю, правильнее. Две независимые сущности — при замене одной не страдает другая.
Но еще раз спасибо за статью!

[lowadka]

Похоже на какой-то особый вид извращения

[4ertovo4ka]

Зря вы так.
Если посмотреть туториалы по связке 2 означенных вещей — везде будет то, что они работают на одном домене в разных вариациях, но нигде нет подсказки как их подружить вместе в части роутов.
Может и извиащение, но в начале пути это ставит в тупик

[lowadka]

Проблема в том, что это заведомо плохое решение. А когда о таком пишут статью, якобы чтобы "просветить других", то значит, что таких "других" будет только больше

[4ertovo4ka]

Причинно-следственная связь: в своем посте я подняла вопрос о том, что у меня была проблема роутинга. Решение проблемы нигде не проскакивало. В итоге потратив время я пришла к тому, что разнесла laravel и angular по разным доменам.
Автор этого поста дал вариант как можно было бы сделать не разнося по проектам.
В итоге имеем: есть 2 варианта решения одной проблемы. Тут нет соревнования, что хуже, а что лучше — а есть одно видение, и автор тут рассказал, как можно было сделать. Теперь проблема, которая не поднималась в источниках — была поднята, предложено 2 варианта решения этой проблемы. 2 рабочих варианта.
И у каждого остается право выбора что использовать.
И я верю, что для кого-то очевиден выбор в пользу разнесения и вообще очевидны многие вещи. Но давайте не будем списывать со счетов блондинок и новичков, у которых такие моменты могут вызвать вопросы.

[ElianL]

Даже если оставлять все один проектом, то есть решени куда лучше:
определить какие урлы должен обрабатывать бекенд(статика, api) все остальное уже "редеректить" на html файл где урл подхватит клиент.
Идея копипастить урлы из одного файла в другой это просто ужас.

[4ertovo4ka]

Есть замечтательное: "критикуя предлагай".
Предложите, пожалуйста, свой вариант решения. Как можно сделать изящнее?

[ElianL]

"определить какие урлы должен обрабатывать бекенд(статика, api) все остальное уже "редеректить" на html где урл подхватит клиент"

чем не решение?

[4ertovo4ka]

Знаете в чем разница между вашим решением и решением которое вам не нравится?
В его технической реализации.
Решение автора наглядно и его можно пощупать и сделать свой вывод. Ваше решение — описательное. Я предлагаю — а вы уж думайте как сделать. Теории много везде. Живой практики нехватка. Ее отсутствие и толкнуло на поднятие вопроса и предложения решений.
Мне хотелось бы ваше в виде кода так же увидеть. Как новичок, который просто танцует на граблях — ценю пример с возможностью пощупать.

[ElianL]

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

Route::get('/templates/{template}', [
    'uses' => 'MyApp\AngularTemplatesController@index',
])

Route::get('/templates/{template}', [
    'uses' => 'MyApp\AngularTemplatesController@index',
])

Route::get('/assets/*', [
    'uses' => 'MyApp\staticController@index',
]);

Route::get('/api/*', [
    'uses' => 'MyApp\apiContoller@index',
]);

Route::get('*', [
    'uses' => 'MyApp\IndexHTMLController@index',
]);

[vintage]

Более изящные решения почему-то лихо минусуются. :-D

[4ertovo4ka]

Почему-то тут минусуют решение, которое описали не в 2 словах.
Минусуют практическую реализацию.
Ваш комментарий же он не решение, он как теория… А теория — это не практическое решение.
И, как по мне, но когда знаешь как сделать лучше — покажи. А нет времени, так не стоит пробегаючи говорить, что все идиоты, а я дартаньян.

[vintage]

https://angular.io/docs/ts/latest/guide/router.html#!#-hashlocationstrategy-

Реально, это решение как этой, так и многих других проблем.

[ElianL]

решени с решеткой это не изящное решение, решетка для браузера это якорь к которому нужно проскролить страницу после ее загрузки, а никак не часть роута.

History Api придумали не просто от нечего делать.

Плюс ссылки с решеткой плохо индексируются поиковиками. Обращаю ваше внимание, что Angular2 (и ReactJS к примеру) могут отлично сами рендериться на сервере

Ваше решени это просто костыль и использование инструментов(решетки в урле) не по назначению

[vintage]

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

Аргумент к скромности пропустим.

Ссылки с решёткой отлично индексируются поисковиками. Примеры надо?

Сами по себе они отрендериться на сервере не смогут, тем более на каком-нибудь Java-сервере. Необходимо реализовать серверную подготовку данных. И тут без разницы будет ли фронт-контроллер перехватывать /lalala или ?_escaped_fragment_=/lalala

"Моё" решение как раз таки не костыль, а чёткое разграничение зон ответственности: что обрабатывается на сервере, а что на клиенте. А вот "ваше" идёт вразрез с архитектурой веба. Главным образом появляется куча проблем с кешированием, ведь браузер не знает, что по разным псевдостатическим ссылкам скрывается фактически одна и та же страница.

[ElianL]

"чёткое разграничение зон ответственности" — как раз таки будет разбиения проекта на два отдельных =)

"Сами по себе они отрендериться на сервере не смогут" — для этого есть nodejs

"куча проблем с кешированием" — при полноценном серверном рендере страницы не статичны, а в случае если вы отдаете браузеру просто пустой html-заглушку то это не большая проблема, так как все "большие" части(js/css) все равно закешируются

[vintage]

Да, и это хорошо. Но при этом вовсе не обязательно разносить всё по разным доменам.

Ну да, куда ж без ноды-то в java-бэкенде ;-)

1. Бессмысленное для пользователя генерирование на сервере html с данными при старте каждой сессии.
2. Лишний блокирующий загрузку всего остального запрос за html, которого могло бы и не быть.
3. Засранный по самое неболуйся application cache.
4. Невозможность выложить на статический сервер типа github.io.
5. Невозможность без плясок с бубном завернуть в cordova или chrome app.
6. Костыли для обеспечения кроссбраузерности.
7. Невозможность раздачи через CDN.

Но всё это, конечно, пустяки. Зато мы можем укоротить урл на один символ.

[ElianL]

Никто и не говорил про разные домены. На каком домене это все крутиться вообще не при чем. Мы говорим о разбиении на два логический проекта(на уровне репозиториев)

Бессмысленное для пользователя генерирование на сервере html с данными при старте каждой сессии

Не бесмыленное — визуально перформанс растет. C сервера приходит уже готовый html
плюс такие страницы индексируются поисковиками

Лишний блокирующий загрузку всего остального запрос за html, которого могло бы и не быть.

нода не блокирует загрузку за счет асинхроности js

Невозможность выложить на статический сервер типа github.io.

и? сколько страниц в интернете генерится, к примеру, php их тоже нельзя выложить

Невозможность без плясок с бубном завернуть в cordova или chrome app.

лично заворачивал в cordova приложение где фронт был написан с прослойкой на node (c reactjs) — проблем никаких. Потому что фронт умеет рендериться там где есть js

Костыли для обеспечения кроссбраузерности.

при чем тут нода?

Невозможность раздачи через CDN

аналогично с "невозможность выложить на статический сервер типа github.io."

Плюс выноса фронта в отдельный проект в том, что сам фронт и решает каким ему быть после сборки — статикой или легким nodejs сервером. Он никак не завазян на язык/фреймворк бекенда. Мы можем переписывать любую часть, другой это коснется

Он полностью абстагирован от бека, как бы это было например с iOS или Android приложением.

Я уж молчу на сколько это удобно когда бекендерам вообще не приходиться думать, о html/css/js файлах — в их репе их просто нет.
А фронтедрам не нужно поддерживать локальную версию бека, заботиться о миграциях, установки зависимотей бекнда и так далее. Они спокойно забирают данные с удаленного сервера и все. + Всегда могут локально просить данные с продакшен сервера(ведь часто баги появляются именно на рабочем контенте)

На эту тему советую почитать вот эту статью https://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/

[vintage]

Эти 7 пунктов были про всевдостатику, а не про ноду.

[ivanuzzo]

чтобы прийти к «заведомо хорошему решению» нужно не раз споткнуться о грабли. Хорошо, когда есть с кем посоветоваться. А если человек — самоучка, и некоторые моменты (например, эта статья) ему покажутся очевиднее, чем разделение на фронт и бэк? Автор не позиционировал статью, как истину в последней инстанции и эта статья вполне имеет право на жизнь. А если бы комментарии озвучивали альтернативы данному подходу — это было бы куда полезнее, чем просто негативная оценка.

[4ertovo4ka]

У меня плюсы закончились на сегодня.
ivanuzzo, плюсую ))))
В идеале здорово, когда есть что с чем сравнивать. Автор ее предложил именно потому, что у меня не хватило на это знаний.
И вообще такие вещи они уже больше относятся к архитектуре, к решениям, с которыми потом жить. Всегда надо иметь представление как можно сделать по разному и что за каждым вариантом может стоять дальше, какие плюсы и минусы.

[ElianL]

под каждый Angular 2 роут в директиве @RouteConfig нам придется создать копию в роутере Laravel;

Вот уже в этот момент, автор должен понять, что что-то он делает не так