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

Make API more Dart-y #99

Open
MarcelGarus opened this issue Apr 30, 2020 · 2 comments
Open

Make API more Dart-y #99

MarcelGarus opened this issue Apr 30, 2020 · 2 comments
Assignees
Labels
challenge accepted Enhancement or feature request accepted enhancement New feature or request good first issue Good for newcomers

Comments

@MarcelGarus
Copy link

MarcelGarus commented Apr 30, 2020

I like the distinction of telegram and teledart – one is a simple typed wrapper around web requests, the other one a full-fledged powerful API that uses the capabilities of object-oriented programming. Some aspects like the inline mode are really great, but I think other parts could be a bit better.
For example, most requests still need to be made through the teledart instance with the exception of replies. I'd love it if you could simply send a message to a chat if you got hold of the Chat. Something like chat.send('Some text.').
Also, most fields currently have the name from the API in snake_case instead of using an adapted camelCase version. The typing could also be a bit stronger. For example, we could create a ChatId class to represent a reference to a Chat. Then we could do stuff like this:

final id = someMessage.chat.id;
final chat = await id.resolve();

We could also introduce classes for several other concepts to make them type-safe. Take photos for example. Currently, the telegram.sendPhoto function accepts dynamic as a photo and developers are forced to go to the Telegram API documentation to find out what they can send, but we could also create a Photo class which gets subclassed by PhotoUrl, and PhotoFile. Users could then create photos using Photo.fromUrl(…) and Photo.fromFile(…) constructors, which makes the API easier to use and explore.

Let me know what you think about this. I'd be happy to help implementing these changes.

@MarcelGarus MarcelGarus added the enhancement New feature or request label Apr 30, 2020
@DinoLeung DinoLeung added good first issue Good for newcomers challenge accepted Enhancement or feature request accepted labels May 1, 2020
@ghost
Copy link

ghost commented Jan 29, 2021

Nice. I'll fork the repo and start working on this. Telegram FTW! #WhatsappOff

@elhe26
Copy link

elhe26 commented Feb 13, 2021

We also need to work on the documentation.

This was referenced Jan 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
challenge accepted Enhancement or feature request accepted enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants