Comments 27
Расскажите как у вас организована работа со store и где живёт бизнес-логика.
Контролы напрямую вызвают action'ы store или работа идёт через промежуточные сервисы?
В моём текущем проекте вся логика лежит в модулях store, но кода стало так много, что всё это крайне тяжело сопровождать. Люди соверуют выносить логику в отдельные js-классы, но тогда появляется вопрос как им работать с state. В общем, хочется узнать, как бороться с лапшекодом в vuex store
Контролы напрямую вызвают action'ы store или работа идёт через промежуточные сервисы?
В моём текущем проекте вся логика лежит в модулях store, но кода стало так много, что всё это крайне тяжело сопровождать. Люди соверуют выносить логику в отдельные js-классы, но тогда появляется вопрос как им работать с state. В общем, хочется узнать, как бороться с лапшекодом в vuex store
В общем, хочется узнать, как бороться с лапшекодом в vuex store
Если там появляется лапшекод, значит что-то идет не так :) По идее, action должен содержать обращение к какому-то ресурсу(самый банальный вариант — HTTP запрос) и последующий вызов commit. Если там накручено много логики — возможно, её стоит вынести в отдельный модуль Vuex?
Если все же нужно выносить логику за пределы Vuex, то это можно сделать так:
import { myActionLogic } from '~/logic/myActionLogic'
export const actions = {
async myAction({state, commit}, payload) {
const computedResult = myActionLogic(state, payload)
const somethingElse = await getSomethingFromNetwork(computedResult)
commit(commitTypes.SET_SOMETHING, somethingElse)
}
}
и в myActionLogic:
// Используем foo и bar из state модуля
export const myActionLogic = ({foo, bar}, {baz}) => {
return foo + bar + baz
}
Показали бы сайт
Похоже что этот: drops.by
По-моему этот: drops[dot]by
Все правильно написали)
«В twitter и на medium ни утихают споры, что все-таки лучше, vue или react»
Где то тут потеряли angular :)
Где то тут потеряли angular :)
Спасибо за статью!
Можно подробностей о конфигурировании pm2, настройках кеширования, как проксируете запросы к nuxt, как работаете со статикой, используете ли lru-cache для компонентов?
Можно подробностей о конфигурировании pm2, настройках кеширования, как проксируете запросы к nuxt, как работаете со статикой, используете ли lru-cache для компонентов?
Расскажу про свой опыт.
Back и front на одном сервере, back кешируют запросы в редис, с ключами типа '/product/123', потом оба проверяют по такому ключу. Статика отдается через nginx, Для большинства компонентов используется lru-cache. Параллельно работает несколько Nuxt инстансев, для разных подпроектов. pm2 используется по простому: pm2 start npm --name «myapp» — run myapp. Так же используем analyze, многие модули грузим через ajax по запросу пользователя. Поэтому текущий общий начальный бандл сократили примерно до 200kb в gzip. При этом функционала и кастомных контролов в проекте достаточно много. Единственное с чем до сих про не разобрался (руки не дошли) это деплой без простоев. Когда билдится новая версия, новые страницы не открываются. Около 50 секунд, для нас не критично, так как главные страницы пока отдаются не через nuxt, когда их переведем придется заморочится. Проект в продакшене около года.
Back и front на одном сервере, back кешируют запросы в редис, с ключами типа '/product/123', потом оба проверяют по такому ключу. Статика отдается через nginx, Для большинства компонентов используется lru-cache. Параллельно работает несколько Nuxt инстансев, для разных подпроектов. pm2 используется по простому: pm2 start npm --name «myapp» — run myapp. Так же используем analyze, многие модули грузим через ajax по запросу пользователя. Поэтому текущий общий начальный бандл сократили примерно до 200kb в gzip. При этом функционала и кастомных контролов в проекте достаточно много. Единственное с чем до сих про не разобрался (руки не дошли) это деплой без простоев. Когда билдится новая версия, новые страницы не открываются. Около 50 секунд, для нас не критично, так как главные страницы пока отдаются не через nuxt, когда их переведем придется заморочится. Проект в продакшене около года.
Единственное с чем до сих про не разобрался (руки не дошли) это деплой без простоев. Когда билдится новая версия, новые страницы не открываются. Около 50 секунд, для нас не критично, так как главные страницы пока отдаются не через nuxt, когда их переведем придется заморочится.
1) Билдить в одно место, а потом использовать подмену. Т.е. запускаем скрипт деплоя, он собирает бандлы в папку version-1.2.3, после чего симлинк папки lastest меняется на version-1.2.3. Или просто переименовываем папку version-1.2.3. Т.е. все эти манипуляции делаются уже после билда и они очень быстры.
2) (не очень хороший способ, но им пользуются тоже). Добавляем готовые бандлы в гит, а на продакшене вообще не собираем ничего.
Благодарю за статью. Мой внутренний ценитель интересных тем доволен.
Глядя на этот сайт даже сложно поверить, что бандл весит меньше 500 КБ. Очень крутой результат и статья интересная. Я делал сервис, spa на vue, и бандл весил 1,5 мб.
как решен вопрос с сео? нет ли проблем для индексации такого сайта?
За размер бандла побеспокоились, а про размер картинок видимо забыли? В итоге особой разницы не заметно, все равно главная страница грузит 5мб
Да, спасибо за замечание. Сейчас поправим.
Это вот тоже нормально на тему, что все гонятся за скоростью, а какой-нибудь такой мелочью можно все труды убить.
Кстати на тему ресайза картинок тоже у себя в блоге писали: надеюсь интересно) websecret.by/blog/optimizaciya-izobrazhenij-na-krupnyh-proektah
Это вот тоже нормально на тему, что все гонятся за скоростью, а какой-нибудь такой мелочью можно все труды убить.
Кстати на тему ресайза картинок тоже у себя в блоге писали: надеюсь интересно) websecret.by/blog/optimizaciya-izobrazhenij-na-krupnyh-proektah
хороший выбор.
интересно было бы посмотреть на внутрянку
интересно было бы посмотреть на внутрянку
Например? В поисках идей для статей)
Я люблю laravel, имхо, это лучшее, что есть в PHP. Хочется какой-то простой коммерции, с не очень сложными телодвижениями на нем. За много лет я разные решения пробовал, и всегда было все не так, как хочется. С годами я привык, преждем что-то выбирать, смотреть архитектуру — обычно это подсказывало, стоит ли это вообще использовать. Сейчас я плотно ощупываю opencart, в качестве решения для небольших проектов, а также (о боже мой!) Битрикс24, вернее, рассматриваю вариант написания дополнений к нему. Страшновато, потому что знакомство с движком Битрикса внутри вызывает профдеформацию ;-) но уж очень вкусный тарифный план в облаке, всяческие CRM и все такое.
Спасибо за статью. Так же полистал комменты и для себя убедился, что проблем с сео нет. Так же помониторил ваш сайт, около 1000 в выдаче по обоим поисковикам, а это важно для меня, т.к. проект, который я буду делать упадет мне на продвижение. В общем я рад, что решил для себя использовать этот стек :)
Sign up to leave a comment.
Опыт разработки SPA на VueJS + Nuxt