woocommerce/plugins/woocommerce-blocks/assets/js/base/context/store-notices-context.js

129 lines
3.0 KiB
JavaScript
Raw Normal View History

/**
* External dependencies
*/
import PropTypes from 'prop-types';
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 {
createContext,
useContext,
useCallback,
useState,
} from '@wordpress/element';
import { useSelect, useDispatch } from '@wordpress/data';
import {
StoreNoticesContainer,
SnackbarNoticesContainer,
} from '@woocommerce/base-components/store-notices-container';
/**
* @typedef {import('@woocommerce/type-defs/contexts').NoticeContext} NoticeContext
*/
const StoreNoticesContext = createContext( {
notices: [],
createNotice: ( status, text, props ) => void { status, text, props },
createSnackbarNotice: ( content, options ) => void { content, options },
removeNotice: ( id, ctxt ) => void { id, ctxt },
setIsSuppressed: ( val ) => void { val },
context: 'wc/core',
} );
/**
* Returns the notices context values.
*
* @return {NoticeContext} The notice context value from the notice context.
*/
export const useStoreNoticesContext = () => {
return useContext( StoreNoticesContext );
};
/**
* Provides an interface for blocks to add notices to the frontend UI.
*
* Statuses map to https://github.com/WordPress/gutenberg/tree/master/packages/components/src/notice
* - Default (no status)
* - Error
* - Warning
* - Info
* - Success
*/
export const StoreNoticesProvider = ( {
children,
className = '',
createNoticeContainer = true,
context = 'wc/core',
} ) => {
const { createNotice, removeNotice } = useDispatch( 'core/notices' );
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 [ isSuppressed, setIsSuppressed ] = useState( false );
const createNoticeWithContext = useCallback(
( status = 'default', content = '', options = {} ) => {
createNotice( status, content, {
...options,
context: options.context || context,
} );
},
[ createNotice, context ]
);
const removeNoticeWithContext = useCallback(
( id, ctxt = context ) => {
removeNotice( id, ctxt );
},
[ removeNotice, context ]
);
const createSnackbarNotice = useCallback(
( content = '', options = {} ) => {
createNoticeWithContext( 'default', content, {
...options,
type: 'snackbar',
} );
},
[ createNoticeWithContext ]
);
const { notices } = useSelect(
( select ) => {
return {
notices: select( 'core/notices' ).getNotices( context ),
};
},
[ context ]
);
const contextValue = {
notices,
createNotice: createNoticeWithContext,
createSnackbarNotice,
removeNotice: removeNoticeWithContext,
context,
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
setIsSuppressed,
};
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 noticeOutput = isSuppressed ? null : (
<StoreNoticesContainer
className={ className }
notices={ contextValue.notices }
/>
);
const snackbarNoticeOutput = isSuppressed ? null : (
<SnackbarNoticesContainer />
);
return (
<StoreNoticesContext.Provider value={ contextValue }>
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
{ createNoticeContainer && noticeOutput }
{ children }
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
{ snackbarNoticeOutput }
</StoreNoticesContext.Provider>
);
};
StoreNoticesProvider.propTypes = {
className: PropTypes.string,
createNoticeContainer: PropTypes.bool,
children: PropTypes.node,
context: PropTypes.string,
};