Gatsby: [gatsby-plugin-twitter] Not consistently working

[fk]

Excuse the vague issue title, haven't had the time to look into the code actually, so all I can do for now is report what i observed: On gatsbyjs.org, navigating from the homepage to "Blog", then to "Announcing Gatsby 1.0.0", tweets are rendering fine. When going back to "Blog", and then accessing that article again, things aren't working any more:

Adblockers and related stuff that might block Twitter's widgets are off. I suppose this is an issue with gatsby-plugin-twitter because on https://www.yisela.com/computer-generated-poetry/ I observe a similar behavior – only tweets do not render more often than they do over there, and I can not really reproduce a certain behavior like on gatsbyjs.org.

[KyleAMathews]

This is the relevant code https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-plugin-twitter/src/gatsby-browser.js

Perhaps a setTimeout there would help? Perhaps twttr.widgets.load() is called sometimes before the page is fully rendered.

[KyleAMathews]

Though if that's the case, we should make sure onRouteUpdate isn't called before rendering is complete.

[KyleAMathews]

This still a problem?

[fk]

Hey @Anaizing, would love if you could take a look!

Have you seen https://www.gatsbyjs.org/docs/how-to-contribute/#contributing-to-the-repo? Following this guide, you can set up local development and test your changes to gatsby-plugin-twitter by pointing https://www.gatsbyjs.org/packages/gatsby-dev-cli/ to your local clone of the Gatsby monorepo.

[backlineint]

I've run into similar behavior on my Gatsby site - twitter embeds with the plugin don't seem to load reliably. A setTimeout does seem to resolve the issue.

[KyleAMathews]

@backlineint are you on the latest Gatsby? I recently made a change so that onRouteUpdate is only called after a setTimeout of 0 finishes which should ensure that React has flushed to the DOM already.

[fk]

Oh, seems @Anaizing deleted her comment. :-(

gatsbyjs.org is looking fine. 👍
Will update yisela.com and report back!

[fk]

Updated yisela.com but still seeing it ~50% of time when accessing https://www.yisela.com/computer-generated-poetry/ directly (as opposed to navigating to that page e.g. from the home page). But my eyes are a bit heavy—will check tomorrow.

[backlineint]

I wasn't on the latest Gatsby, but when I updated (npm update gatsby would cover me, right) I'm still seeing the issue.

Digging in a little bit more though, I'm starting to think there is something a little more specific going on here. Locally, I'm seeing the following error in the console when the twitter embed doesn't load:

ncaught SyntaxError: Identifier 'o' has already been declared
    at s (content_script_bundle.js:1)
    at content_script_bundle.js:1
    at content_script_bundle.js:19
    at s (content_script_bundle.js:1)
    at o (content_script_bundle.js:1)
    at Object.<anonymous> (content_script_bundle.js:1)
    at content_script_bundle.js:19
    at content_script_bundle.js:1
    at Object.<anonymous> (content_script_bundle.js:19)
    at Object.1134 (content_script_bundle.js:19) 

I see the same thing on https://www.yisela.com/computer-generated-poetry/ when the embeds don't load. But I'm only seeing this in Chrome. And when I load in an incognito window the embeds work fine. So that tells me it might be some combination of browser extensions that cause this (best guess for me is the Ghostery ad blocker)

So that makes it seem like an edge case to me. @fk not sure if you're seeing this on all browsers.

[fk]

Haven't checked today yet, but will in an hour or so (unless I end up buying Celeste—just dropped by your blog ;-)). I think to recall that in an icognito window things did work "less" for me.

But yeah, I hear you on Ghostery…I remember some things from a few years ago that also where a "symptom" of having that extension running. 😄 Given the context that makes so much sense. I'm not running any adblockers in FF and Safari, and the behavior in those is also ~50%/50%… 😁

[fk]

@backlineint Double- and triple-checked (which of course doesn't necessarily mean anything) and can't reproduce the error you're seeing in the console. :-/

Was a little under the weather yesterday 🤒, but today I upgraded yisela.com to the latest Gatsby (v1.9.192) and checked again. Here's what I saw, tried, and concluded:

1. Tweets on https://www.yisela.com/computer-generated-poetry/ render nicely when I unregister the Service Worker for yisela.com (via Chrome devtools/Firefox's about:serviceworkers).
2. _Reloading_ that page after the Service Worker installed itself again, the tweets don't work anymore.
3. Navigating back to https://www.yisela.com/ and from there accessing the article at https://www.yisela.com/computer-generated-poetry/ and tweets render as expected.

I took a quick detour and removed my homecooked <RouteTransition> component because I thought that could be interfering, but the described behavior persisted.

Then I remembered #2169 and disabled the app shell like #2170 does for gatsbyjs.org:

https://github.com/gatsbyjs/gatsby/blob/c0aa1679731325496b2758106ee9f63b7203afb4/www/gatsby-config.js#L99-L105

… and 🎉, tweets work.
I replicated the described behavior with the gatsbyjs.org source: When I remove the options for gatsby-plugin-offline, the tweets in the article at https://www.gatsbyjs.org/blog/gatsby-v1/ behave as described above.

So far, so good, but I do not yet know what to make of all of this. :-P

/cc @KyleAMathews

[rebelliard]

@fk are you aware of a workaround that doesn't break the offline mode in PWAs?

[fk]

Hi @rebelliard 👋 — no, unfortunately not. :(

[rojcyk]

This is still an issue, is there any update?

[deadcoder0904]

@fk in your above comment, you said tweets work. so what's the workaround?

[EQuimper]

I get it to work by making the timeout to 200ms. Less than that this is not working for me.

[deadcoder0904]

@EQuimper I got it working on my site. It doesn't work locally well. Only works sometimes but on Netlify it is working for me now

[EQuimper]

@deadcoder0904 Yes was like you too before but if I make it with a setTimeout of 200 he work 100% of the time :). Lower than that make it inconsistent

[deadcoder0904]

Yeah it must be because twitter.widget.js isn't loaded completely so after your timeout it loads

[EQuimper]

Yes I don't like this workaround but work for now :)

[jlengstorf]

This is fixed in v2 as soon as this PR merges: https://github.com/gatsbyjs/gatsby/pull/6777

[fk]

🎉 💪 💪 🙏

[EQuimper]

Thank @jlengstorf

[raae]

Will this be fixed in version1 as well?

[jlengstorf]

@raae If I understand the level of effort that went into the fix, my guess is that this will not be back-ported to v1. That being said, we are _really_ close to our first release candidate for Gatsby v2, and it's stable enough to use on most projects right now.

• v2 Epic <== works best if you have the free Zenhub extension installed
• v2 project
• v1 to v2 migration guide

[m-allanson]

This should be fixed in [email protected]

[raae]

I am working with [email protected] it still looks like onRouteUpdateis called before the page template's renderfunction. As far as I understand that means we cannot rely on onRouteUpdate to run scripts that transform the content since it will not be in the html yet.

[KyleAMathews]

@raae yeah — this is a bug related to the @reach/router PR https://github.com/gatsbyjs/gatsby/pull/6918

Working on fixing it right now

[raae]

I see, otherwise, I thought a fix could be something like this?

class TwitterComponentRenderer extends React.Component {
  runScript() {
    if (
      typeof twttr !== `undefined` &&
      window.twttr.widgets &&
      typeof window.twttr.widgets.load === `function`
    ) {
      window.twttr.widgets.load();
    }
  }
  componentDidMount() {
    this.runScript();
  }
  componentDidUpdate() {
    this.runScript();
  }
  render() {
    return createElement(this.props.pageResources.component, this.props);
  }
}

exports.replaceComponentRenderer = ({ props, loader }) => {
  return createElement(TwitterComponentRenderer, { ...props, loader });
};

[KyleAMathews]

Nah, the existing thing will be fine once I fix when onRouteUpdate is called.

[raae]

Ok, I'll use this as a workaround while waiting for the fix.

[KyleAMathews]

@raae fix is up here: https://github.com/gatsbyjs/gatsby/pull/7142

Will merge/publish in a bit.