How is gmail.new.get.* a replacement for gmail.get.visible_emails()?

Hi, thanks for the library! Let’s say I need to programmatically select some emails on the users currently visible list of emails. gmail.get.visible_emails seemed like the right thing but I see it’s deprecated and I’m advised to use gmail.new.get.* instead.

I don’t see which of these is a replacement for that method though: email_data email_id thread_data thread_id

none of these return the list of emails as far as I can tell. Perhaps I’m misunderstanding, how exactly are those a replacement?

How would you advice getting the list of emails so I can select them. Should I use gmail.dom.inbox_content() and then find the rows that have checkboxes?

I will be happy to contribute to the library and help maintain, as I am working on a project that could potentially use this!

[josteink]

How is gmail.new.get.* a replacement for gmail.get.visible_emails()?

Good question! It isn’t. Yet.

none of these return the list of emails as far as I can tell

Correct.

how exactly are those a replacement?

api.new.get.email_data() and api.new.get.thread_data() replace api.get.email_data() in the sense that api.get.email_data() will stop working, and those hopefully wont.

All other variations of api.get.*_email_data() are ultimately based on api.get.email_data() and will eventually stop working too.

What that ultimately means is that we’ve managed to provide decent replacements for api.get.email_data(), but not its contextual siblings.

How would you advice getting the list of emails so I can select them.

Use some jQuery/DOM selector magic to extract the new style IDs which represents visible emails, selected emails (or whatever) and use the new-style API to get data about those.

Should I use gmail.dom.inbox_content() and then find the rows that have checkboxes?

If that works, great. Maybe you can inspect its code and see if there’s room for optimizations when those two actions are combined too?

I will be happy to contribute to the library and help maintain

Sounds good. If so, PRs are definitely welcome.

This is a open-source library and any functionality currently present in this library has been provided by contributors like yourself scratching your own itch.

I scratched my own itch, which was the general reverse-engineering required for api.new.get.email_data() and api.new.get.thread_data(), which was no small task let me tell you.

If you can base your code on those, and extend the API with new methods like api.new.get.visible_email_data() or api.new.get.selected_email_data() that would be great and I’ll be glad to review and merge those PRs.

[mikob]

Makes sense. I’ll stay away from localized text, but still try to use other semantic props.