we are integrating Mollie Components into a web application using Turbo Drive ā similar to what pjax does IIRC and are observing some technical issues.
Our setup
Users navigate through a multi-step payment process.
When users navigate from one page to the next, Turbo Drive will asynchronously fetch the subsequent page and only replaces the body while keeping the JS state of the users browser intact. More details about what Turbo Drive exactly does here.
On payment-setupMollie is initialised, the Card Component is mounted, etc. A reference to the initiated Mollie-object is stored at window.__mollieObj ā so it can be reused later when users may need to re-enter their credit card details (in step edit-payment).
// Either retrieve the existing mollie Obj or create new one
window.__mollieObj = window.__mollieObj || Mollie(window.__mollie.profile_id, window.__mollie.config);
For users who navigate through payment-setup->preview->edit-payment the Card Component should be mounted again. At this point window.__mollieObj is pointing to a Mollie-instance and we want to reuse it.
When mounting the Card Component I can observe that each iframe is stuck in the is-loading state like so:
There are no JS errors in the console.
The Card Component has been properly unmounted when users navigated away from setup-payment->preview
What I suspect is happening
I can see that new Mollie() registers some EventListeners on the head and body of the Document.
I understand that Turbo Drive will not remove those EventListeners when users navigate from payment-setup->preview.
When users then navigate from preview->edit-payment the old EventListeners are in place and a new Card Component is mounted.
Hey hey šš½
we are integrating Mollie Components into a web application using
Turbo Drive
ā similar to whatpjax
does IIRC and are observing some technical issues.Our setup
Users navigate through a multi-step payment process.
When users navigate from one page to the next, Turbo Drive will asynchronously
fetch
the subsequent page and only replaces thebody
while keeping the JS state of the users browser intact. More details about what Turbo Drive exactly doeshere
.On
payment-setup
Mollie
is initialised, the Card Component is mounted, etc. A reference to the initiatedMollie
-object is stored atwindow.__mollieObj
ā so it can be reused later when users may need to re-enter their credit card details (in stepedit-payment
).For users who navigate through
payment-setup->preview->edit-payment
the Card Component should be mounted again. At this pointwindow.__mollieObj
is pointing to aMollie
-instance and we want to reuse it.When mounting the Card Component I can observe that each
iframe
is stuck in theis-loading
state like so:setup-payment->preview
What I suspect is happening
I can see that
new Mollie()
registers some EventListeners on thehead
andbody
of the Document.I understand that Turbo Drive will not remove those EventListeners when users navigate from
payment-setup->preview
.When users then navigate from
preview->edit-payment
the old EventListeners are in place and a new Card Component is mounted.Then something is going wrong :)