#bluecitrusheart_code
fickle saffronBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always 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/1404474106883080264
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- bluecitrusheart_unexpected, 5 days ago, 8 messages
mighty maple
As seen below, no address is provided but complete is true and results in no validation when attempting to confirm.
celest falcon
Hi there 👋 just trying to make sure I understand correctly, you're saying unmounting an Address Element with a mode of shipping emits an empty Event corresponding to an Address Element with a mode of billing?
Do you have a publicly accessible test site where I can see this behavior?
mighty maple
Correct. We have both elements loaded on the page, and unmounting the shipping element emits the billing element's event. Is this expected?
Sorry we do not have a public site for testing as this is currently restricted to authenticated users only.
celest falcon
I personally wouldn't expect that, unless your code that unmounts the Shipping Address Element instance is also interacting with your Billing Address Element and causing changes.
mighty maple
That would be my first thought as well. Assuming we chased down the upstream effect which triggered the onChangeHandler, it is still surprising that the Billing Address Element would consider empty fields as complete and bypass validation.
celest falcon
Yeah, feels potentially weird, but i'd be curious to see what changes you're making to the various elements before saying it isn't expected.
Do you have the replication steps to see this behavior if I wanted to test it on my own site?
mighty maple
We are setting up the elements as stated per the Stripe documentation using two Address Elements and the Payment Element together. The only exception here is that we are unmounting the shipping address element if the user selects one of their saved shipping addresses (dropdown with saved addresses). Immediately when the shipping element is unmounted, the billing address element emits the empty validation mentioned above. We have a debouncer on our onChange for both Address Elements if that matters at all.
<AddressElement
onChange={debounce(handleOnChange, 300)}
options={billingElementOptions}
/>
I'm going to continue debugging and testing to see if there are alternatives. I assume the other option here is to keep the shipping element mounted and fill it with default values from the user's selection of saved addresses to avoid the validation issues.
Just to be clear though, you agree that unmounting one address element should not trigger the onChange for the other in any way?
celest falcon
No, I wouldn't expect that, and would like to understand how to reproduce that behavior so I can flag it to our teams.
mighty maple
Would the elements API internally reattach listeners when it gets reinitialize?
celest falcon
What are you re-initializing? I thought you were just unmounting things?
mighty maple
Sorry it was a hypothetical question. We aren't (I don't think anyway) re-initializing or re-rendering anything purposefully.