Comments 11
Смотрели ли на Nuxt, и если да, то почему выбрали свой вариант SSR?
Правильные ли в таком случае юз-кейсы?
1. Копирайтер хочет изменить шаблон краткого описания товара: сместить картинку, вёрстку текста, добавить название производителя. Копирайтер делает файл с новым шаблоном, загружает на сервер, и приложение использует новый шаблон уже так прямо на лету?
2. Копирайтер хочет добавить функцию сравнения цен товаров. Делает шаблон сравнения, прикладывает к техническому заданию, отправляет программисту. Программист реализует функцию сравнения, прикручивает шаблон, вводит переменную, по которой модуль можно запросить (к примеру из другого шаблона), и теперь тэгом {price-compare} копирайтер может вставить нужный модуль куда надо.
1. Копирайтер хочет изменить шаблон краткого описания товара: сместить картинку, вёрстку текста, добавить название производителя. Копирайтер делает файл с новым шаблоном, загружает на сервер, и приложение использует новый шаблон уже так прямо на лету?
2. Копирайтер хочет добавить функцию сравнения цен товаров. Делает шаблон сравнения, прикладывает к техническому заданию, отправляет программисту. Программист реализует функцию сравнения, прикручивает шаблон, вводит переменную, по которой модуль можно запросить (к примеру из другого шаблона), и теперь тэгом {price-compare} копирайтер может вставить нужный модуль куда надо.
UFO just landed and posted this here
Я вижу две, на мой взгляд, серьезные проблемы в данном подходе, которые делают его нежелательным для использования на продакшене:
1. Сборка шаблонов в рантайме. Это черевато проблемами с производительностью. Если правильно понял принятое решение, на клиент грузится несжатый исходник шаблона, что приводит к передаче лишних данных по сети. После исходник компилируется, что тратит ресурсы клиента.
2. Отсутствует проверка шаблона на ошибки. Любой незакрытый тег, отсутствующая переменная или метод просто уронят компонент.
Сама идея подгружать шаблоны, или даже компоненты целиком, очень даже стоящая. Но все таки должна быть сборка, которая как уменьшит объем загружаемых на клиент данных, так и может выявить ошибки в шаблоне до попадания в продакшн.
Так же вангую еще и третью проблему: системы контроля версий не используются, на сколько понял файлы шаблонов просто заливаются на сервер (ftp, scp, samba, rsync — не важно, они все ненадежны для выкладывания на продакшн). Нет разрешения конфликтов, нет возможности быстро откатится, нет истории правок, сложно автоматизировать сборку.
1. Сборка шаблонов в рантайме. Это черевато проблемами с производительностью. Если правильно понял принятое решение, на клиент грузится несжатый исходник шаблона, что приводит к передаче лишних данных по сети. После исходник компилируется, что тратит ресурсы клиента.
2. Отсутствует проверка шаблона на ошибки. Любой незакрытый тег, отсутствующая переменная или метод просто уронят компонент.
Сама идея подгружать шаблоны, или даже компоненты целиком, очень даже стоящая. Но все таки должна быть сборка, которая как уменьшит объем загружаемых на клиент данных, так и может выявить ошибки в шаблоне до попадания в продакшн.
Так же вангую еще и третью проблему: системы контроля версий не используются, на сколько понял файлы шаблонов просто заливаются на сервер (ftp, scp, samba, rsync — не важно, они все ненадежны для выкладывания на продакшн). Нет разрешения конфликтов, нет возможности быстро откатится, нет истории правок, сложно автоматизировать сборку.
Да не без недостатков и смотрю дальше как это можно оптимизировать.
По первому пункту если компонент написан в стиле:
то тут происходит ровно тоже что и с загрузкой через обертку, при этом растет вес JS файла. При использовании .vue — компонента, конечно там уже все собирается в JS и не происходит лишней нагрузке на компонент.
По второму пункту, да…
И опять же, данный способ стал использоваться по причине, что приходится очень часто отвлекаться если мои коллеги решили сменить местами порядок 2х компонентов (а это действительно у нас к сожалению происходит часто), или ввели всего пару отступов в каком либо компоненте, то приходится тормозить работу с текущими задачами чтобы им срочно поменять пару блоков, после чего может вновь произойти тоже самое, потому что им не понравилось как выглядит)
Системы контроля версий самая беда, поскольку использую исключительно я.
Так же есть недостаток в данном подходе что происходит загрузка всех компонентов, даже которые могут быть не использованы, а так же лишний запрос к серверу на получение данных, что несколько снижает производительность/скорость загрузки сайта.
Если не изменяет память в Angular 1.x как раз происходила подгрузка шаблонов в момент когда они были необходимы, после чего шаблон кэшировался и не запрашивался вновь, как раз смотрим в эту сторону, чтобы загружались только необходимые шаблоны в нужный момент времени, при этом без лишних Promis'ов/async/await
Может в последствии когда все таки мы придем к одному варианту и количество изменений сведется к минимуму, то возможно и уберем обертку, но пока уже год в таком плавании, и остается только надеятся)
По первому пункту если компонент написан в стиле:
Vue.component({
name: 'some-component',
template: '<h1>I am component</h1>'
});
то тут происходит ровно тоже что и с загрузкой через обертку, при этом растет вес JS файла. При использовании .vue — компонента, конечно там уже все собирается в JS и не происходит лишней нагрузке на компонент.
По второму пункту, да…
И опять же, данный способ стал использоваться по причине, что приходится очень часто отвлекаться если мои коллеги решили сменить местами порядок 2х компонентов (а это действительно у нас к сожалению происходит часто), или ввели всего пару отступов в каком либо компоненте, то приходится тормозить работу с текущими задачами чтобы им срочно поменять пару блоков, после чего может вновь произойти тоже самое, потому что им не понравилось как выглядит)
Системы контроля версий самая беда, поскольку использую исключительно я.
Так же есть недостаток в данном подходе что происходит загрузка всех компонентов, даже которые могут быть не использованы, а так же лишний запрос к серверу на получение данных, что несколько снижает производительность/скорость загрузки сайта.
Если не изменяет память в Angular 1.x как раз происходила подгрузка шаблонов в момент когда они были необходимы, после чего шаблон кэшировался и не запрашивался вновь, как раз смотрим в эту сторону, чтобы загружались только необходимые шаблоны в нужный момент времени, при этом без лишних Promis'ов/async/await
Может в последствии когда все таки мы придем к одному варианту и количество изменений сведется к минимуму, то возможно и уберем обертку, но пока уже год в таком плавании, и остается только надеятся)
У вас излишне многословный код для оберток, создавать промисы там, где функции axios уже их возвращают — излишество. Можно написать каждую обертку буквально в две строки:
const wrapComponent = (name, template, component) => () => axios.get(template)
.then(({ data:template }) => Vue.component(name, { ...component, template }));
const wrapPageComponent = (name, template, component) => () => axios.get(template)
.then(({ data:template }) => ({ ...component, template }));
Sign up to leave a comment.
Динамическая загрузка шаблона Vue компонента