Я согласен, что выглядит не очень просто, но плюсы все же есть.
В этом случае, принципиальное отличие подхода с перезагрузкой блока внутри страницы через ajax в использовании реактивного фронтового движка. Ajaх перезагрузка контента остается перезагрузкой и это, на мой взгляд, не совсем SPA.
К примеру, для SPA каталога (в нашем случае на Vue.js) в теле страницы загружены сразу шаблоны списка товаров и детальной страницы (также могут быть другие шаблоны "страниц": сравнения и т.д.). . Внутри SPA свой собственный роутинг и все работает как "отражение" текущего состоянию JS объекта с данными. Что это дает:
Смена данных в JS объекте приводит к соответвующим изменениям на странице. Это та самая "реактивность". И больше нет необходимости объявлять обработчики незвисимо на как каждом интерактивном элементе. (jQuery для простоты выбора элементов можно больше не подключать, кто ранее использовал) - дает очень существенное упрощение работы с любыми обработчиками и упрощение логики работы компонента в целом.
Переключение между шаблонами происходит мгновенно. При необходимости, запрашиваются недостающие данные от компонентов и только данные. Результат может кэшироваться. При повторном переходе внутри spa задержки нет вообще. С точки зрения user experience отклик страницы всегда очень быстрый( можно привести аналогию с мобильным приложением)
Повторное использование фронтовых компонентов практически повсеместное. Компонент товара с небольшим числом доработок используется в списке каталога, в детальной странице, в корзине, в разделе checkout. Т.е. практически везде.
На самом деле, есть очень существенные плюсы. Но есть и минус - страница не работает без JS, что ограничивает индексацию. Но проблема также имеет решение. Мой коллега описывал ее в отдельной статье. Прошу обратить внимание, если эта тема Вам интересна: https://habr.com/ru/company/agima/blog/578056/
Никакой проблемы нет, если мы реализуем приложение с нуля, с выбором фреймворка специально для построения api. Очевидность преимуществ использвания api и других вполне себе рациональных подходов в статье не оспаривается.
Проблема для меня видна в том, что использование Битрикс в проектах в большинстве своем не про api, а про компоненты со встроенным шаблоном представления.
Задачей являлось продолжать использовать практически весь написанный ранее код (модель), не переписывая проект с нуля. При этом, научиться наполнять Vue компонент данными , по-прежнему использовать возможность настройки через визульный редактор: настройку путей ЧПУ, количество элементов в списке, постраничку и т.д. Также сохранить все возможности, присущие компонентам Битрикс - возможность встраивания и повторного использования с настройкой "по-месту", своего рода SPA в компоненте. Это хорошо себя показало на практике. Некоторые базовые компоненты Битрикс, как sale.order.ajax "из коробки" работают с выдачей шаблону компонента данных в json, что позволило использовать vue компонент с малым количеством правок.
Кроме того, решение позволило в составе компонента использовать сборку webpack, что очень хорошо принято фронтовыми разрабочиками по понятным причинам. Также, больше не нужна интеграция верстки, как это бывает на практике с Битрикс компонентами. Можем протестировать верстку однократно. Преимещества перед стандартными компонентами оказались весомыми. Мы хотели использовать Vue.js SPA в виде компонента Битрикс и нашли возможность. Если у Вас работающий Битрикс-проект, то, на мой взгляд, - это возможность его развить.
Есть плюсы и минусы. Выбор всегда за Вами.
Я согласен, что выглядит не очень просто, но плюсы все же есть.
В этом случае, принципиальное отличие подхода с перезагрузкой блока внутри страницы через ajax в использовании реактивного фронтового движка. Ajaх перезагрузка контента остается перезагрузкой и это, на мой взгляд, не совсем SPA.
К примеру, для SPA каталога (в нашем случае на Vue.js) в теле страницы загружены сразу шаблоны списка товаров и детальной страницы (также могут быть другие шаблоны "страниц": сравнения и т.д.). . Внутри SPA свой собственный роутинг и все работает как "отражение" текущего состоянию JS объекта с данными. Что это дает:
Смена данных в JS объекте приводит к соответвующим изменениям на странице. Это та самая "реактивность". И больше нет необходимости объявлять обработчики незвисимо на как каждом интерактивном элементе. (jQuery для простоты выбора элементов можно больше не подключать, кто ранее использовал) - дает очень существенное упрощение работы с любыми обработчиками и упрощение логики работы компонента в целом.
Переключение между шаблонами происходит мгновенно. При необходимости, запрашиваются недостающие данные от компонентов и только данные. Результат может кэшироваться. При повторном переходе внутри spa задержки нет вообще. С точки зрения user experience отклик страницы всегда очень быстрый( можно привести аналогию с мобильным приложением)
Повторное использование фронтовых компонентов практически повсеместное. Компонент товара с небольшим числом доработок используется в списке каталога, в детальной странице, в корзине, в разделе checkout. Т.е. практически везде.
На самом деле, есть очень существенные плюсы. Но есть и минус - страница не работает без JS, что ограничивает индексацию. Но проблема также имеет решение. Мой коллега описывал ее в отдельной статье. Прошу обратить внимание, если эта тема Вам интересна: https://habr.com/ru/company/agima/blog/578056/
.
К сожалению,код проекта под NDA. Основная идея представлена в примерах кода в контексте статьи
Никакой проблемы нет, если мы реализуем приложение с нуля, с выбором фреймворка специально для построения api. Очевидность преимуществ использвания api и других вполне себе рациональных подходов в статье не оспаривается.
Проблема для меня видна в том, что использование Битрикс в проектах в большинстве своем не про api, а про компоненты со встроенным шаблоном представления.
Задачей являлось продолжать использовать практически весь написанный ранее код (модель), не переписывая проект с нуля. При этом, научиться наполнять Vue компонент данными , по-прежнему использовать возможность настройки через визульный редактор: настройку путей ЧПУ, количество элементов в списке, постраничку и т.д. Также сохранить все возможности, присущие компонентам Битрикс - возможность встраивания и повторного использования с настройкой "по-месту", своего рода SPA в компоненте. Это хорошо себя показало на практике. Некоторые базовые компоненты Битрикс, как sale.order.ajax "из коробки" работают с выдачей шаблону компонента данных в json, что позволило использовать vue компонент с малым количеством правок.
Кроме того, решение позволило в составе компонента использовать сборку webpack, что очень хорошо принято фронтовыми разрабочиками по понятным причинам. Также, больше не нужна интеграция верстки, как это бывает на практике с Битрикс компонентами. Можем протестировать верстку однократно. Преимещества перед стандартными компонентами оказались весомыми. Мы хотели использовать Vue.js SPA в виде компонента Битрикс и нашли возможность. Если у Вас работающий Битрикс-проект, то, на мой взгляд, - это возможность его развить.