#wulff-13

1 messages · Page 1 of 1 (latest)

hoary templeBOT
sand sorrel
olive wagon
#

Hi there

sand sorrel
#

We're having difficulties understanding how to include this component in our Vue app. It says

olive wagon
#

That's correct as far as I know. It won't throw an error or anything. It will just resolve to null if it can't initialize properly (like in a server environment where it isn't supported).

sand sorrel
#

Okay. Thanks!

This is a bit confusing to me:

Import @stripe/stripe-js as a side effect in code that will be included throughout your site (e.g. your root module). This will make sure the Stripe.js script tag is inserted immediately upon page load.

import '@stripe/stripe-js';

If I just do import and I don't use anything from the import, the editor will complain

olive wagon
#

What does it complain about?

#

Just that it is an unused import?

sand sorrel
#

Yeah and I'm not sure if it won't just be removed when compiling to TS if unused

olive wagon
#

It should still work fine as far as I know. Should be pretty easy to test though

sand sorrel
#

I think it's also a bit confusing that I have to provide a public key to loadStripe, when I would just want that code to inject the script tag and initialize the SDK. I would then expect to subsequently call Stripe("pk_...") to get an instance of Stripe.

#

Alright

#

(Because loadStripe is a promise and Stripe() is not)

olive wagon
#

Yeah the library and its fraud monitoring (which is why it is recommended to load it throughout your app) is dependent on your publishable key and that is loaded async.

sand sorrel
#

Hmm, but I don't need a key to include the script tag

#

So if that is true, then injecting the script tag should make no difference until Stripe() is called, or?

olive wagon
#

Sorry yeah I'm moving too quickly. What I said is incorrect -- you are right you only need to load the library for the fraud detection functionality. You then do load an instance of Stripe with your publishable key to properly use Stripe.JS methods for your account. The latter is what happens async

sand sorrel
#

Don't you mean the "former" happens async? Because injecting the script tag and waiting for the SDK to load has to be async, and Stripe("pk_") is not a promise so that can't really be async?

#

It seems to me that the easiest approach is to just include <script src="https://js.stripe.com/v3" async></script> in the entire app

olive wagon
#

Using loadStripe to load your Stripe instance happens async. I thought that is what you are referring to above.

sand sorrel
#

Which brings me back to my original point: It should be possible to call loadStripe without a public key and just have it return a promise once the SDK is loaded and you have access to window.Stripe. These seem to be closely coupled in the current logic

#

I'm just trying to understand exactly why this is 😄

#

In connect contexts you often need multiple instances of Stripe() with either your platform or connected account's PK, so that's why

olive wagon
#

loadStripe is designed to be used when you don't actually load the library initially. So it has to be async in that case.

sand sorrel
#

Yes. So this is not true: "You then do load an instance of Stripe with your publishable key to properly use Stripe.JS methods for your account. The latter is what happens async" - loading the SDK is async, creating a new Stripe instance is not. Currently, these are bundled together in one always-async promise.

So this means that for my platform, I would call loadStripe and get a Stripe instance, but if I need Stripe object in connect context, I need to call Stripe("pk_connect_key"), which I cannot do until after loadStripe's promise has returned.

My point is that loadStripe taking a public key seems to tightly couple the loading of the SDK to the creation of a new Stripe instance, which isn't the same thing.

#

And this whole thing confused me 😄

#

Or do you want me to just always call loadStripe whenever I need a new Stripe object?

olive wagon
#

Ah okay thanks for clarifying. I do think that if you have already called loadStripe then you could just create a new Stripe instance without calling loadStripe again and it would use the current loaded script, but I've never actually tested that. It is much more common to just load throughout on app load and then create instances as needed.

sand sorrel
#

Yeah that's what I figured as well. I guess we'll just do <script src="https://js.stripe.com/v3" async></script> and then use Stripe() whenever

olive wagon
#

Yep that's what I'd recommend.

sand sorrel
#

Cool. So in an SPA, this means:

  1. If you use async in the script tag, the SDK may not have loaded when your app tries to access Stripe
  2. If you don't use async, the entire page will stop working if Stripe's CDN doesn't work, and if your page only uses Stripe for a few features, taking it completely offline (practically) if the Stripe JS doesn't load is not a great idea. But I suppose this happens so rarely and in such short periods of time that it won't ever matter.
#

This was what originally lead me down the loadStripe path because it moves the loading of the SDK into a programmatic environment where it can be error-handled.

olive wagon
#

Makes sense. Yeah the overall recommendation is to just load it async, and it should load quite quickly overall.

sand sorrel
#

Unfortunately this often leads to "Stripe is not defined" errors if the page uses the SDK immediately

#

so we had to resort to some basic JS event functionality to know when it's availble, i.e. script.onload

#

And I thought this would be easier solved with loadStripe, but apparently not

#

I'll work it out. I just wanted to ask if I was completely off base