Library does do not allow Stripe SDK to be loaded async about react-stripe-elements

[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.

[rixth]

Initial idea for a fix: #25

[michelle-stripe]

@rixth thanks for the report and the PR! I went ahead and fleshed out some alternative ideas here: #25 (comment)

[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: #25 (comment) 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 ***@***.***> wrote: So the main issue I see with this approach is the exactly one that you identified here: #25 (comment) <#25 (comment)> 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 <#24 (comment)>, 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 ***@***.***> 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 <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWGsFDRVUTf5cy-8QvrTZC8n68rrwawoks5sR13AgaJpZM4OTD88> .

-- Sent from Gmail Mobile

[iMerica]

Thank you @domlyons. Very cool.