Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Всем привет!
Делаю сайт типа файлового хостинга на laravel. Конечно он немного тестовый, впрочем время покажет, с чего то надо начинать.
На настоящий момент готово все, что связано с авторизацией и профилем, плюс подписки через laravel cashier и braintree. Все это обошлось ну практически без js просто надобности даже не было.
Теперь на очереди система аплоада и управления файлами, храниться файлы будут на другом сервере с доступом через API. Видимо в данном случае и нужен js фреймоворк. Вижу два варианта:
1) Ограничить js функционал текущей открытой страницей и каким то небольшим интерактивом. Вроде самого аплоада, всплывающих слоев, подсказок итп. Тут подойдет и нативный js и jquery и возможно react. По этому подходу есть обширный практический опыт.
2) Сделать что то близкое к single page. Те переходы между формами и списками без реолада и со сменой url, более сложный клиентский функционал и интерактив. И тут видимо уже нужен фреймворк в который роуты прописать angullar, или vue - vue router, или еще что то подобное.
А тут опыта нет. Кроме того верно ли я понимаю, что если роуты будут в js фреймворке, то это должно быть так для всего сайта включая профиль и подписки, а не только управления файлами? И laravel тогда должна будет отдавать уже не html, а json ?
Что посоветуете? Желательно, все таки что то не совсем уж монструозное в обучение. Хотя в общем то какое то время освоению уделить можно.
Не в сети
Мастер 
А тут опыта нет. Кроме того верно ли я понимаю, что если роуты будут в js фреймворке, то это должно быть так для всего сайта включая профиль и подписки, а не только управления файлами? И laravel тогда должна будет отдавать уже не html, а json ?
С роутами вечно проблема, урлы дублируются на бэкенде и фронте.
Лично я выгружаю все ларавеловские роуты в json, который съедает фреймворк.
Да, laravel всегда и везде будет отдавать json, если ты хочешь строго разделять фронт и бэк.
Тут уже надо смотреть в сторону стандартизаций - ключевики для поиска: JSON-RPC, fractal - https://fractal.thephpleague.com/ (или иное), GraphQL.
Что посоветуете? Желательно, все таки что то не совсем уж монструозное в обучение. Хотя в общем то какое то время освоению уделить можно.
Советую vuejs, легок в обучении, взял лучшее из реакта и ангуляра.
Не в сети
- Советую vuejs, легок в обучении, взял лучшее из реакта и ангуляра
А он хорошо подходит если я уж так всему сайту строго разделять фронт и бек и отдавать только json не буду? А скажем через js будет работать список файлов и действия с ними, аплоадер конечно… Ну а всякие функции регистрации профиля они как сейчас есть с релоадом…
Не в сети
А наоборот в чистый single page весь сайт или раздел сайта без релоадов vue может? Или все таки может, но реально для этого нужен angullar?
Не в сети
Мастер Да, на все твои вопросы - vue может.
Или все таки может, но реально для этого нужен angullar?
Ты думаешь, что vue это что-то левое и отсталое? Это не так 
vue годная штука и на него все больше обращают внимания.
Laravel спонсирует vue.
Не в сети
Мастер 
А наоборот в чистый single page весь сайт или раздел сайта без релоадов vue может? Или все таки может, но реально для этого нужен angullar?
Добавлю свои пять копеек - лично я люто ненавижу все эти SPA, которые пихают где не попадя (от разных бложиков - привет Google Groups - до интернет-банкингов - привет... да все почти). SPA - это реинкарнация одностраничников на Flash. В 90% случаев достаточно отдавать адекватный HTML с сервера и сверху навешивать лёгкий JS (хоть на голом jQuery, хоть на фреймворках).
Это лучше по всем пунктам: работает быстрее (JS-движок всегда однопоточный, в отличии от рендеринга страницы), загружается быстрее (браузер может использовать предзагрузку/предсказание переходов), нет проблем с тем, что URL в строке адреса действительно соответствует URL'у страницы (в случае косяков с history API), 100% user-friendly для поисковиков и для гиков на lynx и т.д. и т.п.
Единственное, где, пожалуй, выигрывают SPA - это дублирование шаблонов на сервере и на клиенте. Но надо ли ради этого городить все остальное?
Не в сети
А наоборот в чистый single page весь сайт или раздел сайта без релоадов vue может? Или все таки может, но реально для этого нужен angullar?Добавлю свои пять копеек - лично я люто ненавижу все эти SPA, которые пихают где не попадя (от разных бложиков - привет Google Groups - до интернет-банкингов - привет... да все почти). SPA - это реинкарнация одностраничников на Flash. В 90% случаев достаточно отдавать адекватный HTML с сервера и сверху навешивать лёгкий JS (хоть на голом jQuery, хоть на фреймворках). Это лучше по всем пунктам: работает быстрее (JS-движок всегда однопоточный, в отличии от рендеринга страницы), загружается быстрее (браузер может использовать предзагрузку/предсказание переходов), нет проблем с тем, что URL в строке адреса действительно соответствует URL'у страницы (в случае косяков с history API), 100% user-friendly для поисковиков и для гиков на lynx и т.д. и т.п.Единственное, где, пожалуй, выигрывают SPA - это дублирование шаблонов на сервере и на клиенте. Но надо ли ради этого городить все остальное?
Все это с одной стороны так. А с другой на lynx и совсем отсталый браузеры уже наплевать. Насчет СЕО на сайте где весь функционал внутри и главное что бы подписались тоже как то не важно.
Да сингл пейдж может быть тормознее и не удобнее в целом обычного html с легкими js, но это в случае каталогов, какие то разнородных сайтов, именно что совсем не похожих на флешку... Это так. Но он лучше там где все это мысленно представить можно как одно приложение и где js функционал достаточно сложный... От jquery в таких случаях много говно-кода и глюков. Много с этим парился.
В общем то приоритет не столько максимальная оптимизация и сео-френдли, сколько удобство юзеров и чистый современный код.
В тоже время прямо весь что бы только API отдавал пока планов нет. Например на страницах инфо профиля, управления подписками итд, это все незачем..
В общем думаю оптимально vue? Или уж простой небольшой js по старинке? Ангулляр видимо избыточен и тяжел в изучении для данной задачи
Не в сети
Мастер и главное что бы подписались
[...]
Но он лучше там где все это мысленно представить можно как одно приложение и где js функционал достаточно сложный...
Не лучше. Каждая перезагрузка страницы (включая кнопками вперед/назад) требует обновления скриптов с сервера + рендеринга уже после рендеринга страницы браузером. Эти задержки идут на сотни мс, а то и на секунды и весьма заметны. Скорее всего, твой кандидат на подписку не будет ждать, а закроет страницу и пойдет дальше.
Накладные расходы на выполнение JS очень больше, особенно на мобильных устройствах (где и сеть медленная, и устройство слабое). Опять же, для любителей Opera Turbo и подобных сервисов клиентский JS обычно ставит крест на возможности использовать сайт.
А "достаточно сложный" функционал требует просто правильного подхода - что с SPA, что без. Например, строится архитектура наподобие микросервисной, т.е. клиентский JS рассматривается как клиент внутреннего API сайта, итого имеем бекенд, который генерирует базовый HTML, бекенд, который реализует API и фронтенд в виде JS, который это API использует. В дальнейшем API можно сделать публичным. Также эта структура легко масштабируется.
От jquery в таких случаях много говно-кода и глюков. Много с этим парился.
jQuery для больших динамических страниц не приспособлен - это да. Зато другие фреймворки вполне работают и в описанном мной сценарии (подцепляются к DOM с сервера и дальше уже работают сами). Другое дело, что тот же Angular настолько тяжелый, что он регулярно подвешивает мой Firefox даже на не-SPA страницах... Выбирать фреймворк надо с умом.
Не в сети
- Зато другие фреймворки вполне работают и в описанном мной сценарии (подцепляются к DOM с сервера и дальше уже работают сами)
- итого имеем бекенд, который генерирует базовый HTML, бекенд, который реализует API
Тут честно не очень понял… Кроме того что два бекенда… В общем то самый классический старый подход бекенд оттадает html в нем встроены скрипты в которых в свою очередь при надобности ajax запросы к беку уже за json, а то и за html’ом. Вы это имеете ввиду?
Про ангулляр ясно понятно… Да и времени осваивать его сейчас нет.
Изменено htclog81 (01.11.2017 20:00:44)
Не в сети
Мастер Те не делают ajax запросы?
Делают, почему же?
Простой пример - работа с формой. В SPA форма создается с нуля клиентским JS, и обрабатывается им же (например, по onsubmit делается XHR, и результат вставляется в страницу). Без JS пользователь видит пустую страницу. В варианте HTML-only - JS нет, форма уходит на сервер через <form> и сервер уже рендерит ответ как хочет (равно как и форму).
В гибридном же варианте 1) форма рендерится сервером, т.е. выводится <form>, 2) клиентский JS, если он загрузился и выполнился, перехватывает onsubmit и делает XHR (или что-то еще) вместо браузера, и результат рендерит как нужно (здесь может быть логика любой сложности), 3) если JS не загрузился/не отработал - форма уходит на сервер и страница перезагружается, и сервер генерирует ответ.
Может показаться, что дублировать логику на JS и на сервере для ответов это сложно, но это не так. У бекенда, фактически, две роли: низкий уровень, где в ответ на действия отдаются машиночитаемые данные (JSON) и второй - где выполняются все те же действия, но данные форматируются уже для человека. Так вот JS обращается к первому уровню (то, что я назвал внутренним API), а прямой запрос к контроллеру (не через XHR) - это второй уровень. По сути, даже код контроллера может вызывать метод, который возвращает JSON, и работать только с ним. Отформатировать ответ на сервере обычно проблем не представляет, тем более что это можно делать в упрощенном варианте, оставив полное форматирование на совести JS-кода.
В общем то самый классический старый подход бекенд оттадает html в нем встроены скрипты в которых в свою очередь при надобности ajax запросы к беку уже за json, а то и за html’ом. Вы это имеете ввиду?
Да, за исключением того, что скрипты не встраиваются прямо в код страницы, а идут отдельно. Например, если логика не сложная и хватает jQuery, то достаточно кода подобного вида в отдельном .js, который подгружается в конец страницы (<script src> перед </body>):
$(document).on('submit', '#myform', function () { ...; return false; })Это позднее связывание обработчиков событий, что позволяет как угодно менять страницу без потери обработчиков (в обычном случае обработчик привязан к отдельному узлу и если его заменить, например, в результате ответа на XHR, то обработчики потеряются).
А про vue Вы что думаете?
С Vue не работал. Осторожно отношусь к проектам, вокруг которых поднимают хайп. Тем не менее, отзывы о Vue хорошие, есть смысл на него посмотреть.
Не в сети
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)