Парни, что бы юзать Вью - нужно перед этим учить вебпак? ;)

В плане, обязалова? ;)

Я учил, потом забыл, потом взял vue-cli, но ничего не вспоминал

Короче стандартный сборщик справлялся с поставленно задачей))

Не нужно Разбирайся поэтапно)

Борисов Дмитрий, фрилансер, занимаюсь VoIP, сообщество интересно тем, что на Vue пишу интерфейсы для АТС, активно использую Quasar-framework, Москва, устная рекомендация

Если кому нужны вебсоскеты, то вот https://www.npmjs.com/package/wspromisify

const data = await socket.send(response)

и куча плюшек

@houd1n1 какое то отношение имеешь?)

посмотри на ник

тут и там

)

а

ок

попробуй 1метр данных отправить

и принять

туда сюда

ну даже 500кб

надо кое что проверить

@houd1n1 я не ради настроение испортить

просто полтора года назад тоже в сокеты пришлось закопаться

в итоге нашел так сказать границы у браузеров

ну я прилично гонял по этой схеме, щас ток рассекретить решил на днях

большие джейсоны?

@houd1n1 https://github.com/astr0junk/backbone.WSR/blob/master/backbone-wsr.js

просто вот к чему пришел

и строчки

чанкинг и бафферинг

исключает лимиты по буферу в браузере на сокете

это покусочные данные

стрим

угу

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

эту тему тоже хочу воткнуть, но пока хз как, т.к. если в этом кейсе оставить тот же апи, то профита использования части данных что уже пришла не будет

почему?

ну у меня куча кучная кейсов с небольшими чанками а-ля одновременное редактирование

погляди код

суть та же

каждое сообщение имеет промис колбэк

просто транспорт другой

по поводу апи у меня ожидание await пока не придёт фрейм

в целом понятно, но это разбиение

?

всмысле?

как обход для больших месседжей ок

но есть у тебя, допустим, картинка

давай иначе - ты как хочешь что бы вело себя?

так

и ты хочешь по мере получения её частей отрисовывать

оч грубо, т.к. эт овряд ли быа бы картинка)

а почему не получить всю быстро?

без блокирования следующей?

т.е. если мы ждём конца потока в простом виде промисов, то утрачиваем возможность обрабатывать его кусочки

надо как-то совмесить

а и будет без блокирования как утебя

просто если мы разбили на N частей

то приходит сначала 1, потом 2 ... N

то пока у нас грузятся 2 до N

мы могли бы как-то поработать с 1

ммм

ну да в стриме куски не подпишешь

надо добавить buffer_size для больших сообщений, который по дефолу null и не режет, например. И какую-то тему сразу заодно чтобы можно было чанки читать. Мб через колбеки или какие-то промежуточные резолвы...

да подписать-то изи

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

а вот красивый апи сделать как щас чтобы куски юзать

ERROR: S client not available

ab2str

это филосовский вопрос

str2ab

потом в чанке читается реквест айди

можно по нему идентифицировать

Ага, вижу

по нему понимать от какого реквеста кусок, и к какой части данные мерджить

но это тоже тех.вопрос

причём простой

а вот как бы так чтобы чанки отдельно юзать и чтобы авайт было?

а почему нельзя отдельно юзать?

допустим у нас есть сообщение {a: ‘b’, c: ‘d’}

сначала отдаем первое проперти потом второе

на каждое получение делаем мердж объекта

или я чего то не пойму..

А что резать надо -- это кейс. В родмапу)

это подкапотное

с каким куском данных ты хочешь уже начинать работать?

сейчас юзер-прогер делает так: data = await ws.send(123)

я вот что не пойму

далее работает с data

в одну строчку

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

ну там, клеточный автомат

так

20Мб

и допустим мы знаем что это пиксели

так?

хотим чтобы поле отрисовывалось по мере загрузки

авайтом так просто не справиться)

как оно для юзера-прогера будет?

выглядеть