Audit payment method interface API (#2622)

* remove obsolete useStoreOrder hook and implementation.

This hook was actually never completed and was only implemented in the `usePaymentMethodInterface` hook/api. The original purpose was to expose order details to registered payment methods, but that is now exposed via checkout state event emitters so it’s no longer needed.

OrderId is exposed via the `CheckoutState` context provider.

* remove setBillingData from being exposed to payment methods directly

billingData is updated via event emitter callback responses (see payment method data context provider) and is not something that should be set directly via payment methods.

We want checkout to have control over how billing data is updated in the state.

Author: nerrad

assets/js/base/hooks/index.js

@@ -1,6 +1,5 @@
 export * from './cart';
 export * from './checkout';
-export * from './order';
 export * from './payment-methods';
 export * from './shipping';
 export * from './use-collection';

assets/js/base/hooks/order/index.js

@@ -21,7 +21,7 @@ import {
 /**
  * Internal dependencies
  */
-import { useStoreOrder, useStoreCartCoupons, useStoreCart } from '..';
+import { useStoreCartCoupons, useStoreCart } from '..';
 
 /**
  * @typedef {import('@woocommerce/type-defs/registered-payment-method-props').RegisteredPaymentMethodProps} RegisteredPaymentMethodProps
@@ -116,8 +116,7 @@ export const usePaymentMethodInterface = () => {
 		onShippingRateSelectFail,
 		needsShipping,
 	} = useShippingDataContext();
-	const { billingData, setBillingData } = useBillingDataContext();
-	const { order, isLoading: orderLoading } = useStoreOrder();
+	const { billingData } = useBillingDataContext();
 	const { cartTotals } = useStoreCart();
 	const { appliedCoupons } = useStoreCartCoupons();
 	const { noticeContexts, responseTypes } = useEmitResponse();
@@ -164,9 +163,6 @@ export const usePaymentMethodInterface = () => {
 		},
 		billing: {
 			billingData,
-			setBillingData,
-			order,
-			orderLoading,
 			cartTotal: currentCartTotal.current,
 			currency: getCurrencyFromPriceResponse( cartTotals ),
 			cartTotalItems: currentCartTotals.current,

assets/js/base/hooks/order/use-store-order.js

@@ -119,10 +119,6 @@
  * @typedef BillingDataProps
  *
  * @property {BillingData}             billingData               The address used for billing.
- * @property {Function}                setBillingData            Used to set the cart billing
- *                                                               address.
- * @property {Object}                  order                     The order object for the purchase.
- * @property {boolean}                 orderLoading              True if the order is being loaded.
  * @property {PreparedCartTotalItem}   cartTotal                 The total item for the cart.
  * @property {SiteCurrency}            currency                  Currency object.
  * @property {PreparedCartTotalItem[]} cartTotalItems            The various subtotal amounts.

assets/js/base/hooks/payment-methods/use-payment-method-interface.js

@@ -106,7 +106,7 @@ A big part of the payment method integration is the interface that is exposed fo
 -   `paymentStatus`: This is an object with the [following payment status properties](https://github.com/woocommerce/woocommerce-gutenberg-products-block/blob/308e968c700028180cab391f2223eb0a43dd2d4d/assets/js/type-defs/contexts.js#L91-L113) - `isPristine`, `isStarted`, `isProcessing`, `isFinished`, `hasError`, `hasFailed`, `isSuccessful`. Note, your payment method does not have to handle setting this status client side. Checkout will handle this via the responses your payment method gives from observers registered to [checkout event emitters](./checkout-flow-and-events.md).
 -   `shippingStatus`: This object has two properties - `shippingErrorStatus`, which is an object with various error statuses that might exist for shipping, and `shippingErrorTypes`, which is an object containing all the possible types for shipping error status.
 -   `shippingData`: This object contains all shipping related data (outside of status) - `shippingRates`, `shippingRatesLoading`, `selectedRates`, `setSelectedRates`, `isSelectingRate`, `shippingAddress`, `setShippingAddress`, and `needsShipping`.
--   `billing`: This object contains everything related to billing - `billingData`, `setBillingData`, `order`, `orderLoading`, `cartTotal`, `currency`, `cartTotalItems`, `displayPricesIncludingTax`, `appliedCoupons`, `customerId`
+-   `billing`: This object contains everything related to billing - `billingData`, `cartTotal`, `currency`, `cartTotalItems`, `displayPricesIncludingTax`, `appliedCoupons`, `customerId`
 -   `eventRegistration`: This object contains all the checkout event emitter registration functions. These are functions the payment method can register observers on to interact with various points in the checkout flow (see [this doc](./checkout-flow-and-events.md) for more info). The following properties are available - `onCheckoutBeforeProcessing`, `onCheckoutAfterProcessingWithSuccess`, `onCheckoutAfterProcessingWithError`, `onPaymentProcessing`, `onShippingRateSuccess`, `onShippingRateFail`, `onShippingRateSelectSuccess`, `onShippingRateSelectFail`
 -   `components`: The properties on this object are exposed components that can be implemented by your payment method for various common interface elements used by payment methods. Currently the available components on this property are: `ValidationInputError` (a container for holding validation errors which typically you'll include after any inputs), and `CheckboxControl`(which is usually used for indicating to save the payment method). **Note: this last one is subject to change**
 -   `setExpressPaymentError`: This function receives a string and allows express payment methods to set an error notice for the express payment area on demand. This can be necessary because some express payment method processing might happen outside of checkout events.