Support parsing methods as well

[valscion]

Oh well, I guess I really wanna go head first to tackle #2 😄

This PR starts off with a proof of concept to see if I can get any output for method parsing. Turns out there doesn't seem to be much left to do to get some output that is actual working code

[sergeysova]

😆

[valscion]

Yeah I just tried to get the parser going 😄

This was funky to run on the API website in developer tools console:

Array.from(document.body.querySelectorAll('body table'))
  .map(table => [table, table.querySelector(':scope tr:first-child td:first-child')])
  .filter(([_, el]) => el.innerText === 'Parameters')
  .map(([table, el]) => {

let elTry = table;
for (let i = 0; i < 50; i++) {
  elTry = elTry.previousElementSibling;
  if (elTry === null) { return null; }
  if (elTry.nodeName === 'H4') { return elTry; } 
}

}).map(heading => heading.innerText)

I wanted to see if the same approach of finding names would work, and seems like it does 😄

[valscion]

Any ideas on how to progress with this? If you feel like you have ideas, now that you have invited me to contribute I can also push this branch to this repository and let you figure things out as well :)

I'm mostly interested in getting this feature supported and am not looking for glory, so I don't mind if you come up with a better idea 😄

[sergeysova]

I think, Store and Builders should be refactored:

• Add collection of types and methods
• Add support for methods in builders (not for rust)

store.types.get('SomeType')

const method = store.methods.get('methodName')
method.name // methodName
method.arguments // array of { name: 'foo', type: FooType }
method.returns // ReturnType

To parse methods, parser should be improved:

• Parser should correctly distinguish method from type (first column in types "Field", in methods "Parameters" and column "Required")
• Correct parsing return type from Returns a UserProfilePhotos object. and Returns true. https://core.telegram.org/bots/api#getuserprofilephotos
• Correct parsing InlineKeyboardMarkup or ReplyKeyboardMarkup or ReplyKeyboardRemove or ForceReply to union of types
  ....

Other cases maybe covered by exists parser.

[valscion]

Yeah. I might get to this tomorrow, it's getting quite late here (its 0:21 past midnight right now) so I'm gonna close my laptop for now.

I managed to hack together even more crappy code to get some types that actually would work together 😅

Let's see where this will go later. Good night!

[valscion]

Oh yeah my hack didn't touch these declarations at all. Only their references 😝

[valscion]

Such pretty type name. I guess we will really want to have chat_id: number | string here? As Integer is a native type of number and String is a native type of string.

[sergeysova]

In this case, I agree

[valscion]

And here we will want to have:

reply_markup: InlineKeyboardMarkup | ReplyKeyboardMarkup | ReplyKeyboardRemove | ForceReply

As the description says "Optional", should this then be

reply_markup?: InlineKeyboardMarkup | ReplyKeyboardMarkup | ReplyKeyboardRemove | ForceReply

right?

[sergeysova]

Yes

[valscion]

Closing in favor of #18