ae0b1d6b7d
* Implement `started` action creator. Also for TS typing I changed `paymentMethodData` to be optional for both the `success` and `started` action creators. This is because the behaviour allows for paymentMethodData to be retained in the state if it is not explicitly provided on dispatch. * Implement started action creator on the exposed payment status dispatcher. The implementation now allows for receiving payment method data when the `start` status is dispatched. * Don’t overwrite payment method data when `success` status is set. It is intended that if paymentMethodData is undefined, that is simply passed through to the dispatched action. This signals the reducer to retain the existing paymentMethodData in state (when undefined). The correct way to clear the paymentMethodData is to either explictly provide an empty object, or set the status to pristine. * Fix types for incoming paymentMethodData * Implement receiving paymentMethodData in reducer. This changeset also configures the reducer to retain the existing paymentMethodData in state (and related correlated information0 when the provided paymentMethodData property is undefined. The only time paymentMethodData should be reset in state is when it is explicitly provided or the status is set to PRISTINE. * Fix types for started action dispatcher. * Explicitly clear paymentMethodData state when express payment started. Also restores previous paymentMethodData when express payment cancelled. * Switch saved tokens to utilize the payment method status started dispatched action instead of success. This change ensures that savedToken handlers registered by payment methods have access to the `onPaymentProcessing` checkout event. * fix typedef Really just need to ensure types are used anywhere, this is a temporary change due to the time sensitive needs for this PR. * Update assets/js/base/context/cart-checkout/payment-methods/reducer.ts Co-authored-by: Albert Juhé Lluveras <contact@albertjuhe.com> Co-authored-by: Albert Juhé Lluveras <contact@albertjuhe.com> |
||
|---|---|---|
| .. | ||
| active-filters | ||
| attribute-filter | ||
| cart-checkout | ||
| featured-category | ||
| featured-product | ||
| handpicked-products | ||
| price-filter | ||
| product-best-sellers | ||
| product-categories | ||
| product-category | ||
| product-new | ||
| product-on-sale | ||
| product-search | ||
| product-tag | ||
| product-top-rated | ||
| products | ||
| products-by-attribute | ||
| reviews | ||
| single-product | ||
| README.md | ||
README.md
Blocks
Our blocks are generally made up of up to 4 files:
|- block.js
|- editor.scss
|- index.js
|- style.scss
The only required file is index.js, this sets up the block using registerBlockType. Each block has edit and save functions.
The scss files are split so that things in style are added to the editor and frontend, while styles in editor are only added to the editor. Most of our blocks should use core components that won't need CSS though.
Editing
A simple edit function can live in index.js, but most blocks are a little more complicated, so the edit function instead returns a Block component, which lives in block.js. By using a component, we can use React lifecycle methods to fetch data or save state.
The Newest Products block is a good example to read over, this is a simple block that fetches the products and renders them using the ProductPreview component.
We include settings in the sidebar, called the Inspector in gutenberg. See an example of this.
Other blocks have the concept of an "edit state", like when you need to pick a product in the Featured Product block, or pick a category in the Products by Category block.
Saving
Usually blocks can be converted to HTML in the save function, so that what's saved into the database is the same HTML that's rendered on the frontend. Our blocks are different since they need to show the latest products and reflect any changes to products.
The grid blocks are saved as shortcodes using getShortcode, but the Featured Product block is considered a "dynamic block", so we use PHP to build that each time the post is loaded on the frontend. The code for that is set up when the block is registered in PHP, and lives in WGPB_Block_Featured_Product.