Pull to refresh

Comments 11

А $.waitForRequest() не будет срабатывать на другого пользователя?
А аргументы replyTo, selective и др. есть возможность передавать?
API обертки все же сильно ограничен по сравнению с node-telegram-bot-api, начиная от того, что не возвращает Promise (это очень удобно позволяет делать сложные конструкции из асинхронных функций), заканчивая очень ограниченными функциями sendPhoto и прочих (почему нельзя задать имя файла и произвольный mime?).
Так же не вижу в коде какого либо показа отладочной информации, если что то пошло не так.
Я тоже являюсь автором пары ботов с аудиторией 100+ человек, и со временем пришел к выводу что на callback'х далеко не уедешь.
Спасибо за замечания, про ограниченность обертки вы, наверное, правы и я буду дорабатывать ее в следующих версиях. Насчет Promise: мне кажется тут у всех свое мнение, кому-то они нравятся, кому-то нет. А для сложных конструкций у меня есть функции waitForRequest, waitForRequest и runMenu.
Вот простой кейс из моего бота — бот отсылает фото, и бывает, что API глючит, бывает что картинка битая, бывает что бота кикнули из чата. Так вот, нужно сделать, в зависимости от ошибки повтор отправки сообщения (более 1 раза возможно), нужно удалить пользователя и взять следующего и попробовать повторить (если кикнули), нужно отослать текстовое сообщение с ссылкой на картинку (если все совсем плохо).
Таким образом, если попробовать построить подобное на collback'х то можно очень сильно запутаться. Я даже и не знаю что кроме Promise тут может помочь.
Или же, банальное — есть лимиты на отправку сообщений в секунду, надо уметь считать сообщения на уровне обертки, что бы не превысить лимиты и если они превышены — отправить через секунду. Тут тоже Promise отлично решает задачу.
Это холиварный вопрос, но все же. Чем вас не устраивают промисы? По скорости bluebird реализация почти такая же, как коллбэки, а удобнее в разы.
Плюс на промисах базируется async-await, который уже в stage 2.
Хорошая идея поддерживать промисы. При этом отличная мысль — поддерживать их одновременно с колбеками, чтобы действительно каждый работал так как нравится.
А как решается проблема получения сообщений в групповых чатах? Включаете setprivacy и смотрите весь поток сообщений? И еще момент. Допустим, один из участников группового чата послал команду. waitForResponse будет ждать следующей информации именно от этого же участника, или будет рассматривать любое первое пришедшее сообщение как информацию?
Честно говоря задача написания ботов для групповых чатов не стояла. Функция waitForRequest будет ждать информацию от любого участника беседы, но, я думаю, будет не сложно отфильтровать нужного по $.user.id
#Дуровпозвонит )))

Спасибо за статью, обязательно попробуем. К статейке очень не хватает скришотов, чтобы понимать, что получается в итоге — кнопки вместо клавиатуры, или кнопки экранные. Пример той-же получившейся «формы» — это, я так понял, последовательные вопросы?
Спасибо!
Only those users with full accounts are able to leave comments. Log in, please.