Please support ContextFunc<string> in type of questionText

Now questionText just support string.

Please support ContextFunc<string> in type of questionText too.

[Ramin-Bateni]

@EdJoPaTo I understand what you say and I have faced with this situation in developing my bots in the past years.

So I have a solution for you! I use my Technic to have stateless ability in reply-to-question situation while the question can have dynamic data.😎

---

My Technic: I generate a unique sign (a random string) and inject it to the End or Beginning of the question.

For example:

Step 1

Text of question »» What is your name? Generated Sign »» #sE1R2w Step 1 result »» #sE1R2w What is your name?

Now we go ahead and hide the sign by this way:

Step 2

function signQuestion(sign,text){
    signUrl = 'http://wwww.wwwwwwwwwwww.www/';
    signTextLink = `[\u200c](${signUrl}${signTextLink})`
    return signTextLink + text;
}
let finalQuestion = signQuestion('#sE1R2w','What is your name?');

Step 2 result »» [\u200c](http://wwww.wwwwwwwwwwww.www/#sE1R2w)What is your name? What the user see finally if we send the message with markup support »» What is your name?

Step 3

OK! That’s it…👌 Now we can easily check the sign of question instead of text of question when we have reply_to_message:

if( ctx.message.reply_to_message)
{
   const sign = getSignOfMessage(ctx.message.reply_to_message)

    // Now here we check the sign of reply_to_message NOT the text of reply_to_message ;)
   if(sign == ........){
   }
}

function getSignOfMessage(msg){
    const signUrl="http://wwww.wwwwwwwwwwww.www/#";
    let sign;
    f(msg.entities)
    {
        const e = msg.entities.find(i=>i.type=="text_link" && i.url && i.url.indexOf(fakeUrl)>0)
        if(e){
            sign=e.url.substr(e.url.indexOf('#'))
	}
    }
    return sign;
}

[EdJoPaTo]

In order to detect its an answer the library currently checks for the reply_to_message. It has to have the exact text as questionText provided on startup.

As this check of the replied message is done on every message coming in it is performance critical.

Also when the result of the function would change between the user hitting the button and the response of the user the library would not be able to detect the users reply at all. the user would be stuck. This is why I chose to prefer an always the same questionText.

The menu in general uses the callback_data which allows this library to be stateless (the only states are from the Telegram and the functions asking or the state (like hide)). Normal Text messages do not allow for this kind of statelessness which makes them feel wrong in the context of this library. 😔