https://msdn.microsoft.com/en-us/library/bb397502.aspx

Creates an array from a string representation.

По ссылке разбор строки

ну дык да

сам аррей хз че там парсить там все и так распарсено уже

Кому интересно присоединяйтесь https://t.me/nest_ru

valor? ну уж нет

я еще за бутстрап не простил

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

А как ты это реализовал бы?

А как ты это реализовал бы?

я не бы а пошел и сделал через blur как нормальный человек

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

Лучше сразу расстреляйте

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

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

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

...args

.apply(this, arguments)

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

лучше не переопределять console.log

лучше не переопределять console.log

дай человеку спокойно отстрелить себе ногу

дай человеку спокойно отстрелить себе ногу

ненуачо

ненуачо

не, я ж ниче, отстреливай же :D

.apply(this, arguments)

Спасибо!

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

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

Спасибо!

Вредные советы

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

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

Лол

делать нг4 но при этом опиратьтся на легаси столетней давности - сомнительная практика

Напомни, на чём у тебя там фокус висит?

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

Напомни, на чём у тебя там фокус висит?

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

А, блин, не тот чат

но за хендлеры вне своего скоупа однозначно надо спрашивать сл юдей

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

эксперты вот мой тестовый стэнд: // server.js const http = require('http') const server = http.createServer(function(req, res) { res.write('1') setTimeout(() => res.write('2'), 1000) setTimeout(() => res.write('3'), 2000) setTimeout(() => res.end(), 5000) }) server.listen(3000) --- // client.js const http = require('http') const req = http.request( { hostname: 'localhost', port: 3000, path: '/', method: 'GET', headers: { 'Content-Type': 'application/json' } }, function(res) { // http.IncomingMessage res.on('data', chunk => { // ... }) res.on('end', () => { // why emits end if I kill server? console.log('END') }) res.on('close', () => { console.log('CLOSE') }) } ) req.on('error', err => { console.log('req error') }) req.end() при успешном чтении с потока res, эмитится событие end - ОК при обрыве (просто прибить сервер пока он не отдал все данные) тоже эмитится end, и только потом уже close - НЕ ОК. судя по доке на readable потоках end должен эмитится только при успешном завершении тоже самое работает как положенно на серверном req (http.IncomingMessage) Как мне отличить успешный/не успешный кейс?

res.on разве у него нет события ошибка?

нет

req.on('error', err => { console.log('req error') }) Не срабатывает хочешь сказать?

читай внимательно))

res != req

Сек, аж интересно стало. Ща у себя заведу

Мне для теста надо прихлопнуть сервер да?

да

Жизненно

Пишут что клоуз это как раз факап https://stackoverflow.com/questions/6572572/node-js-http-server-detect-when-clients-disconnect

Счас ищу в доке что к чему

это пример сервера же

и на сервере req http.IncomingMessage отрабатывает корректно, обрыв close, успех end

https://nodejs.org/api/http.html#http_event_aborted

Вот

aborted подпишись

ну эт понятно что есть aborted, хотя непонятна разница между aborted и close. Поведение все же странное.

The 'close' event is emitted when the stream and any of its underlying resources (a file descriptor, for example) have been closed. The event indicates that no more events will be emitted, and no further computation will occur. **** The 'end' event is emitted when there is no more data to be consumed from the stream. Note: The 'end' event will not be emitted unless the data is completely consumed. This can be accomplished by switching the stream into flowing mode, or by calling stream.read() repeatedly until all data has been consumed. *** Event: 'aborted' Emitted when the request has been aborted and the network socket has closed.

Note: The 'end' event will not be emitted unless the data is completely consumed - обрыв значит что данные не completely consumed противоречие в доках какое то

Разные уровни абстракции если можно так выразиться. Аборт и клоуз относятся к стриму, энд сигнализирует об окончании данных

я смотрю сорцы аксиоса адаптера к ноде, они вообще не заморачиваются: https://github.com/axios/axios/blob/master/lib/adapters/http.js#L185

только end и error который вероятнее всего хэндлит ошибки из zlib

Доку тоже люди пишут

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

const axios = require('axios') axios .get('http://localhost:3000') .then(res => console.log(res.data)) .catch(err => console.log(err))

т.е даже такой кейс считается успешным)

модуль request из npm такое же поведение

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

СТранно, если писали не дураки, тогда зачем они подписываются на ивент которого нет? https://github.com/axios/axios/blob/master/lib/adapters/http.js#L180

https://github.com/axios/axios/blob/master/lib/adapters/http.js#L147 хочешь сказать у zlib нету error?

вот если что: https://github.com/nodejs/node/blob/master/lib/zlib.js#L137

Ну на злиб они переходят только в отдельных кейсах, а http.IncomingMessage вроде как не емитит эроры

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

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

https://github.com/nodejs/node/blob/master/lib/_http_incoming.js

Или это какой-то другой Инкам

Напишешь аксиосам что они мудаки?

это тот самый

я пока не уверен что мудаки они а не я)

Точно не я

Но видимо все надеются на лучшее

Аксиос читает req.aborted пропертю но это не то что им надо. Вернее не на 100% то

важно когда abort вызывается

timeout и cancel

интересно: https://github.com/request/request/blob/master/request.js#L994

кто работал с телеграм апи отправке кнопок в таком формате должен быть json { chat_id: messageObj.chat.id, text: text, reply_markup: {ReplyKeyboardMarkup: {keyboard: [[1, 2, 3], [1, 2, 3]]}} } ?