Ещё выше - в транспорте

Как все же лучше - готовить данные в экшенах сразу так, чтобы их было просто отобразить или делать это преобразование в компонентах?

походу ему похрен на промис, он не дожидается created..

Давай отделим мухи от котлет. Если ты хочешь использовать vuex тогда asyncData. Если изоляцию компонента - тогда хук креатед. Я у себя на проекте с ssr записал следующие created(){ if (this.someCollections) return axios.get('http://api.'+this.dom+'/auto/getallauto', {responseType:'json'}) .then(data=>this.someCollections = data) }, первая строчка нужна что-бы уже на клиенте не стартовать повторно get запрос. На сервере у меня хук зарезолвился и с сервера пришли данные уже в data.someCollections

Да

Давай отделим мухи от котлет. Если ты хочешь использовать vuex тогда asyncData. Если изоляцию компонента - тогда хук креатед. Я у себя на проекте с ssr записал следующие created(){ if (this.someCollections) return axios.get('http://api.'+this.dom+'/auto/getallauto', {responseType:'json'}) .then(data=>this.someCollections = data) }, первая строчка нужна что-бы уже на клиенте не стартовать повторно get запрос. На сервере у меня хук зарезолвился и с сервера пришли данные уже в data.someCollections

А если запрос за данными подвис - серевер будет ждать и не отдавать html?

Я посмотрю, спасибо. Но я имел ввиду именно структуру проекта, когда есть разные проекты но все равно это один целый проект.

Давай отделим мухи от котлет. Если ты хочешь использовать vuex тогда asyncData. Если изоляцию компонента - тогда хук креатед. Я у себя на проекте с ssr записал следующие created(){ if (this.someCollections) return axios.get('http://api.'+this.dom+'/auto/getallauto', {responseType:'json'}) .then(data=>this.someCollections = data) }, первая строчка нужна что-бы уже на клиенте не стартовать повторно get запрос. На сервере у меня хук зарезолвился и с сервера пришли данные уже в data.someCollections

1. asyncData с Vuex не связан в обязательном порядке, в asyncData можно зарезолвить какую угодно асинхронную операцию. Vuex это для менеджмента глобального state'а в Flux подходе. 2. твой хук в created же по сути запускается на сервере, но сервер не дожидается завершение .get операции и просто херачит результирующий HTML на клиент, там-же created запускается заново, и заново обращается к серверу за данными.. т.е. твой асинхронный код в created лишь лишний раз нагружает сервер, он абсолютно безполезен! 🙂

1. asyncData с Vuex не связан в обязательном порядке, в asyncData можно зарезолвить какую угодно асинхронную операцию. Vuex это для менеджмента глобального state'а в Flux подходе. 2. твой хук в created же по сути запускается на сервере, но сервер не дожидается завершение .get операции и просто херачит результирующий HTML на клиент, там-же created запускается заново, и заново обращается к серверу за данными.. т.е. твой асинхронный код в created лишь лишний раз нагружает сервер, он абсолютно безполезен! 🙂

Игорь, в силу специфики чата тут есть екземпляры которые на простой вопрос пишут херь и советуют гору велосипедов сразу сходу. Любую информацию нужно отделать. Если у вас простое spa и не нужен сервер-сайд рендеринг, то лучше всего разделить фронт от бека. Сформировать два проекта с своими зависимостями и гитом.

А если запрос за данными подвис - серевер будет ждать и не отдавать html?

tl;dr есть? =)

Я тоже в этому склоняюсь, осталось придумать как их объединять при деплое

Дожидается

Дэн, не еби мне моцк, ты вообще дупля не режешь в ssr и все эти скрини до жопы иди дальше пропагандируй адонис и пиро и по кругу

Вот про created я думаю так же, поэтому и уточнил про подвисший запрос. Иначе, зачем тогда asyncData? :)

Обычно у тебя проект на том же сервере что и база. Соотвественно запрос быстрее в разы. И учитывая то что всё на коа это не блочит общий тред. Дождалось резолва в креатед отдало html

Я тоже в этому склоняюсь, осталось придумать как их объединять при деплое

asyncData нужен для связки на сервере приложения и сторы. Для того чтобы пока не зарезолвятся все акшены не начинать рендерить приложение

не обязательно, в asyncData можно делать ЧТО УГОДНО 🙂 Actions & Store это лишь элементы Flux для работы с глобальным стейтом. в asyncData можно и вычисления проводить, и локальный стейт компонента изменять... да что угодно

Если у тебя чистый спа, то деплой фронта это отдать html, стили и сбандленый js.

зачем??

например можно сделать асинхронный запрос и запихать результирующие данные в локальный scope компонента, совсем не трогая глобальный стейт

так это можно сделать в хуках

так это можно сделать в хуках

если мы говорим об SSR, то асинх данные в created грузить нельзя!!!!

так это можно сделать в хуках

сервер не дожидается промис из created

дожидается

т.е. 2 проблемы: 1. ты тратишь лишние ресурсы на данные, которые просто выбрасываешь (на сервере). 2. в случае с SSR - Crawler скачает этот HTML с сервера но не выполняет твой Promise в created, ибо он JS не умеет, собственно Crawler не видит контента

гг, забанили в react

Моунтед не срабатывает при ssr

Рома, я выше написал что попробую на рабочем проекте. Видать у меня на сервере успевает зарезолвится промис. Потому что с сервера уже приходят данные

"это легко доказать, просто добавь console.log в начале created и перед resolve() в Promise body" это НЕ РАБОТАЕТ: почему? потому-что сервер рендерит твой сайт синхронно, т.е. в 1 цикле event loop'а. А Promise помещается в event-queue и выполняется ПОСЛЕ того как сайт был уже отправлен на клиент, т.е. от этого промиса пользы нет никакой, лишняя трата серверных ресурсов. а когда твой сайтец в браузере запускается он ПОВТОРНО запускает created но уже в браузере, и снова грузит данные

Я просто пошутил, чего беситься то? =)

что за БЭМ?

БЭМ наше всё в CSS

вот именно! Ситуация такая: Сейчас ты пишешь без ssr, а завтра у тебя появляется ssr. И что б не было проблем, ты пишешь запросы в mounted, ибо они не будут выполняться на сервере в отличии от created

@Piterden @c01nd01r - Если писать преобразование ДО vue - то это вроде как не совсем то, какой то внешний код будет заниматься ui, а это дело vue. - Если писать преобразование в экшенах - то тогда логика отображения компонента размазана по компоненту и по экшену. И при каждом новом компоненте пилим код в экшене. Мало того, каждый экшн думает о всех компонентах. Ну и подход с .vue тоже как то мимо пролетает, было то все в одном. - Если писать преобразование в компонентах - то вроде бы шикарно. Экшены будут очень простые, даже слишком. Только я вот боюсь вот чего: когда надо отобразить список сущностей. Тогда получается, что есть computed массив, который будет пересоздаваться при изменении источника данных (добавлении данных). И типа перерендедиваться весь список. Но, вроде как vue докучи умный и понимает что этого делать не надо. Последнее ща проверю

Мне сегодня сказали что там банят за упоминание БЭМ. Правильно делают ящитаю

По первому пункту. У тебя есть какая-то файлик api.js. В нем описаны функции для запроса к сервису. Тут нет никакого UI. В экшине или компоненте ты делаешь import getUser from '../api.js' и вызываешь getUser(id). Вся магия по обработке данных проиходит в этом getUser. В итоге в стору/стейт компонента у тебя приходят красивые обработанные данные, готовые для рендеринга. В итоге Vue не знает про http, а транспортный слой не знает Vue.

/banned æ digital