scottf - react elements | Stripe Developers | Page 1

opaque bobcat Jun 6, 2022, 2:20 PM

#

Hello! Just starting a thread for you -- I'll review and respond as soon as I can 🙂

#

The Stripe hooks will only work in components inside that provider, as far as I know.

#

You might be able to wire things up some other way to pass what you need, but this is outside our documented/tested flows

tidal hawk Jun 6, 2022, 2:23 PM

#

yeah, that makes sense

opaque bobcat Jun 6, 2022, 2:23 PM

#

What's the use case for wanting to interact with the element data outside the context of the provider?

tidal hawk Jun 6, 2022, 2:24 PM

#

The issue stems from the pattern created by the Payment Element where the client secret is required in the <Elements/> provider instead of being a prop requirement on the <PaymentElement/> itself

#

We only generate an intent (and thus client secret) for customers after they have created an account (step 1 of our form)

#

our form UI is broken up into two steps with the non-active step being visibly read-only/disabled

#

so I think the only way to solve this, while still confirming to stripe's prescribed useage pattern, is to have a dummy/placeholder form full of vanilla input fields, and then rerender/swap the entire form out with the real one once we have a client secret

#

I really wanted to avoid this if possible, so was just trying to verify that there wasnt a better way

opaque bobcat Jun 6, 2022, 2:43 PM

#

I don't think you need to rebuild the form with dummy values - that's a lot of work to keep in sync. Creating a PI with placeholder details might be simpler, which is then updated or cancelled as needed based on customer action.

#

But this is really up to you to decide

tidal hawk Jun 6, 2022, 2:53 PM

#

Yeah I think that's definitely the easiest solution and clearly is the way stripe designed this to be used. I'm not sure I can get our systems design team to budge on that but that's not an issue you can solve!

#

Thanks for your help

opaque bobcat Jun 6, 2022, 2:56 PM

#

Happy to try to help! We're trying to expand the support for more and more use cases for the payment element so its good feedback 🙂

tidal hawk Jun 6, 2022, 2:57 PM

#

Being able to render the element with just the publishable key, and then requiring the intent as a parameter on the confirmPayment() method would be the ideal solution in my opinion

#

I believe this is how the card element works

#

I'm sure there's a good reason, internally, why the payment element doesnt work in the same fashion

#

but that's been the biggest limiter when it comes to UI flexibility

opaque bobcat Jun 6, 2022, 2:59 PM

#

Yea this is part of the benefit of the payment element though, the automatic configuration for payment methods. That requires a specific PI though, currently, from which we can determine possible payment methods.

#

eg, currency and amount matter, along with other settings

tidal hawk Jun 6, 2022, 3:00 PM

#

yeah I guess that's the tradeoff we make

opaque bobcat Jun 6, 2022, 3:00 PM

#

ie, if your payment is in USD, we can't offer SEPA etc

#scottf - react elements