Целесообразно ли использовать Angular 4 на классическом PHP сайте, а не в роли SPA?
Всем доброго времени суток.
Общая ситуация:
Angular 4 прекрасно справляется со SPA приложениями, это ясно понятно. Но у нас имеется очень большой сайт, на котором примерно 40% страниц продвигаются в поисковиках и зависимы от СЕО, а остальные 60% являются сервисными, типо личного кабинета и других подобных вещей, которые доступны только после авторизации.
Весь сайт стоит на самописном PHP фреймворке, поэтому гибкости хватает на внедрение сумасшедших идей, а на фронте работает jquery+knockout. СЕО страницы рендерятся на сервере, а сервисные knockout`ом используя ajax запросы, обращаясь к API (есть полноценное апи со всем необходимым). У нас много форм и различных полей/селектов, которые сейчас работают по ajax`у c API, они находятся и на тех и на других страницах.
Что хотим:
Мы хотим унифицировать фронтенд и привести его к одному знаменателю, возможно избавиться от jquery и knockout`а и заменить их на Angular 4, так как это позволит более удобно манипулировать данными поступающими по api и выводить/изменять/удалять/создавать их.
Вопрос:
На сколько вообще целесообразно использоваться Angular на классическом пхпешном сайте? Ведь как понимаю, он рассчитан на то, что в рамках SPA он один раз долго грузится, а потом уже можно быстро юзать приложение, но как будет на обычном сайте? Не получится ли что при каждом переходе на новую страницу, мы будем долго грузить заново весь ангуляр?
И да, зная как устроен ангуляр (единая взаимосвязная система), пока с трудом понимаю, как его можно внедрять на такой сайт, но очень уж хочется)))
Вы же сами всё верно написали.
Если только вы не имели в виду и страницы, которые сейчас рендерятся на сервере для поисковиков, перевести на Ангуляр - это ерунда (бессмысленно вообще и через жопу в частности).
Т.е. то, что у вас сейчас на jQ+KO - можно и переписать, но вряд ли это какой-то выигрыш даст кроме того, что станет "стильно модно молодёжно".. и геморройно..
И кстати, если уж всё равно захотите переписать по-современному, очень рекомендовал бы выкинуть Ангуряр из кандидатов, и в первую очередь смотреть на Vue.
Спасибо, я вас понял. Ну а если абстрагироваться от предпочтений, то что бы вы выбрали в такой ситуации: ангуляр, вуе или реакт? Что для этого будет лучше всего.
И да, я на ангуляр хочу перевести чисто сервисные страницы, а на остальных лишь некоторые отдельные элементы
Тут, видимо, таки ровно вопрос предпочтений.
Но если выбирать между Vue и Angular, то для меня (и не только) - это однозначно Vue.
А React.. ну, можно считать, что он мне просто не нравится (можно было бы аргументировать, но всё равно это будут только личные приоритеты).
Jekins: По опыту предпочел бы vue или angular 1.5(но vue конечно лучше) Ими проще всего задавать поведение для уже существующей структуры , без потери структурности и появления несостыковок и любых дргих проблем. Два раза приходилось использовать примерно как в вашем случае. При этом просто подключали файлы vue.min.js, vue.resourse.min.js без сборщиков(но, чуть позже , стали очевидны преимущества webpack, например так или иначе мы стали писать коммпоненты, и очень удобно когда есть возможность писать стили прямо в файлах компонента )
Василий Назаров: хорошо, спасибо за ответ vkdv: да, вот в ангуляре (новом) немного пугает вся эта сложная структура. Да, в SPA который только на ангуляре все круто, единый проект, а вот внедрение этой все структуры в уже существующую будет не просто. Буду рассматривать Vue как вариант. Спасибо за ответ
Оставьте сайт (как он есть сейчас) на обычном PHP и отдельно создайте подгружаемые раздельно библиотеки обработчиков унифицированных блоков на нативном JS (без всяких JS-библиотек , типа jquery и подобных).
Как только унифицированный блок помещён на страницу (унифицированная форма, или нужна анимация, обработка ввода и отправки данных и т.д.) - подключайте нужную библиотеку (на стороне PHP, которая является обработчиком этого блока) и динамически "цепляйте" обработчик (класс обработки логики событий для этого блока) к нему при инициализации страницы (на стороне клиента).
Не забудьте включить кэширование статики для браузера (заголовки, отдаваемые сервером).
PS: Не нужно создавать трудности там, где их можно избежать.
Да, это отличны способ увеличить скорость загрузки сайта, спасибо. Но остаётся другая сторона вопроса - удобство. Ангуляр был затронут из-за того, что на сервисных страницах, коих большинство, необходимо делать сложные формы отправки данных или фильтрации, а так же выводить контент из апи, который является результатом этих фильтраций. На jq+ko сейчас сам процесс напоминает кашу и не особо удобно. Или вы имеете ввиду подключить подобную инициализацию скриптов и к ангуляру, подключая его только при необходимо и в необходимый промежуток времени?
Было бы ещё замечательно, если намекнёте, как называется подобный способ подключения фронта, чтобы смог откапать по больше инфы
Jekins:
1. Забудьте вообще про либы!
2. Всё нативно пишется!
3. От сложности логики - ничего не меняется!
4. Подобный способ подключения необходимого функционала называется: модульно-функциональный, по-требованию ("on-demand") и применяется в любом языке программирования, поддерживающим работу с библиотеками (т.е., почти в каждом). Другими словами: минимакс для производительности исполнения кода.
Спасибо за мнение. Да, я знаю про ангуляр юниверсал и его возможности и считаю отличным подходом для сайтостоения, но не рассматривал переход полностью на ангуляр, так как у нас в команде примерно 15 php разработчиков и я 1 фронтендер. Боюсь один не потяну весь проект, тем более, что это один из 3 больших проектов компании, где я выполняю функции фронтендера. 60% сервисной стороны сайта смогу, но вот сделать абсолютно все, не уверен. Да и будем честны, никто мне не позволить весь проект перетянуть на себя, когда у нас сидит такая куча бэк разработчиков, которые так или иначе занимаются обработкой данных и выводом их на фронт.
Ну так вот, по вашему мнению, если я буду грузить ангуляр на всех страницах сайта, используя его только в определенных местах (у нас есть сложная поисковая форма, которая отображается по всему сайту), ну и на сервисных страницах, то это будет вполне рабочий вариант фронта?
Jekins: на сервисных страницах переход может быть вполне оправдан. Разметка будет почти такая же, стили те же самые. Единственное - необходимо согласовать API, а также придумать как разделить все на компоненты.
А вот на остальных страницах - его можно внедрить в любое место на странице, обновив поисковую форму, например. Однако при каждом открытии новой страницы она(форма) будет перезагружаться по новой, что может сказаться на загрузке. В любом случае, нужно пробовать.
Можно также попробовать Vue.js, как более легковесную альтернативу.
Для таких целей лучше взять React, вам не нужно хранить сложный стейт на фронте, а просто нужна удобная VM библиотека. Можно конечно и ангуляр взять, там core не очень здоровый, но всё равно куча всего останется неиспользуемого.
Спасибо за мысль. Про реакт не думал, так как пишу в основном на ангуляре и не особо знаю, что реакт из себя представляет. Ок, посмотрю что он такое, может действительно он подойдет лучше. Но как понимаю, если в таком проекте заюзать ангуляр, то это не будет полным дебилизмом?))
Jekins: всё зависит от того, что у вас на страницах. Если много всякого функцианала/работы с API - то у вас получится несколько Angular приложений, и это вполне нормально. Ну и по ходу дела что-то можно будет перенести в Angular и сделать управление страницами на клиенте в рамках одного приложения.
Николай: да, работы с апи очень много и практически на каждой странице. Сейчас это все лежит на jquery и knockout`е, что не устраивает. Хорошо, как я вас понял, просто стоит сделать множество мелких ангуляр приложений, которые подгружаются в определенных местах сайта (например, через вес сайт тянется большая и сложная форма поиска с множеством фильтров)
Да, это нормальное решение, единственное не понятно, как тогда это все собирать, ведь не буду же я под каждую страницу разворачивать полноценный приложение со своим вебпаком, через тот же cli
Есть точка входа #app, там закидываете нужные компоненты. Просто на разных страницах разные компоненты подключаете. Компоненты могут иметь свой роутинг и прочее.
Средний
