походу ему похрен на промис, он не дожидается 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?

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

С чего?

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

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

Давай отделим мухи от котлет. Если ты хочешь использовать 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 лишь лишний раз нагружает сервер, он абсолютно безполезен! ?

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

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

Дожидается

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

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

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

На днях кто-то из чата давал ссылку на ишью хромиума из за хот модуль оеплейсиент. Дайте ещё раз, там в твиттере Койер и Уес Бос возмущаются почему неактивны стили

Можно хайпу поднять

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

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

tl;dr есть? =)

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

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

tl;dr есть? =)

Не тебе было, пардон

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

https://github.com/ndabAP/Vue.js-with-Sails.js-backend-example-project Пример с разделением

Дожидается

да как раз-таки нет, не дожидается! сразу после того как created синхронно завершается - сервер отсылает HTML, а там уже на клиенте снова запускается created и там уже сработает твой Promise а Promise который ты запустаил на сервере в created просто лишняя трата ресурсов, ибо эти данные попросту выбрасываются ? это легко доказать, просто добать console.log в начале created и перед resolve() в Promise body

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

Я не ипу. Просто this же не будет работать...

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

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

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

Эм, че т звучит как: "ну, надеюсь ответ на запрос успеет прийти до того, как сервер отрендерит"

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

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

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

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

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

зачем??

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

Вот, ключевое слово "сбандленный". На каком этапе и как его туда поместить

зачем??

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

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

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

зачем дополнительная сущность?

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

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

в смысле?

в прямом

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

в created асинхронные данные грузить имеешь ввиду?

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

Можно вызывать методы с асинхронными операциями из хуков

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

Напримет в mounted

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

почему?

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

в хуках на сервере это не сработает. asyncData выполняется до рендера (об этом в доке написано). Он нужен, что б до получить данные для ренндера приложения, а потом уже, когда данные получены, начать рендер. С хуками такое не прокатит

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

дожидается

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

дожидается

да ёпп.... Ярик, ты мои сообщения читаешь? ?

да как раз-таки нет, не дожидается! сразу после того как created синхронно завершается - сервер отсылает HTML, а там уже на клиенте снова запускается created и там уже сработает твой Promise а Promise который ты запустаил на сервере в created просто лишняя трата ресурсов, ибо эти данные попросту выбрасываются ? это легко доказать, просто добать console.log в начале created и перед resolve() в Promise body

Собственно, как то был же спор, где данные на клиенте грузить - потом пришел Илья и сказал, что грузить надо в mounted, ибо в created ломается ssr

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

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

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

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

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

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

за что

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

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

Ну там чел че то спросил... я ответил, а потом сказал что на vue с его реактивностью это было бы по проще =) Писоветовал vue. А у них прям совсем подгорело.

ну так вопрос касался реакта, зачем советовать другой инструмент

Ну еще бы)))

... используйте vue

мне бы не понравился такой ответ)

вот вот

может у меня проект весь написан на ректе, но не менять же сразу инструмент

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

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

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

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

показать то не запускается повторно на сайтеце?

ну ёёпт)) Ярослав, я же всё разжевал вроде? "вплодь до последней инструкции процессора" так сказать, что и как происходит

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

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

ERROR: S client not available

твоё решение с асинхронными загрузками данных в created это не просто не работает, это просто бред ? т.е. просто лешено смысла

что за БЭМ?

секта яндекса

что за БЭМ?

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

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

css in js наше все

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

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

поэтому собственно и существует asyncData

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

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

однако вопрос "как асинх. данные в компонентах (не-раутер-компонентах) грузить на серваке" этим не решается..

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

тут банят за то, что не любишь БЭМ

/banned æ digital

?

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

я пока попробую, бросать в action относительно сырые данные (диф списка сущностей). Экшн это с помощью Vue* аккуратно кладет в store. А каждый компонент сам преобразует данные как себе надо

/banned æ digital

Зачем так пугать.

я пока попробую, бросать в action относительно сырые данные (диф списка сущностей). Экшн это с помощью Vue* аккуратно кладет в store. А каждый компонент сам преобразует данные как себе надо

Тогда лучше не компонент, а store getter

Тогда лучше не компонент, а store getter

чтобы быть точным, store getter это что? Computed?

чтобы быть точным, store getter это что? Computed?

это геттеры в Vuex. Принцип работы примерно как computed в компонентах

чтобы быть точным, store getter это что? Computed?

https://vuex.vuejs.org/ru/getters.html

это геттеры в Vuex. Принцип работы примерно как computed в компонентах

ага, посморел. Я думаю, что... это конечно хорошо. Но мне уже очень понравилась идея самодостаточности компонентов. Было бы круто всю логику компонента хранить у него. А не в расшаренном для всех store. Как думаешь? В случае повтора кода - можно вынести их отдельно, не беда.

Приветы. Есть небольшая работа, куда об это можно написать? В этом чате можно?

ага, посморел. Я думаю, что... это конечно хорошо. Но мне уже очень понравилась идея самодостаточности компонентов. Было бы круто всю логику компонента хранить у него. А не в расшаренном для всех store. Как думаешь? В случае повтора кода - можно вынести их отдельно, не беда.

Я считаю, что обработку данных в компонентах нужно свести к минимуму, даже в умных компонентах, оставляя только логику работы с UI "для дизайнеров". Если обработка данных вынесена куда-то во вне, с этим проще работать, поддерживать, тестировать. Тебе все равно где-то придется писать этот код. И меньше всего хочется делать это в UI компоненте.

Я считаю, что обработку данных в компонентах нужно свести к минимуму, даже в умных компонентах, оставляя только логику работы с UI "для дизайнеров". Если обработка данных вынесена куда-то во вне, с этим проще работать, поддерживать, тестировать. Тебе все равно где-то придется писать этот код. И меньше всего хочется делать это в UI компоненте.

а мне как раз больше всего %) Ладно, будет не удобно - уберу, спасибо за ответы.

?

тут банят за то, что не любишь БЭМ

БЭМ?))

бинарная эмуляция монолита?

бинокль Эрнеста Масловича?

банановый экстракт мороженного?

в хуках на сервере это не сработает. asyncData выполняется до рендера (об этом в доке написано). Он нужен, что б до получить данные для ренндера приложения, а потом уже, когда данные получены, начать рендер. С хуками такое не прокатит

Грубо говоря, asyncData, как раз таки sync )))

Приветы. Есть небольшая работа, куда об это можно написать? В этом чате можно?

Есть @javascript_jobs

БЭМ?))

https://seeklogo.com/images/B/bmw-logo-248C3D90E6-seeklogo.com.png

Есть @javascript_jobs

Спасиба