api.new.get.email_data is giving null.

[anilreddyr7]

Earlier I was using api.get.email_data to get email data. If I see newer gmail.js, it is suggested to use new.get.email_data as get.email_data is a deprecated Gmail API. How to use this function? If I invoke new.get.email_data instead of get.email_data, it is giving me null .Can you please help me out how we can get the data using new method? Do we have any sample code snippet?

[josteink]

The new APIs are definitely not documented. That’s something we should look into fixing.

Let me see if I can make some quick examples sometime later this week.

[wnateg]

For me, it seemed to work more often if I checked for the data periodically. I didn't check the code to verify there was any evidence to support this, but it worked with trial and error.

var i = 0, interval = setInterval(function() {
	var dataNew = gmail.new.get.email_data(msgId);
	if (typeof dataNew === undefined || ! dataNew) {
		console.log(i, dataNew);
		return (++i) > 60 ? clearInterval(interval) : true;
	}
	console.log('data found');
	clearInterval(interval);
}, 500);

[josteink]

With the new APIs we don’t actually “get” the email, but rather gmailjs intercepts and caches all emails gmail processes. When you request an email, you will only get it if it is found in the cache.

For any random email Id, it will probably fail. For an email on screen it should succeed.

Hope this helps.

[anilreddyr7]

With the new APIs we don’t actually “get” the email, but rather gmailjs intercepts and caches all emails gmail processes. When you request an email, you will only get it if it is found in the cache.

For any random email Id, it will probably fail. For an email on screen it should succeed.

Hope this helps.

Thanks for the update. It is already 2019, but still old method gives proper email data. I'm not leaning towards new method. Because I'm worried about intercepting gmail process and getting email data. Will Google definitely block old gmail request to fetch email data?

[josteink]

Thanks for the update. It is already 2019, but still old method gives proper email data.

While testing New Gmail while it was in closed beta, any kind of XHR on our part seemed to fail, and thus the all the get.email_data() too methods.

The document's we received clearly stated "early 2019", whatever Google means by that.

As mentioned in the original issue, the test-instance of new Gmail we receieved (while it was still in beta) had issues with our old XHR-requests. This was what prompted us to write new code, using a non-XHR based methodoly.

As also mentioned in that thread, we now have to deal with new Gmail on -2- levels. Can you verify in your old-and-working case what api.check.is_new_data_layer() and api.check.is_new_data_layer() returns?

I'm not leaning towards new method. I'm worried about intercepting gmail process and getting email data.

And as stated in that thread, it's not a 1-to-1 drop-in replacement. And we can't make 1-to-1 drop-in replacement either. If you need that, we can't help.

Could you outline those worries a bit more? Can you provide some real-world code samples and use-cases where you don't get the data you need?

It would be easier for me to help out and discuss if I had something more concrete to look at. Your exampple above seems a bit... Contrived :)

[josteink]

I've also updated the gmailjs-boilerplate project to include a working example using the "new" API.

Take a look here: https://github.com/josteink/gmailjs-node-boilerplate/blob/master/src/extension.js

This example works consistently for me. Do you have any issues with that code on your end?

[josteink]

No feedback provided on the last comments.

Unless I'm provided a concrete code-example of the new API failing, I'm considering this issue closed.

[icyrizard]

@josteink Just want mention that I am experiencing the same issue. I will need to dig into what is happening exactly, but as far as I see it is that the 'Cache' that is used to retrieve the email from is empty, and remains empty.

I failed using your injection script. I would just not load the Gmail script. Mainly because 'require' is not supported by the browser. I specifically see in the README that Gmail-js is not working as a content-script, that is pretty confusing to me as it should interact with the DOM...

For a full debug session I would need to share a lot more, but do want to prevent closing this issue because I am experiencing these problems. See the screenshot attached for a bit of debug info.

FYI, it probably has to do with the injection. But how you actually inject Gmail plugin is not straight forward, the specified demo's do not work for me. It simply contains code that is not able to run in the browser due to the modern JS constructs used.

[josteink]

So many misconceptions here... So let's start by clearing them up.

I failed using your injection script. I would just not load the Gmail script. Mainly because 'require' is not supported by the browser.

This is why you run "npm run build" which uses browserify to bundle those require-statements into one single file, which does not contain "require".

I specifically see in the README that Gmail-js is not working as a content-script, that is pretty confusing to me as it should interact with the DOM...

Which is what the injector script does: It injects the bundled file (dist/extension.js) created by the build-process into the regular DOM.

Really: Please read the full boilerplate README at least, and check the minimal code-example there (which is working) before trying to build something more complex on top. It will save you time.

Now for your other issues... Thanks for the screenshots. They were very illustrative!

As noted in the documentation for api.new.get.* all of these functions requires new style email- and or thread-ids. In your example you are clearly using a legacy ID. This will always return null, because no new-style email-object has legacy-style IDs.

Again, please check the minimal example provided in the boilerplate project how to resolve this. It's not very hard.

I guess... I could add code to the new api.new.get.* function to simply throw an error on wrong email-id format. It might help clear things up earlier...

[icyrizard]

@josteink Amazing, thanks for clearing that up, I did not know about the browserify method that was running upon the build command. The problem is that I've started a browser extension project using: https://github.com/yeoman/generator-chrome-extension . After that I tried to incorporate your code into my existing project, there it went wrong I presume. So I will need to check copy the build code of your boilerplate code. I totally missed the build step, I see that now.

Thanks man, I'll check what reason is that I get the old id format, as Im getting the domEmail. And from that I'm getting the 'id', why would it give the old id format, if that 'does not exist'?

As for the comments, "It's not that hard", is always easy to say if you know all the ins-and-outs, I have made the comments to people far too much... But you have to see I've just discovered this AMAZING gmail extension yesterday, and I know that if I'm running into these problems, other people could be as well, so we can help each other out as fellow devs.

Thank again!

[josteink]

Thanks man, I'll check what reason is that I get the old id format, as Im getting the domEmail. And from that I'm getting the 'id', why would it give the old id format, if that 'does not exist'?

Simple: Compatibility.

There's lots of people and companies who have extensions who only use the old-style APIs, which still expect old-style IDs.

It's not very clean, but it was a hard enough job to get GmailJS working on new Gmail, and I simply didn't have the time to rewrite everything to be 100% backwards compatible and 100% future-proof at the same time.

Also, there are mixed reports about bigger companies/accounts still being on old gmail, despite "most" people being forced to new. That means, we cannot completely deprecate the old-style APIs just yet.

So basically: People having existing extensions will have to adapt some of their code. People writing new extensions will have to be careful about the IDs they obtain and use.

That's life.

[icyrizard]

👍 Good to know, thanks for the time man!

[josteink]

I've just pushed a new version (0.9.2) which automatically detects old-style IDs in api.new.get.email_data() and looks up based on legacy-ID instead.

Note: There's no guarantee this will keep working, so a console-warning IS generated, but it should make it less painful to migrate to thew new API.

Hopefully this helps all the people out there having issues.

[josteink]

I’ve pushed a new version (0.9.4) which also makes obtaining the right email-ID smoother.

Check the updated sample code in the boilerplate-project.

[josteink]

Errors in code reviewed and corrected. Improvements in GmailJS shipped. No new comments in almost a month.

Closing.