#Maastonakki

1 messages · Page 1 of 1 (latest)

fringe lavaBOT
wise parcel
solid sparrow
#

That's the one I've tried to use for my behalf to get understanding of how that works. Basically NextJS uses the React for UI, so that should fit there quite well.

Like said the trouble is, that even in the example of that React-app, <Elements /> get initialized on <App /> level. And if we think about life-cycle of <App />, user might be doing a lot of different things before they end up paying for something (initializing the Payment Intent). And what I've understood, <Elements /> options-prop is immutable when it comes to clientSecret which should be passed to it?

wise parcel
#

Not completely sure but yes looks like <Elements /> will be declared publicly with clientSecret on index.js. You probably would need to separate this page from the other actions you mention? Like before getting to paying, your customer is on pre_index.js, then finally when paying they get to index.js?

#

Sorry clearly I am not a React expert, but LMK if that doesn't make sense

tidal slate
#

problem with nextjs is that if you declare the <Elements /> provider top level, you don't have a clientSecret to render the <PaymentElement /> with

solid sparrow
#

Sure, thanks! I'll try to find way to get better intializion location for <Elements />
I'm not 100% sure if useStripe() and useElements() hooks require the calling component to being wrapped in properly initilized <Elements />

solid sparrow
#

And I would imagine that's the same situation with any React Single-Page Application?

tidal slate
#

as @wise parcel said, best to have a page with the <Elements /> provider and render it only when you have a clientSecret, as it cannot be updated later on the elements provider

tidal slate
#

you can get away with using a <CardElement />, because it doesn't need a clientSecret to render, thats how I implemented it.
the problem with that is that you have to handle a lot more things than with the <PaymentElement />

solid sparrow
#

True. That's kind of double edged sword, since we would like to offer multiple payment options for user, like Card, SEPA Transfer and few others, so that's why we're going with <PaymentElement />

But actually that could be something, to just wrap <Elements /> in Checkout-component, which would be rendered only if parent component has paymentIntent selected, and then pass the clientSecretto that component as a prop.

odd patrol
solid sparrow