React-stripe-elements: Library does do not allow Stripe SDK to be loaded async

[rixth]

The provider expects window.Stripe to be set in its constructor. This forces the user to load the script synchronously (which is bad practice) _before_ they load their app JS (which is even worse).

Are there plans to rearchitect this library to support this?

I have a server-side rendered app, which does not include the Stripe SDK (since it's not needed on every page) -- on pages that require the SDK, we inject it & assume (perhaps slightly unsafely) that it has loaded by the time the user has entered their payment details.

Even ignoring the safety aspects, this approach is not possible with this library as it will throw an exception if the Stripe SDK is not present at first instantiation.

[rixth]

Initial idea for a fix: https://github.com/stripe/react-stripe-elements/pull/25

[michelle-stripe]

@rixth thanks for the report and the PR! I went ahead and fleshed out some alternative ideas here: https://github.com/stripe/react-stripe-elements/pull/25#issuecomment-314192701

[michelle]

@rixth Thinking on this a bit more, is there a reason y'all can't do the polling in your own code and only render the StripeProvider tree once window.Stripe is available? None of react-stripe-elements' components are useful until window.Stripe is available. After putting together the example in the custom elements instance PR (#27), it feels like a worse developer experience overall. The benefits of polling and then passing the elements instance compared to polling and then creating the StripeProvider-tree seem minimal. Perhaps we can improve the error messaging in StripeProvider and in the README and provide a cookbook for dealing async loading. What are your thoughts?

[rixth]

So the main issue I see with this approach is the exactly one that you identified here: https://github.com/stripe/react-stripe-elements/pull/25#issuecomment-314192701 In fact isn't #25 more-or-less what you're describing, but supported explicitly by the library?

We'd be blocking the display of everything inside the stripe provider until Stripe was available. In the case of passing the elements prop to the components themselves has the added benefit that we would be minimizing the amount of page content that is dependent on Stripe before displaying.

[michelle-stripe]

In the solution I'm imagining, you'd only have StripeProvider wrap the tree
that wouldn't make sense to render before Stripe is loaded; for example,
your credit card form. Do you need to render the rest of your credit card
form before Stripe is loaded? Are you building an interface where only the
Stripe-hosted fields are in a loading state?

On Wed, Jul 26, 2017 at 7:03 AM Thomas Rix [e-mail] wrote:

So the main issue I see with this approach is the exactly one that you
identified here: #25 (comment)
https://github.com/stripe/react-stripe-elements/pull/25#issuecomment-314192701

We'd be blocking the display of everything inside the stripe provider
until Stripe was available. In the case of passing the elements prop to
the components themselves has the added benefit that we would be minimizing
the amount of page content that is dependent on Stripe before displaying.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/stripe/react-stripe-elements/issues/24#issuecomment-318062707,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AWGsFCRY_cTBO9zmHxLJbPBQYtNafbdzks5sR0dJgaJpZM4OTD88
.

>

Sent from Gmail Mobile

[rixth]

Going down to the individual fields is probably a bit much, but limiting to the form, would be fine. So what you're suggesting is essentially what #25 does, only hoisting this behaviour up and out in to the application? Just trying to get clarity before I spend time on this

[rixth]

It seems like I'm essentially going to write a StripeProviderProvider :)

[michelle-stripe]

Yes, exactly. Even with the change I made in my PR, you'd need to load
Stripe yourself and provide it to the Elements that need it; right now you
need to load Stripe yourself and provide it to the StripeProvider. I
suppose it's like a ProviderProvider in that sense, except you have the
benefit of using props over context :).

On Wed, Jul 26, 2017 at 8:39 AM Thomas Rix [e-mail] wrote:

It seems like I'm essentially going to write a StripeProviderProvider :)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/stripe/react-stripe-elements/issues/24#issuecomment-318092767,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AWGsFDRVUTf5cy-8QvrTZC8n68rrwawoks5sR13AgaJpZM4OTD88
.

>

Sent from Gmail Mobile

[domlyons]

Hey, we've encountered the same problem on our project, as not all our users need stripe loaded. We created this library to asynchronously load scripts. The example on the page is essentially a StripeProviderProvider. This has more or less solved the problem for us. I think it has advantages over the other discussed methods because it is event driven and doesn't use polling. Let me know if you see any issues with this.

[iMerica]

Thank you @domlyons. Very cool.