mollie / components-examples

Examples and reference implementations for Mollie Components
13 stars 6 forks source link

Harmonizing Mollie with Rails Turbo Drive/pjax like behaviour #32

Open grekko opened 1 year ago

grekko commented 1 year ago

Hey hey šŸ‘‹šŸ½

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.

graph TD;
    start-->payment-setup;
    payment-setup-->preview;
    preview-->edit-payment;
    edit-payment-->preview

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-setup Mollie 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:

SCR-20230303-fpk

What I suspect is happening

I can see that new Mollie() registers some EventListeners on the head and body of the Document.

SCR-20230303-fra

SCR-20230303-frg

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 :)