チェックアウトブロックが注文を処理する方法

このドキュメントでは、チェックアウトフローの内部構造について説明します。具体的には、ユーザーが "注文する "ボタンを押した後に何が起こるかについてです。

構造

以下の領域は、ユーザーのチェックアウト処理に関連しています。

決済レジストリ (ファイル)

支払いレジストリは、各支払い方法のすべての設定情報を保存します。registerPaymentMethod 関数と registerExpressPaymentMethod 関数で新しい支払い方法を登録することができます。

データストア

データストアは、アクティブな支払い方法、チェックアウトのエラーの有無など、ユーザーのセッション中に変更される可能性のあるデータを追跡するために使用されます。これらのデータストアを関心のある領域ごとに分割し、チェックアウトに関連する2つのデータストアがあります：wc/store/checkout (file) と wc/store/payment (file) 。データストアは assets/js/data フォルダにあります。

コンテキスト

コンテキストは、チェックアウト・ブロックがデータを利用できるようにするために使用されます。これらのコンテキストはそれぞれ、フックを使用して、特定の領域に関連するデータと関数を提供します。例えば、 onPaymentSetup ハンドラを PaymentEventsContext コンテキストから使いたい場合は、次のようにします：

const { onPaymentSetup } = usePaymentEventsContext();

コンテキストのもう1つの仕事は、チェックアウト・ブロックの副作用を実行することです。通常は、CheckoutEvents と PaymentEvents がチェックアウトと支払いのデータストアの変更をリッスンし、いくつかのロジックに基づいてこれらのストアにアクションをディスパッチします。

例えば、CheckoutEvents コンテキストでは、チェックアウトのステータスが before_processing のときに emitValidateEvent アクションをディスパッチします。これら2つのストアからのステータスや他のステートデータの変更に反応する多くの類似したロジックがあります。

チェックアウトのコンテキストは以下の通り：

| コンテキスト
| ———————————————————————————————————————————————————————————————————————- | —————————————————- |
| CheckoutEvents | いくつかのチェックアウト関連のイベントハンドラを提供します。
| PaymentEvents | 支払いに関連するイベントハンドラを提供します。
| CustomerData | 現在の顧客に関連するデータを提供します。
| ShippingData | 配送エラーに関するデータとアクションを提供します。

チェックアウト・プロセッサー（checkout-processor.js）

チェックアウト処理コンポーネントは、チェックアウトまたは支払いデータストアの変更を購読し、このデータの一部をパッケージ化し、条件が整ったときに StoreApi /checkout エンドポイントを呼び出します。

チェックアウト・プロバイダー

チェックアウト・プロバイダーは、上記のすべてのコンテキストをCheckoutProcessorコンポーネントにラップします。

チェックアウト・ユーザーフロー

以下はチェックアウトの流れです。

1.注文する」ボタンをクリックしてください。

チェックアウトのプロセスは、ユーザーがボタンをクリックしたときに開始されます。

2.チェックアウトステータスが before_processing に設定されました(ファイル)

ユーザーが "注文する "ボタンをクリックするとすぐに、チェックアウトステータスを_"処理前"_に変更します。ここでチェックアウト情報のバリデーションを行います。

3.checkout_validation_before_processing イベントを出す (file)

ここでは WooCommerce Blocks プラグインや他のプラグインがバリデーションに対応するためのイベントリスナーを登録することができます。このイベントのイベントリスナーが実行され、エラーがあればチェックアウトステータスを idle に設定し、ユーザーにエラーを表示します。

エラーがなければ、次のステップ4に進む。

4.チェックアウトステータスが processing に設定されました(ファイル)

処理ステータスは、以下のステップ5で支払いステータスを変更するために使用されます。

5.支払いステータスは processing (ファイル) に設定されています。

すべてのチェックアウト処理が完了し、エラーがなければ、支払い処理が開始されます。

6.payment_processing イベントを出す (file)

payment_processing イベントが発生する。他のプラグインはこのイベントのイベントリスナーを登録し、独自のコードを実行することができます。

例えば、Stripe プラグインはここで住所と支払いの詳細をチェックし、Stripe API を使用して Stripe 内で顧客と支払いの参照を作成します。

重要：実際の支払いはここでは行われません。 これは、実際の支払いが試みられる前に、支払いプラグインのコードを実行するための前払いフックのように動作します。

7.payment_processing イベントリスナーを実行し、支払いとチェックアウトの状態を設定する (file)

登録されたイベント・リスナーがエラーを返した場合、それをユーザーに表示します。

イベントリスナーが成功したとみなされた場合、チェックアウトのアドレスを支払いアドレスと同期させ、paymentMethodData を支払いストアに保存し、支払いステータスのプロパティ{ isProcessing: true }を設定します。

8./wc/store/v1/checkoutへの POST (ファイル)

支払いエラーがなければ、/checkout StoreApi エンドポイントが呼び出されます。これは、最終的な顧客の住所と選択された支払い方法、そして追加の支払いデータを受け取り、支払いを試みて結果を返します。

重要：支払いは StoreApi を通じて行われ、クライアントから送信される payment_processing イベントを通じて行われるのではありません。

9.processCheckoutResponse アクションはチェックアウトストア(ファイル)でトリガーされます。

StoreApi /checkout エンドポイントへのフェッチがレスポンスを返すと、これを checkout データストアの processCheckoutResponse アクションに渡す。

次のようなアクションを実行する：

• 注文完了後にリダイレクトするURLを設定します。
• 決済結果を checkout データストアに保存します。
• チェックアウトステータスを after_processing に変更します (ステップ10)

10.チェックアウトステータスが after_processing に設定されました(ファイル)

after_processingステータスは、メインのチェックアウト処理ステップが終了したことを示します。このステップでは、クリーンアップアクションを実行し、最後のステップで発生したエラーを表示します。

11.checkout_after_processing_with_success イベントを出す (file)

エラーがなければ、 checkout_after_processing_with_success イベントが発生します。ここで、チェックアウトが成功した後に他のプラグインがコードを実行することができます。

checkout_after_processing_with_success イベントに登録されたイベント・リスナーが実行される。イベント・リスナーからのエラーがなければ、checkout データ・ストアで setComplete アクションが呼び出され、ステータスが complete に設定されます（ステップ13）。イベント・リスナーはここでエラーを返すこともでき、ユーザーに表示されます。

12.checkout_after_processing_with_error イベントを発行する (file)

ステップ5でエラーが発生した場合、 checkout_after_processing_with_error イベントが発生します。他のプラグインは、ユーザーにエラーを表示するために、ここで実行するイベントリスナーを登録することができます。イベント・リスナーは処理され、ユーザーにエラーを表示します。

13.チェックアウトステータスを complete に設定する (ファイル)

エラーがなければ、チェックアウト・データ・ストアの status プロパティは complete に変更されます。これはチェックアウト処理が完了したことを示します。

14.リダイレクト (ファイル)

チェックアウトステータスが complete に設定されると、チェックアウトデータストアに redirectUrl がある場合、ユーザーをURLにリダイレクトします。

その他特筆すべきこと

支払い方法の確認

支払い方法は設定オブジェクトに登録されます。これは canMakePayment という名前の関数を含んでいなければなりません。この関数は、支払い方法が現在のカートの支払いに使用できる場合、true を返す必要があります。現在のカート(アイテム、住所、配送方法など)はこの関数に渡され、各支払い方法が使用可能かどうかを報告する責任を負います。

checkPaymentMethodsCanPay() 関数は、登録されているすべての支払い方法を調べ、支払いが可能かどうかをチェックし、可能な場合は支払いデータストアの availablePaymentMethods プロパティに追加します。

checkPaymentMethodsCanPay()functionは、実行可能なオプションとしてユーザーに表示される前に、支払い方法を検証するために、いくつかの場所で呼び出されなければなりません。

• カートが読み込まれたら、支払い方法を表示できるようにしたいので、最初にそれらを検証する必要があります。
• カートが変更されたら、特定の支払い方法を有効/無効にします。
• チェックアウトがロードされたら、登録されているすべての支払い方法を検証したい