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