Комментарии 11
Интересно. Очень
Придумать проблему и героически её решить.
Если vue.js берёте то какой смысл костылить к нему что-то, напишите апи нормальный с которым ваше фронт приложение будет общаться.
А если хотите стандартные компоненты использовать то не используйте vue или используйте в рамках, не как spa.
Никакой проблемы нет, если мы реализуем приложение с нуля, с выбором фреймворка специально для построения api. Очевидность преимуществ использвания api и других вполне себе рациональных подходов в статье не оспаривается.
Проблема для меня видна в том, что использование Битрикс в проектах в большинстве своем не про api, а про компоненты со встроенным шаблоном представления.
Задачей являлось продолжать использовать практически весь написанный ранее код (модель), не переписывая проект с нуля. При этом, научиться наполнять Vue компонент данными , по-прежнему использовать возможность настройки через визульный редактор: настройку путей ЧПУ, количество элементов в списке, постраничку и т.д. Также сохранить все возможности, присущие компонентам Битрикс - возможность встраивания и повторного использования с настройкой "по-месту", своего рода SPA в компоненте. Это хорошо себя показало на практике. Некоторые базовые компоненты Битрикс, как sale.order.ajax "из коробки" работают с выдачей шаблону компонента данных в json, что позволило использовать vue компонент с малым количеством правок.
Кроме того, решение позволило в составе компонента использовать сборку webpack, что очень хорошо принято фронтовыми разрабочиками по понятным причинам. Также, больше не нужна интеграция верстки, как это бывает на практике с Битрикс компонентами. Можем протестировать верстку однократно. Преимещества перед стандартными компонентами оказались весомыми. Мы хотели использовать Vue.js SPA в виде компонента Битрикс и нашли возможность. Если у Вас работающий Битрикс-проект, то, на мой взгляд, - это возможность его развить.
Придумать проблему и героически её решить.
С битриксом всегда так. Ну хоть в "массы" пытаются вынести свои проблемы.
А можете код примера на githab выложить? Хочется потрогать)
Слишком усложненная схема. SPA для сайтов которые должны индексироваться в поисковых системах так себе идея для битрикс. Но если заказчик так сильно хочет, то наверно проще было бы сделать SPA на основе html а не json. Просто в проекте отлавливаем все клики на js по ссылкам, и выполняем ajax запрос на эти страницы, например http://example.xom/about/. Мы получим полностью контент с хедером и футером по ajax запросу в виде html и сможем вырезать workarea на js, можно и на php, это дело техники. Да, скорости это не даст SPA приложению, так как мы делаем запрос на всю страницу с хедером и футером, также нужно позаботиться о том что бы все события js работали после рендеринга контента. Но это будет скорее проще и надежнее чем пытаться на vue или react перенести.
Я согласен, что выглядит не очень просто, но плюсы все же есть.
В этом случае, принципиальное отличие подхода с перезагрузкой блока внутри страницы через ajax в использовании реактивного фронтового движка. Ajaх перезагрузка контента остается перезагрузкой и это, на мой взгляд, не совсем SPA.
К примеру, для SPA каталога (в нашем случае на Vue.js) в теле страницы загружены сразу шаблоны списка товаров и детальной страницы (также могут быть другие шаблоны "страниц": сравнения и т.д.). . Внутри SPA свой собственный роутинг и все работает как "отражение" текущего состоянию JS объекта с данными. Что это дает:
Смена данных в JS объекте приводит к соответвующим изменениям на странице. Это та самая "реактивность". И больше нет необходимости объявлять обработчики незвисимо на как каждом интерактивном элементе. (jQuery для простоты выбора элементов можно больше не подключать, кто ранее использовал) - дает очень существенное упрощение работы с любыми обработчиками и упрощение логики работы компонента в целом.
Переключение между шаблонами происходит мгновенно. При необходимости, запрашиваются недостающие данные от компонентов и только данные. Результат может кэшироваться. При повторном переходе внутри spa задержки нет вообще. С точки зрения user experience отклик страницы всегда очень быстрый( можно привести аналогию с мобильным приложением)
Повторное использование фронтовых компонентов практически повсеместное. Компонент товара с небольшим числом доработок используется в списке каталога, в детальной странице, в корзине, в разделе checkout. Т.е. практически везде.
На самом деле, есть очень существенные плюсы. Но есть и минус - страница не работает без JS, что ограничивает индексацию. Но проблема также имеет решение. Мой коллега описывал ее в отдельной статье. Прошу обратить внимание, если эта тема Вам интересна: https://habr.com/ru/company/agima/blog/578056/
.
Да! Но с Битрикс есть некоторые сложности...
... и эта сложность - сам битрикс.
Хороший пост, на сегодняшний день (при условии что необходимо использовать rest, push and pull, локальные приложения B24) какой путь ты изберешь, для энтерпрайз разработки front-a?
1. Vue3 + Bitrix rest (стремиться отделить client app от битрикса)
2. Bitrix cli, bitrix vue3, bitrix js lib (то что есть из коробки)
3. Свой вариант (в рамках битрикс)
И почему?
Vue.js для проекта на Bitrix