Remove Stripe iFrame when StripeProvider unmounts

[rogersnm]

Every time the StripeProvider component is constructed it creates a new iFrame in the DOM that is not removed when the component is unmounted (the iFrame appears to be asynchronously created after the Provider constructor executes due to window.Stripe() being called). After transitioning between various different pages that may or may not contain stripe components I'm left with numerous iframes cluttering up the DOM.

I'm aware that I can avoid the problem by placing the StripeProvider higher up the component tree, however I'm unwilling to force the user to download the Stripe.js lib unnecessarily if they're never going to see any Stripe components and therefore would rather keep it inside the pages concerned.

I couldn't see any nice API on the object that comes back from window.Stripe() to remove the iFrame/destroy the instance, however simply running: this._stripe._controller._controllerFrame._iframe.remove(); inside componentWillUnmount on the Provider achieves the desired effect (dirty though that is).

To me, it seems like the ideal solution would be to update Stripe.js to contain a more elegant unmount/destroy/unregister function and then trigger that in componentWillUnmount on the Provider.

[jenan-stripe]

Hi @rogersnm!

however I'm unwilling to force the user to download the Stripe.js lib unnecessarily if they're never going to see any Stripe components and therefore would rather keep it inside the pages concerned.

Can you help me understand your use case a bit more?

Our fraud detection works best when Stripe is loaded and initialized at the beginning of the user session, as early as possible. Additionally, we do a bit of bootstrapping when the client is initialized, so you'll probably want it earlier rather than later for performance reasons.

Just loading and initializing Stripe.js shouldn't cause any drag on the rest of your page (if it does, please let us know!).

[rogersnm]

Hi @jenan-stripe, thanks for taking the time to evaluate this issue 😄

The blocking nature of including Stripe.js via the script tag (<script src="https://js.stripe.com/v3/"></script>) increased our "time to first meaningful paint" by 150% (from 700ms to 1800ms) in our Google Lighthouse report.

In addition to this, we're leveraging Stripe's ability to store payment details to ensure our returning users don't have to re-enter their card details, and so for the majority of visits to our website, users will never see any Stripe components (only seeing them on the rare occasions they wish to add/update their card details). I'm unsure of how Stripe's Radar functionality can be beneficial in this circumstance, given that there is no direct link between a user's session on our website and our backend triggering a payment on their card.

For these reasons, we came to the decision that the Stripe.js library should only be loaded in asynchronously when required, so as to improve the user experience in the majority of use cases, however this causes the issues mentioned above.

[michelle]

Wow! Those times are really concerning and not at all what we'd expect. If you don't mind providing us with additional details on the experiments you ran, that would be really helpful for us in debugging.

We'll also look more into the specific issue, though.

[michelle]

Hey @rogersnm -- we just landed https://github.com/stripe/react-stripe-elements/releases/tag/v1.1.1. Does this release fix your issue?

[rogersnm]

Hi @michelle,

Sorry for the delay in replying previously. The new release does indeed fix the problem 😄, I'm more than happy for you to close this issue (although the release is not up on NPM yet).

Re: the experiments - I can't provide you with too much specific information at this point in development but in general:

• The primary experiment we ran was the Google Lighthouse report (https://developers.google.com/web/tools/lighthouse/#devtools), in addition to simply observing the Chrome network tab
• We're using SSR with embedded style sheets (with all other dependencies loaded asynchronously) so that the entirety of the page can be rendered before the client side React instance loads and initializes
• Including the Stripe.js <script> in the <head> blocks rendering until the script is loaded, parsed and executed (which allegedly takes ~950ms according to Lighthouse); including Stripe.js in the <body> causes a race condition with the <StripeProvider> constructor (as window.Stripe won't necessarily be defined in time)
• We were testing in London against a London based AWS EC2 instance, although from what I can see Stripe.js is also being served by a London-based Fastly cache

Thanks!
Nick

[skogsmaskin]

I'm missing a destroy / cleanup function as well. I think this is an important feature especially for single page apps, because there are many reasons why you don't want external scripts and iframes stuck in your page when the user has navigated away from the relevant functionality (security issues for one).

This is what I'm currently doing to destroy:

• controllerFrame._iframe.remove() for removing the Iframe
• Removing the script tag from the document head.
• Deleting window.Stripe

This works kind of as expected, however it seems like deleting window.Stripe causes the controller iframe to be loaded twice the next time Stripe is loaded. So for now I'm keeping window.Stripe and it works as expected. But I would really like an official way to do this, also removing window.Stripe without side-effects.

[jSchez]

For anyone interested, I came for the same issue.

This is how I have managed to clean the iframe on an Angular4 app

` ngOnDestroy() {

this.card.unmount();
if ( this.stripe['_controller'] ) {
  const $iframe = this.stripe['_controller']['_controllerFrame']['_controllerId'] || false;
  if ( $iframe ) {
    const $element = $('iframe[name="' + $iframe + '"]');
    if ( $element.length ) {
      $element.remove();
    }
  }
}

}`

[MovingGifts]

I still see the iframes build up, is there an official react stripe fix for this?
cc @michelle

[Gidgidonihah]

I can verify that I too am still seeing this behavior with v1.6.0

[ItsJonQ]

👋 Hai all!

I checked this out, and got a rough example working:

I did this by adding the following functions to the <Provider> component's componentWillUnmount() method:

const getStripeControllerFrameNode = stripe => {
  const frameId = stripe && stripe._controller && stripe._controller._id
  if (!frameId) return
  // Note: Using `document` isn't full-proof as it may not work if <Provider>
  // is rendered within an iFrame. This can be improved.
  return document.querySelector(`[name='${frameId}']`)
}

const removeStripeControllerFrame = stripe => {
  const frameNode = getStripeControllerFrameNode(stripe)
  // Note: Does not work, unless Stripe is [ready]. Will need to hook into
  // ready callback (somehow)
  if (frameNode && frameNode.parentNode) {
    frameNode.parentNode.removeChild(frameNode)
  }
}

And then calling it like:

export default class Provider extends React.Component<Props> {
  ...
  componentWillUnmount () {
    removeStripeControllerFrame(this._meta.stripe)
  }
  ...
}

This approach makes some vague assumptions on DOM things, but maybe it's something that can be explored if it'll solve the multi-iFrame issue.

🙌

[asolove-stripe]

I think I'm going to close this issue as the original problem is resolved.

If you want to load Stripe.js asynchronously, we now support doing that via StripeProvider, and have some pretty good docs and an demo of how to do so. The Stripe.js library does not support a way to "unload" itself and remove the controller instance. Adding it presents some API difficulties since the stripe instance itself may be in use elsewhere on the page.