* WIP
* convert to reakit
* rebase and fix styling issues
* add forget initialTabName
* delete button and force manual select
* fix git diff problem in package-lock
* directly render tabs
* fix regression
* gaurd against unset values
* update reakit and guard against empty tabs
* Remove summary from API
* Add wordCountType to assets
* Update packages
* Remove summary from test data
* Featured product uses short desc
* Pass description instead of summary
* Use new Summary Component
* Component and tests
* Increased versititilty of methods
* Update assets/js/base/components/cart-checkout/product-summary/index.js
Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
* Extra tests for html tags
Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
* Use container queries to load Cart and Checkout responsive styles
* Update package-lock.json
* Make form-step react to container queries instead of media queries
* Make sidebar layout inner padding relative to the full-width
* Make container queries breakpoints smaller
* Server side changes for payment method integrations
Including adding a stripe class temporarily
* update needed npm packages (and add some types)
* updates to contexts
* remove stepContent from payment config for payment methods
* update payment method interface and typedefs
Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them)
* add apple pay and stripe cc integration and remove paypal
* remove save payment checkbox from checkout block
It is handled by payment methods.
* Include an id prop for tabs
* fix activePaymentMethod pass through on rendered payment method element
also adds an id for the rendered tab
* add styles for payment method fields
If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this?
These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway).
* fix rebase conflict
* do a test payment request for applePay to determine if the current browser supports it
* don’t console.error for stripe loading.
* Fix placeholder errors in the editor
* improve styling and add missing validation for inline card element
* update pacakge-lock
* rename payment-methods-demo folder to payment-methods-extension
* expose checkbox control on payment method interface
* export payment-methods-extension to it’s own asset build
This allows us to more accurately demonstrate how payment extensions would hook in to the blocks.
* don’t enqueue a style that doesn’t exist
* add full stop to comments and remove obsolete comment blcok
* fix spacing
* switch `activeContent` to `content` for payment method registration config
* add payment-methods-demo config to sideEffects and install @wordpress/icons and @wordpress/primitives to be used directly.
* configure dependency extraction to ignore imports we want to use directly
* fix style issues for production builds
It looks like when a style is imported on the entrypoint of a component (or in a file with just exports), it get’s treeshaken from the final build _regardless of exception rules_.
* fix style imports from wordpress components
* fix loading skeleton showing on production builds
* fix block skeleton showing on production builds for cart
* import side effectful code
* add treatment for `@wordpress/warning` too
* fix typo
* exclude `settings/block` from sideEffects
* rollback `wordpress-components` update and keep sideEffects fixes
* remove unnecessary handle handling
Co-authored-by: Seghir Nadir <nadir.seghir@gmail.com>
Seghir Nadir
renovate[bot]
Darren Ethier
Mike Jolley
Albert Juhé Lluveras
Rua Haszard