Skip to content

Blocks: load payment request button configuration in the Blocks Checkout PHP handler instead of relying on configuration loaded for the Shortcode checkout #2604

Open

Description

Similar to the changes introduced in Stripe: woocommerce/woocommerce-gateway-stripe#1585

Problem

We currently rely on the JS configuration loaded for the shortcode checkout here in the block-based checkout (see for example how we use the wcpayPaymentRequestParams global here).

This is bad for at least 2 reasons:

  • We already have specific handlers for the Payment Request Buttons in the block-based integration JS, and the shortcode JS may contain some duplicate handlers that can potentially mess with the payment flow.
  • Loading unnecessary JS has performance impacts that can significantly slow down the checkout experience for no gain.

Proposed solution

  1. Extract the configuration object into it's own function (similar to what we did in the Stripe plugin).
  2. Use that function to load the payment request configuration into the Blocks settings here.
  3. Stop using the wcpayPaymentRequestParams global in the block integration JS.

Look at woocommerce/woocommerce-gateway-stripe#1585 for inspiration.

Things to consider and test

  1. Are we relying on some JS from the shortcode JS in the block integration JS?
    • If yes, then we should remove that dependency and implement everything in the block integration JS.
  2. How will this affect other theme builders with their own custom cart and checkout blocks, if at all?
    • Themes to look out for here that we've made mistakes with in the past (see pc4etw-aT-p2): CartFlows, possibly others.
  3. What possible side effects could a refactor like this have?
  4. Can we introduce unit (or even e2e) tests here that help us make sure the refactor doesn't break any existing functionality? Do these tests already exist?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    category: engineeringFor product engineering, architecture work, tech debt and so on.category: refactorThe issue/PR is related to refactoring.component: checkoutIssues related to Checkoutcomponent: payment request buttonApple Pay, Google Pay, etcfocus: checkout paymentsneeds prioritisationTriage finished and issues are ready for the following processing.priority: lowThe issue/PR is low priority—not many people are affected or there’s a workaround, etc.size: mediumThe issue is sized medium.type: technical debtThis issue/PR represents/solves the technical debt of the project.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions