Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please support ContextFunc<string> in type of questionText #44

Closed
Ramin-Bateni opened this issue Oct 4, 2019 · 5 comments
Closed

Please support ContextFunc<string> in type of questionText #44

Ramin-Bateni opened this issue Oct 4, 2019 · 5 comments
Labels
enhancement New feature or request

Comments

@Ramin-Bateni
Copy link

Now questionText just support string.

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

@Ramin-Bateni Ramin-Bateni added the enhancement New feature or request label Oct 4, 2019
@EdJoPaTo
Copy link
Owner

EdJoPaTo commented Oct 4, 2019

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. 😔

@Ramin-Bateni
Copy link
Author

Ramin-Bateni commented Oct 11, 2019

@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
Copy link
Owner

An interesting approach!

One thing that came to mind: Telegram checks the urls and tries to generate Link Previews. Having an url in there will trigger the same. This might require a non existing url (which will for sure non existing). Something like http://::1/#signText might work. Using IPv6 localhost is short and should be non existing on Telegrams Crawlers. Also its fast for them to check localhost → less servers involved.

In order to have this stateless the signText has to be supplied to the question by the user of this library in order to have it always the same for this question. Random will result in changes on each restart. This library shouldn't break menu stuff just by restarting the bot.

@Ramin-Bateni
Copy link
Author

Ramin-Bateni commented Oct 15, 2019

@EdJoPaTo , Thank you for your points. That's why I used http://wwww.wwwwwwwwwwww.www/ in my comment to prevent Telegram link previews. But if your ideas works we can use them too. ;)

Yes, I means each question should have a unique sign that can be generate from a random text once and be fixed for the question.

But I think there is a better way instead of getting the sign from the user as a separate argument :

We can use the text of the action (full-action) of the question method for the value of its sign!

For example:

sign = '#'+'main-menu:my-question';
or
// encrypt the full-action » If we dose not want embed text of actions of the bot in the client side (in the messages)
sign = '#'+MD5('main-menu:name-question')

@EdJoPaTo
Copy link
Owner

EdJoPaTo commented Nov 1, 2019

I used t.me now as it is relatively short and has no previews when it has no user / group username. Sadly its not that easy to use the full action code as uniqueIdentifier so I just added it as a required option. Simpler to add and does its job too.

Thanks again for this idea how to approach it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants