#coroi1304_address-element-value

1 messages ยท Page 1 of 1 (latest)

cinder streamBOT
#

๐Ÿ‘‹ Welcome to your new thread!

โฒ๏ธ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can start a new thread if you have another question.

๐Ÿ”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1250079422422319165

๐Ÿ“ Have more to share? Add details, code, screenshots, videos, etc. below.

steel thornBOT
bronze ivy
#

Hi there ๐Ÿ‘‹ offhand, I'm not sure why that wouldn't be working. If you split that into separate lines, rather than nesting the get functions, does the behavior persist? That might give us more insight into exactly where things are hanging/stalling if you can split that up and add additional logging.

lime lantern
#

hello! i did that second line of logging to see what result i can extract out of the getValue call... it does hang when i just make the addressElement.getValue() call which is what prompted me looking into it at first.

cinder streamBOT
#

coroi1304_address-element-value

lime lantern
#

const addressElement = elements?.getElement('address')

if (addressElement) {
const { complete, value } = await addressElement.getValue()
// do stuff with value
}

here is a snippet of the actual work flow

bronze ivy
#

What is in addressElement after you run this?
const addressElement = elements?.getElement('address')
Is that resolving and finding the Address Element instance you created correctly? Apologies for not being more explicit before, but that's the part I was referring to splitting out.

lime lantern
#

it is, yup - i am seeing the element we created

#

const addressElement = elements?.getElement('address')
if (addressElement) {
console.log(addressElement)
const { complete, value } = await addressElement.getValue()
console.log(complete: ${complete}, value: ${value})

}

#

seeing the element with the first log, but the second log never fires

#

& i see getValue on the address element here

bronze ivy
#

Hm, do you have a test site where I can see this behavior and take a closer look?

lime lantern
#

unfortunately i do not ):

one thing i will try is to set it up how the docs suggest.. using .then instead of await and see what happens

bronze ivy
#

Sounds good, I'm curious to hear if that changes anything as well!

lime lantern
#

haha.. well that allowed the payment flow to complete (as expected, since we aren't blocking for the results of the promise now) but it still seems like the promise didn't resolve

#

i'm gonna do a little more sleuthing here and let you know what i find

#

i could have sworn this was working yesterday/friday.. but maybe i am misremembering lol

bronze ivy
#

I'm trying to find time to dig into this more too, but the server is pretty busy right now.

lime lantern
#

all good, thank you for your help so far!

#

i guess i am mostly wondering in what scenarios could that getValue promise fail to resolve or reject

bronze ivy
#

Hm, I really don't understand what is happening here. I just ran the function in my test site, and it seemed to pull the address as expected.

lime lantern
#

ok i think i figured it out actually. i had moved some logic around and put the stripe payment element in a <template> that it wasn't in before.. we are using a two screen checkout process. the template is only showing on the first screen, so i think it's getting unmounted when we move to the second screen and try to getValue the element. hence it not being available!