woocommerce/plugins/woocommerce-blocks/assets/js/base/context/cart-checkout/shipping/index.js

263 lines
6.4 KiB
JavaScript
Raw Normal View History

/**
* External dependencies
*/
import {
createContext,
useContext,
useReducer,
useEffect,
useMemo,
useRef,
} from '@wordpress/element';
import {
useShippingAddress,
useStoreCart,
useSelectShippingRate,
} from '@woocommerce/base-hooks';
import { useCheckoutContext } from '@woocommerce/base-context';
/**
* Internal dependencies
*/
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
import {
ERROR_TYPES,
DEFAULT_SHIPPING_CONTEXT_DATA,
shippingErrorCodes,
} from './constants';
import {
EMIT_TYPES,
emitterSubscribers,
reducer as emitReducer,
emitEvent,
} from './event-emit';
/**
* @typedef {import('@woocommerce/type-defs/contexts').ShippingDataContext} ShippingDataContext
* @typedef {import('react')} React
*/
const { NONE, INVALID_ADDRESS, UNKNOWN } = ERROR_TYPES;
/**
* Reducer for shipping status state
*
* @param {string} state The current status.
* @param {Object} action The incoming action.
* @param {string} action.type The type of action.
*/
const errorStatusReducer = ( state, { type } ) => {
if ( Object.values( ERROR_TYPES ).includes( type ) ) {
return type;
}
return state;
};
const ShippingDataContext = createContext( DEFAULT_SHIPPING_CONTEXT_DATA );
/**
* @return {ShippingDataContext} Returns data and functions related to
* shipping methods.
*/
export const useShippingDataContext = () => {
return useContext( ShippingDataContext );
};
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
const hasInvalidShippingAddress = ( errors ) => {
return errors.some( ( error ) => {
if (
error.code &&
Object.values( shippingErrorCodes ).includes( error.code )
) {
return true;
}
return false;
} );
};
/**
* The shipping data provider exposes the interface for shipping in the
* checkout/cart.
*
* @param {Object} props Incoming props for provider
* @param {React.ReactElement} props.children
*/
export const ShippingDataProvider = ( { children } ) => {
const { dispatchActions } = useCheckoutContext();
const {
cartNeedsShipping: needsShipping,
shippingRates,
shippingRatesLoading,
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
cartErrors,
} = useStoreCart();
const [ shippingErrorStatus, dispatchErrorStatus ] = useReducer(
errorStatusReducer,
NONE
);
const [ observers, subscriber ] = useReducer( emitReducer, {} );
const { shippingAddress, setShippingAddress } = useShippingAddress();
const currentObservers = useRef( observers );
const {
selectShippingRate: setSelectedRates,
selectedShippingRates: selectedRates,
isSelectingRate,
} = useSelectShippingRate( shippingRates );
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
const eventSubscribers = useMemo(
() => ( {
onShippingRateSuccess: emitterSubscribers( subscriber ).onSuccess,
onShippingRateFail: emitterSubscribers( subscriber ).onFail,
onShippingRateSelectSuccess: emitterSubscribers( subscriber )
.onSelectSuccess,
onShippingRateSelectFail: emitterSubscribers( subscriber )
.onSelectFail,
} ),
[ subscriber ]
);
// set observers on ref so it's always current.
useEffect( () => {
currentObservers.current = observers;
}, [ observers ] );
// increment/decrement checkout calculating counts when shipping is loading.
useEffect( () => {
if ( shippingRatesLoading ) {
dispatchActions.incrementCalculating();
} else {
dispatchActions.decrementCalculating();
}
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
}, [ shippingRatesLoading, dispatchActions ] );
// increment/decrement checkout calculating counts when shipping rates are
// being selected.
useEffect( () => {
if ( isSelectingRate ) {
dispatchActions.incrementCalculating();
} else {
dispatchActions.decrementCalculating();
}
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
}, [ isSelectingRate, dispatchActions ] );
// set shipping error status if there are shipping error codes
useEffect( () => {
if (
cartErrors.length > 0 &&
hasInvalidShippingAddress( cartErrors )
) {
dispatchErrorStatus( { type: INVALID_ADDRESS } );
} else {
dispatchErrorStatus( { type: NONE } );
}
}, [ cartErrors ] );
const currentErrorStatus = useMemo(
() => ( {
isPristine: shippingErrorStatus === NONE,
isValid: shippingErrorStatus === NONE,
hasInvalidAddress: shippingErrorStatus === INVALID_ADDRESS,
hasError:
shippingErrorStatus === UNKNOWN ||
shippingErrorStatus === INVALID_ADDRESS,
} ),
[ shippingErrorStatus ]
);
// emit events.
useEffect( () => {
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
if (
! shippingRatesLoading &&
( shippingRates.length === 0 || currentErrorStatus.hasError )
) {
emitEvent(
currentObservers.current,
EMIT_TYPES.SHIPPING_RATES_FAIL,
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
{
hasInvalidAddress: currentErrorStatus.hasInvalidAddress,
hasError: currentErrorStatus.hasError,
}
);
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
}
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
}, [
shippingRates,
shippingRatesLoading,
currentErrorStatus.hasError,
currentErrorStatus.hasInvalidAddress,
] );
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
useEffect( () => {
if (
! shippingRatesLoading &&
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
shippingRates.length > 0 &&
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
! currentErrorStatus.hasError
) {
emitEvent(
currentObservers.current,
EMIT_TYPES.SHIPPING_RATES_SUCCESS,
shippingRates
);
}
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
}, [ shippingRates, shippingRatesLoading, currentErrorStatus.hasError ] );
// emit shipping rate selection events.
useEffect( () => {
if ( ! isSelectingRate && currentErrorStatus.hasError ) {
emitEvent(
currentObservers.current,
EMIT_TYPES.SHIPPING_RATE_SELECT_FAIL,
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
{
hasError: currentErrorStatus.hasError,
hasInvalidAddress: currentErrorStatus.hasInvalidAddress,
}
);
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
}
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
}, [
selectedRates,
isSelectingRate,
currentErrorStatus.hasError,
currentErrorStatus.hasInvalidAddress,
] );
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
useEffect( () => {
if (
! isSelectingRate &&
selectedRates &&
! currentErrorStatus.hasError
) {
emitEvent(
currentObservers.current,
EMIT_TYPES.SHIPPING_RATE_SELECT_SUCCESS,
selectedRates
);
}
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
}, [ selectedRates, isSelectingRate, currentErrorStatus.hasError ] );
/**
* @type {ShippingDataContext}
*/
const ShippingData = {
shippingErrorStatus: currentErrorStatus,
dispatchErrorStatus,
shippingErrorTypes: ERROR_TYPES,
shippingRates,
setShippingRates: setSelectedRates,
shippingRatesLoading,
selectedRates,
setSelectedRates,
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
isSelectingRate,
shippingAddress,
setShippingAddress,
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
onShippingRateSuccess: eventSubscribers.onShippingRateSuccess,
onShippingRateFail: eventSubscribers.onShippingRateFail,
onShippingRateSelectSuccess:
eventSubscribers.onShippingRateSelectSuccess,
onShippingRateSelectFail: eventSubscribers.onShippingRateSelectFail,
needsShipping,
};
return (
<>
<ShippingDataContext.Provider value={ ShippingData }>
{ children }
</ShippingDataContext.Provider>
</>
);
};