Как правильно передать данные с сервера в SPA, не прибегая к реализации API?

Question

[Сергей]

Принято решение переписать часть существующего сервиса как с vuejs для большей гибкости + заодно избавиться от лапши из JQuery. Но страницы не будут целиком как SPA, лишь часть будет задействована как корневой элемент.
В связи с этим вопрос - как правильнее вывести уже существующие данные для vue?
1. Как и раньше - шаблонизатором просто в разметку/атрибуты? Сейчас примерно так и есть, но хотелось бы избавиться от этого. Всегда отвращали эти конструкции в стиле
let appFrontData = '<?=$someServerVarHere ?>';
2. Не загружать данные для корневого элемента, завести отдельный API-url, который будет отдавать те же данные в JSON и загружать axios при инициализации vue.
Выглядит неплохо, но придется дублировать часть функционала для реализации мини-API-эндпоинтов частей для нескольких страниц.
3. ... Еще варианты?

Answer 1

[Константин Б.]

let appFrontData = '<?=$someServerVarHere ?>';

Гы! А вы думали что в идеальном варианте должны быть единорожки вместо этого?) Три варианта у вас есть и не более.

1) Глобальная переменная. Кстати если вы посмотрите реализацию Nuxt.js/Next.js фреймворков, там как раз используется этот как единственный возможный.
2) Передача в компонент через props
<ComponentName :data='<?=$someServerVarHere ?>'/>
3) Загрузка из компонена

Других вариантов не существует

Comments

[Alex]

Илья

1) Глобальная переменная. Кстати если вы посмотрите реализацию Nuxt.js/Next.js фреймворков, там как раз используется этот как единственный возможный.

Это один из худших вариантов. Особенно в виде let appFrontData = '<?=$someServerVarHere ?>';

1. По некоторым исследованием парсинг JSON работает быстрее чем парсинг непосредственно JS. То есть

   let appFrontData = JSON.parse('<?=$someServerVarHere ?>');

   уже более производительный вариант.
   
2. Глобальную переменную может читать кто угодно и очень просто. И она может быть изменена. Так что нужно добавлять
   

   let appFrontData = Object.freeze( JSON.parse('<?=$someServerVarHere ?>') );

   
   
   
3. Типичные проблемы глобальной области видимости как то конфликты имён и прочее. Никакой изоляции данных.
   

Если вставлять данные в страницу, то предпочтительнее выглядит

<script id="some-uid" type="application/json">{"org": 10, "items":["one","two"]}</script>

// Где-то внутри области видимости компонента
const data = JSON.parse(document.querySelector('#some-uid'));

У вас нет глобальных переменных.
Таких тегов может быть сколько угодно на странице, для каждого компонента.

Такой подход используется в Facebook -- Данные для первичного рендеринга вставляются в тело страницы, а всё остальное -- подгружается по сети.

[Сергей Левченко]

Alex, "нахватались по верхам"...
1) Это абсурд, как может это:
let appFrontData = { a: 1};
быть медленнее чем
let appFrontData = JSON.parse("{ 'a': 1"});

2) Object.freeze в данном случае бессмысленно использовать
3) Ну дак такой кейс, тут иначе никак, тут головой надо думать

<script id="some-uid" type="application/json"> тоже далеко не идеальный вариант

[Alex]

Сергей Левченко,

1. Подробности: https://v8.dev/blog/cost-of-javascript-2019#json
   
2. Почему же? Проблема мутации (случайных или вредоносных) объектов в JS никуда не делась.
   
3. Вот в том и смысл выносить данные в тег: чтобы оторвать их от глобального контекста. Без условно это не решение всех проблем. Тем не менее при таком подходе данные уже есть на странице, они уже загружены, но не занимают память и компонент может их получить в изолированном контексте тогда, когда понадобится.
   

[Сергей Левченко]

Alex,
1) Очень интересно! Не видел/слышал, спасибо за инфу. Но согласитесь - странное поведение движка. И судя по статье, это было в 2019, как сейчас - не знаю. И там от размера зависит, 10 кб - это довольно большой объект данных.
2) Эта проблема есть всегда, таков язык и область применения. Тут нет защиты.
3) В целом взгляды сошлись!

Answer 2

[Alex]

"Правильного" ответа тут не будет. Многое зависит от вашего конкретного случая, от того как построен Бекенд.
Второй вариант выглядит предпочтительнее, если говорить про концепцию SPA. Один из плюсов такой архитектуры в том, что логика работы и данные разделены. То есть всю реализацию (html/css/js) можно один раз отдать на клиент и кэшировать там на максимально длинный срок. И подгружать только недостающие данные для отображения. (И axios вам вероятно даже не нужен).
С другой стороны, если речь идёт про какой-то сравнительно небольшой элемент который может и не понадобится пользователю, тогда, скорее всего это будет излишне.

Вот вам совет: вынесите логику загрузки данных в отдельный модуль. Спрячьте за условной функцией loadData(). Чтобы вы в любой момент могли изменить способ загрузки. Это может быть как сетевой запрос

function loadData() {
  return fetch(' ... ')
}

Или заранее вставленные данные

function loadData() {
  return document.querySelector('#json-data').textContent
}

Comments

[Владимир Кудря]

Еще как вариант могу предложить в шапке что то по типу
window.core_data = ...
а в mounted или beforeCreate делать получение этих данные и записывать в компонент

[Alex]

Владимир Кудря, Опять таки этот или любой другой алгоритм должен быть скрыт за абстракцией.