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

я бы вообще решил какойнибудь фабрикой обьекта ScrollBehaviourPolicy который бы можно было наследовать и переопределить что угодно в том числе и весь https://github.com/vuejs/vue-router/blob/dev/src/util/scroll.js#L59 но это во взрослом языке и взрослом фреймворке )

Делай стрим с донатами на еду

на камеру я был бы очень уныл. а за стрим текста в чатики пока никто не донатит

Стрим кода + тебя) норм, лайвкодинг многие устраивают

всё что касается говорения у меня всё с этим плохо

я мечтаю о формате уровня https://www.youtube.com/watch?v=EdejtjXEhzs но програмисты слишком плавают в программировании чтобы воспринимать архитектурные решения эмоционально

Надо работать, а не мечтать )

Надо работать, а не мечтать )

Нет, не так. Надо работать и мечтать 🙂

СкролТу это известный косяк роутера, они в курсе вроде как

проход по древу и состалвление flat map tree, т.е. списка асинхронных компонентов, которых нужно дождаться прежде чем рендерить сайт

невозможно

для этого надо вычислить состояние компонента

что аналогично рендеру

представьте что у вас v-if который рендерит один из двух компонентов

для того чтобы понять какой компонент надо асинхронно ждать - надо вычислить состояние v-if

которое может быть завязано на компьютерд, которые завязаны на data, которая завязана на пропсы пришедшие из компонента сверху

смерть в яйце, яйцо в зайце, заяц в утке, утка в шоке

😂😂😂

Получается, что если у нас в компоненте есть n вложеностей и у половины из них есть asyncData и в этих функциях есть что-то что возвращает данные, то все эти данные мы то получить можем перед рендером, но вот без vuex никак прокинуть в компоненты мы не можем. Да?

можем всякими странными хаками, но vuexв этом случае оптимаьлное решение

я тут обратился в англоязычный портал Reactiflux:

Hey guys! Long Story Short: We need Webpack to traverse the applications component tree during compilation and generate a flat dependency-tree-map for each view registered in the router, is this theoretically possible? Short Story Long: Currently SSR (server-side-rendering) support in Vue is implemented using an asynchronous hook called asyncData on components registered by the router. The problem is: this only allows for smart route-components (AKA "views" or "pages") exclusively, unfortunatelly there's no way to make any component beneath the views become smart. The view becomes responsible for fetching all the data and executing all asynchronous operations before the page is rendered letting the data flow down the tree of dumb components. This is far from ideal because usually you'd want to split up the application into multiple, independent, individual smart components, but instead, if you want SSR support, you have to make the view component "super-smart" and everything beneath it - just dumb, not good! The Idea: We need equality! Every component throughout the application should be able to perform some asynchronous operations before the page is considered ready and is finally rendered by the server. Therefore we need to compose a component dependency-tree. Though because it would be ridiculously inefficient to traverse the tree of components for a certain view everytime the Node.js server renders the application it must be done during the compilation process, and that is where Webpack comes to my mind. Webpack must traverse the entire component tree and create some kind of a flat dependency-tree-map, which is then kind of "exported" to the JavaScript that's executed on the server as well as on the client. This would allow the server to wait for asynchronous smart components to finish their async work before the page is rendered and the resulting HTML is returned to the client. What do you guys think about it? Please let me know 😉

можем всякими странными хаками, но vuexв этом случае оптимаьлное решение

Гряный хак это переписать функцию renderToString?

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

для того чтобы понять какой компонент надо асинхронно ждать - надо вычислить состояние v-if

весомый аргумент, а разве webpack не может запустить render да вычислить?

как здесь делают - https://github.com/fenivana/vue-ssr-boilerplate/blob/master/src/shared/ssrMixin.js

весомый аргумент, а разве webpack не может запустить render да вычислить?

рендер это уже рантайм

чтобы запустить рендер надо создать инстанс компонента, чтобы создать инстанс компонента надо запустить зависимости

это все уже совсем не "compile-time"

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

(залогинен или нет)

все, приплыли

компайл тайм бесполезен

как здесь делают - https://github.com/fenivana/vue-ssr-boilerplate/blob/master/src/shared/ssrMixin.js

этот грязный хак кстати неплохо работает))

неплохо но очень опасно

мы с этим сталкивались на проекте

А они этот INITIAL_COMPONENTS_STATE на контекст вешают на сервере?

когда у нас "тикало время" в одном из компонентов - в итоге всякие интересные побочные эффекты, когда на сервере рендерился еще обратный отсчет, а на клиенте уже "войти в игру" (по честному, просто время пришло) - дерево компонентов не совпадало

Получается, что если у нас в компоненте есть n вложеностей и у половины из них есть asyncData и в этих функциях есть что-то что возвращает данные, то все эти данные мы то получить можем перед рендером, но вот без vuex никак прокинуть в компоненты мы не можем. Да?

суть asyncData не в том чтобы вернуть данные, а в том чтобы сообщить выше стоящему компоненту что мол "я готов!"

вообще asyncData неправильное название для этого хука, правильнее было бы просто async

нельзя )

ключевое слово. И хоть его можно использовать в имени методов - это плохой тон

async async() { ... }

async async() { ... }

ну можно хотя бы asyncReady, ли ещё как, но не asyncData, ибо это даёт людям ложное представление о том, что asyncData должен вернуть какие-то данные

на самом деле он просто должен зарезолвить возвращаемый Promise

вообще-то в канонической интерпретации он возвращает данные

https://nuxtjs.org/api/

The result from asyncData will be merged with data.

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

да, я понимаю, думаю как можно решить вопрос с v-if

на самом деле он просто должен зарезолвить возвращаемый Promise

Резолвя этот промис мы понимаем что в vuex произошел action. Собственно там появились данные. Которые мы будем использовать при рендере

да, я понимаю, думаю как можно решить вопрос с v-if

никак, v-if тьюринг-полон

соответственно нам нужно только запускать код

а раз он тьюринг-полон (а тьюринг-полон он банально потому что там может быть любое подмножество языка JS, а сам JS очевидно тьюринг-полон) -задача остановки для него неразрешима

https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%B0_%D0%BE%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B8

математика, бессердечная сука

убивает мечты программистов с 1936 года

😁👌🏻

щас бы чтобы обьяснить проблему несовладания с кодом тралировать тюринг машинами из начала века

компьютеды вон идеально работают несмотря на то что там может быть куча ветвлений

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

Можно точно сказать, что ничего не произойдет, если ничего не делать ))))

компьютеды вон идеально работают несмотря на то что там может быть куча ветвлений

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

и только от реактивных сущностей

@xanf_ua, окей.. я сейчас задам глупый вопрос, но мне, наверно, можно.. лимит глупости в чате пока не пройден, я счетаю. Почему не сделать отдельных хук, который будет позволять дальнейший рендер компонента только после его резольва? Тогда код станет понятней. И каждый сам себе выберет, что там делать, наполнять стору или локальный стейт. Мы одинаково ждем резольва всех вложенностей на сервере. И только тогда рендерим. Условно мы потереям в скорости, так как через промис олл, отправленные на разные апи запросы зарезолвятся все быстрее, но стандартно в 90% мы фетчим всё с своей родной апишечки...

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

Вспомнил async внутри computed )))

@xanf_ua, окей.. я сейчас задам глупый вопрос, но мне, наверно, можно.. лимит глупости в чате пока не пройден, я счетаю. Почему не сделать отдельных хук, который будет позволять дальнейший рендер компонента только после его резольва? Тогда код станет понятней. И каждый сам себе выберет, что там делать, наполнять стору или локальный стейт. Мы одинаково ждем резольва всех вложенностей на сервере. И только тогда рендерим. Условно мы потереям в скорости, так как через промис олл, отправленные на разные апи запросы зарезолвятся все быстрее, но стандартно в 90% мы фетчим всё с своей родной апишечки...

а кто мешает сделать это самому

но это не отменяет проблемы рендера дерева чтоб собрать все компоненты

Интересная вики ссылка. То есть sync просто не существует?

Все есть промис )))))

Программа не может, не запустившись, эмулировать собственный запуск ))

все есть обзервабл

а кто мешает сделать это самому

Мне мешает время понимания внутренности vue и в js я может месяцев пять, колупать буду долго. Но вот когда они решали реализацию ssr кто-то же предложил сделать заворот так как он есть сейчас, хотя могли бы сделать два пути. Не одни же мы тут уперлись в стейт отдельного компонента

никто не выдумывал ничего

сср в реакте )

взязли скопировали

Так и что нам в итоге остаётся? Юзать vuex вместо локального стейта для корректного ssr?

конечно

а вы об этом. ну это очевидно потому что сср не может в реактивность а не про какоето дерево

а асинкдата вызывается в контексте beforeRouteEnter и она же имеет доступ только к стору, разве нет ?

она не имеет доступа к компоненту

В реактивность может бродкаст, но поисковикам пох на это