Experimental - Use real store data for previewing taxonomy filter block #59609
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Testing GuidelinesHi @ralucaStan @woocommerce/developer-advocacy, Apart from reviewing the code changes, please make sure to review the testing instructions (Guide) and verify that relevant tests (E2E, Unit, Integration, etc.) have been added or updated as needed. Reminder: PR reviewers are required to document testing performed. This includes:
|
|
Size Change: +2.55 kB (+0.04%) Total Size: 5.86 MB
|
Test using WordPress PlaygroundThe changes in this pull request can be previewed and tested using a WordPress Playground instance. Test this pull request with WordPress Playground. Note that this URL is valid for 30 days from when this comment was last updated. You can update it by closing/reopening the PR or pushing a new commit. |
kmanijak
requested changes
Jul 11, 2025
...ns/woocommerce/client/blocks/assets/js/base/context/hooks/collections/use-collection-data.ts
Show resolved
Hide resolved
...ommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/edit.tsx
Outdated
Show resolved
Hide resolved
Comment on lines
89
to
98
| if ( isPreview ) { | ||
| // Use preview data for preview mode | ||
| setTermOptions( | ||
| sortFilterOptions( [ ...termOptionsPreview ], sortOrder ) | ||
| ); | ||
| setIsOptionsLoading( false ); | ||
| return; | ||
| } |
There was a problem hiding this comment.
This is kind of duplicated in previous hook. What about returning
if ( ! taxonomy ) {
return { taxonomyTerms: [], isTermsLoading: false };
}
if ( isPreview ) {
return { taxonomyTerms: return { taxonomyTerms: [], isTermsLoading: false };, isTermsLoading: false };
}
in line 53 so there's one useEffect handling data preparation and this one handles the state with no additional logic. Minor but it would feel cleaner to me.
There was a problem hiding this comment.
@kmanijak Can you revisit this comment and the connected comment below with the current code? I pushed some updates to these hooks' callbacks.
...ommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/edit.tsx
Outdated
Show resolved
Hide resolved
...ommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/edit.tsx
Outdated
Show resolved
Hide resolved
...ommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/edit.tsx
Outdated
Show resolved
Hide resolved
cb93f5e to
d9b0409
Compare
kmanijak
approved these changes
Jul 17, 2025
Comment on lines
43
to
+50
| const [ termOptions, setTermOptions ] = useState< FilterOptionItem[] >( | ||
| [] | ||
| isPreview | ||
| ? sortFilterOptions( [ ...termOptionsPreview ], sortOrder ) | ||
| : [] | ||
| ); | ||
| const [ isOptionsLoading, setIsOptionsLoading ] = | ||
| useState< boolean >( true ); | ||
| const [ isOptionsLoading, setIsOptionsLoading ] = useState< boolean >( | ||
| ! isPreview | ||
| ); |
There was a problem hiding this comment.
Clever, I like using isPreview to determine initial state! 👍
| { sprintf( | ||
| // translators: %s: Taxonomy label. | ||
| __( | ||
| 'There are no products associated with %s.', |
|
Minor comment, there's some incorrect encoding happening in taxonomies names: 
|
Base automatically changed from
wooplug-4766-product-collection-data-api-add-support-for-taxonomy
to
trunk
July 17, 2025 10:03
📝 WalkthroughWalkthroughThe changes add support for a Changes
Sequence Diagram(s)sequenceDiagram
participant EditComponent as TaxonomyFilter Edit Component
participant WPData as WP Core Data (useSelect)
participant CollectionData as useCollectionData Hook
participant Utils as sortFilterOptions Utility
EditComponent->>WPData: Fetch taxonomy terms (by taxonomy, hideEmpty)
WPData-->>EditComponent: Return terms and loading state
EditComponent->>CollectionData: Fetch product counts (by queryTaxonomy)
CollectionData-->>EditComponent: Return counts and loading state
EditComponent->>Utils: Sort terms and counts (sortFilterOptions)
Utils-->>EditComponent: Return sorted options
EditComponent->>EditComponent: Render filter UI with options and loading states
Possibly related PRs
📜 Recent review detailsConfiguration used: .coderabbit.yml 📒 Files selected for processing (5)
🚧 Files skipped from review as they are similar to previous changes (5)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/edit.tsx (1)
53-81: WordPress data fetching is well implemented.Good use of core data selectors with proper loading state tracking. The 15 term limit is appropriate for preview display as noted in previous reviews.
🧹 Nitpick comments (1)
plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/edit.tsx (1)
91-154: Consider extracting term processing logic for better maintainability.The effect handles multiple responsibilities well, but the term processing logic (lines 119-140) could be extracted to a separate utility function for improved testability and reusability.
Example refactor:
// In a utils file export const processTermsWithCounts = ( taxonomyTerms: Term[], taxonomyCounts: TaxonomyCount[], hideEmpty: boolean ): FilterOptionItem[] => { return taxonomyTerms.reduce((acc: FilterOptionItem[], term) => { const count = taxonomyCounts.find(item => item.term === term.id)?.count || 0; if (hideEmpty && count === 0) return acc; acc.push({ label: term.name, value: term.slug, selected: false, count, }); return acc; }, []); };
📜 Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
docs/apis/store-api/resources-endpoints/product-collection-data.md(2 hunks)plugins/woocommerce/changelog/59608-wooplug-4766-product-collection-data-api-add-support-for-taxonomy(1 hunks)plugins/woocommerce/client/blocks/assets/js/base/context/hooks/collections/use-collection-data.ts(4 hunks)plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/constants.ts(1 hunks)plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/edit.tsx(5 hunks)plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/test/block.ts(6 hunks)plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/utils/sort-filter-options.ts(1 hunks)plugins/woocommerce/src/StoreApi/Routes/V1/ProductCollectionData.php(3 hunks)plugins/woocommerce/src/StoreApi/Schemas/V1/ProductCollectionDataSchema.php(2 hunks)plugins/woocommerce/src/StoreApi/Utilities/ProductQuery.php(2 hunks)plugins/woocommerce/src/StoreApi/Utilities/ProductQueryFilters.php(1 hunks)plugins/woocommerce/tests/php/src/Blocks/StoreApi/Routes/ProductCollectionData.php(9 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{php,js,ts,jsx,tsx}
Instructions used from:
Sources:
⚙️ CodeRabbit Configuration File
plugins/woocommerce/tests/**/*.php
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/woo-phpunit.mdc
🧠 Learnings (10)
📓 Common learnings
Learnt from: samueljseay
PR: woocommerce/woocommerce#59051
File: plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/mini-cart-contents/inner-blocks/mini-cart-footer-block/index.tsx:66-70
Timestamp: 2025-06-23T05:47:52.696Z
Learning: For WooCommerce mini-cart blocks in plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/, the standardized conditional pattern for experimental features should be `if ( isExperimentalMiniCartEnabled() ) { blockSettings.save = () => <InnerBlocks.Content />; }` - defaulting to the traditional Save component and only overriding when the experimental feature is enabled.
Learnt from: samueljseay
PR: woocommerce/woocommerce#58716
File: plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/iapi-frontend.ts:83-101
Timestamp: 2025-06-17T07:07:53.443Z
Learning: In WooCommerce blocks, when porting existing code patterns that have known issues (like parseInt truncating decimal money values), maintain consistency with existing implementation rather than making isolated fixes. The preference is for systematic refactoring approaches (like broader Dinero adoption) over piecemeal changes.
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-06-30T09:26:55.361Z
Learning: Provide clear, step-by-step instructions for how to test the changes in the PR description.
Learnt from: lysyjan
PR: woocommerce/woocommerce#59632
File: packages/js/email-editor/src/layouts/flex-email.tsx:116-122
Timestamp: 2025-07-14T10:41:46.150Z
Learning: In WooCommerce projects, formatting suggestions should respect the project's Prettier configuration and linting rules. Changes that would break the lint job should be avoided, even if they appear to improve readability.
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#59675
File: .github/workflows/release-bump-as-requirement.yml:48-65
Timestamp: 2025-07-15T15:39:21.815Z
Learning: In WooCommerce core repository, changelog entries for all PRs live in `plugins/woocommerce/changelog/` directory and are processed during releases, not at the repository root level.
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#59499
File: plugins/woocommerce/src/Internal/ProductFilters/QueryClauses.php:327-332
Timestamp: 2025-07-10T04:22:27.648Z
Learning: In the WooCommerce ProductFilters QueryClauses class, the $chosen_taxonomies parameter in add_taxonomy_clauses() already contains only validated public product taxonomies. The validation occurs upstream in the Params class during parameter registration, so additional taxonomy existence validation in the processing methods is redundant.
plugins/woocommerce/changelog/59608-wooplug-4766-product-collection-data-api-add-support-for-taxonomy (2)
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#59499
File: plugins/woocommerce/src/Internal/ProductFilters/QueryClauses.php:327-332
Timestamp: 2025-07-10T04:22:27.648Z
Learning: In the WooCommerce ProductFilters QueryClauses class, the $chosen_taxonomies parameter in add_taxonomy_clauses() already contains only validated public product taxonomies. The validation occurs upstream in the Params class during parameter registration, so additional taxonomy existence validation in the processing methods is redundant.
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#59675
File: .github/workflows/release-bump-as-requirement.yml:48-65
Timestamp: 2025-07-15T15:39:21.815Z
Learning: In WooCommerce core repository, changelog entries for all PRs live in `plugins/woocommerce/changelog/` directory and are processed during releases, not at the repository root level.
plugins/woocommerce/src/StoreApi/Routes/V1/ProductCollectionData.php (2)
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#59499
File: plugins/woocommerce/src/Internal/ProductFilters/QueryClauses.php:327-332
Timestamp: 2025-07-10T04:22:27.648Z
Learning: In the WooCommerce ProductFilters QueryClauses class, the $chosen_taxonomies parameter in add_taxonomy_clauses() already contains only validated public product taxonomies. The validation occurs upstream in the Params class during parameter registration, so additional taxonomy existence validation in the processing methods is redundant.
Learnt from: mreishus
PR: woocommerce/woocommerce#58891
File: plugins/woocommerce/src/Blocks/Utils/BlocksSharedState.php:0-0
Timestamp: 2025-06-16T21:59:26.255Z
Learning: In WooCommerce's CartSchema::get_item_response() method, when called in the context of BlocksSharedState::register_cart_interactivity(), the method returns a plain array rather than a WP_REST_Response object, making it directly suitable for wp_interactivity_state() without needing to call ->get_data().
plugins/woocommerce/src/StoreApi/Utilities/ProductQuery.php (1)
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#59499
File: plugins/woocommerce/src/Internal/ProductFilters/QueryClauses.php:327-332
Timestamp: 2025-07-10T04:22:27.648Z
Learning: In the WooCommerce ProductFilters QueryClauses class, the $chosen_taxonomies parameter in add_taxonomy_clauses() already contains only validated public product taxonomies. The validation occurs upstream in the Params class during parameter registration, so additional taxonomy existence validation in the processing methods is redundant.
plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/test/block.ts (9)
Learnt from: samueljseay
PR: woocommerce/woocommerce#59051
File: plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/mini-cart-contents/inner-blocks/mini-cart-footer-block/index.tsx:66-70
Timestamp: 2025-06-23T05:47:52.696Z
Learning: For WooCommerce mini-cart blocks in plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/, the standardized conditional pattern for experimental features should be `if ( isExperimentalMiniCartEnabled() ) { blockSettings.save = () => <InnerBlocks.Content />; }` - defaulting to the traditional Save component and only overriding when the experimental feature is enabled.
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#59499
File: plugins/woocommerce/src/Internal/ProductFilters/QueryClauses.php:327-332
Timestamp: 2025-07-10T04:22:27.648Z
Learning: In the WooCommerce ProductFilters QueryClauses class, the $chosen_taxonomies parameter in add_taxonomy_clauses() already contains only validated public product taxonomies. The validation occurs upstream in the Params class during parameter registration, so additional taxonomy existence validation in the processing methods is redundant.
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/blocks/checkout/inner-blocks/checkout-shipping-address-block/customer-address.tsx:76-90
Timestamp: 2025-06-13T13:37:35.793Z
Learning: In plugins/woocommerce/client/blocks/assets/js/blocks/checkout/inner-blocks/checkout-shipping-address-block/customer-address.tsx, the `shouldAnimate` flag is expected to be `false` only on initial render and may remain `true` after the first edit; it does not need to be reset.
Learnt from: samueljseay
PR: woocommerce/woocommerce#58716
File: plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/iapi-frontend.ts:83-101
Timestamp: 2025-06-17T07:07:53.443Z
Learning: In WooCommerce blocks, when porting existing code patterns that have known issues (like parseInt truncating decimal money values), maintain consistency with existing implementation rather than making isolated fixes. The preference is for systematic refactoring approaches (like broader Dinero adoption) over piecemeal changes.
Learnt from: gigitux
PR: woocommerce/woocommerce#58902
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-specifications/edit.tsx:205-206
Timestamp: 2025-06-17T12:40:54.118Z
Learning: In WordPress blocks, when there's a styling mismatch between editor and frontend, check if the PHP renderer (like in `ProductSpecifications.php`) adds specific classes to the output. If so, add those same classes to the `useBlockProps` className in the editor component (like in `edit.tsx`) to ensure consistent styling. For example, adding `wp-block-table` class to both frontend and editor ensures core table styles and theme customizations apply consistently.
Learnt from: gigitux
PR: woocommerce/woocommerce#58846
File: plugins/woocommerce/client/blocks/tests/e2e/tests/all-products/all-products.block_theme.spec.ts:41-52
Timestamp: 2025-06-16T09:20:22.981Z
Learning: In WooCommerce E2E tests, the database is reset to the initial state for each test, so there's no need to manually restore global template changes (like clearing the header template) as the test infrastructure handles cleanup automatically.
Learnt from: vladolaru
PR: woocommerce/woocommerce#59160
File: plugins/woocommerce/tests/php/src/Internal/Admin/Settings/PaymentsProviders/WooPayments/WooPaymentsServiceTest.php:360-373
Timestamp: 2025-06-25T15:39:25.166Z
Learning: Test mocks should accurately simulate the behavior of the functions they replace, including return value semantics. For WordPress functions like `update_option`, the mock should properly return `false` when the value hasn't changed and `true` when it has, to avoid masking logic errors in tests.
Learnt from: triple0t
PR: woocommerce/woocommerce#59186
File: packages/js/email-editor/src/store/initial-state.ts:9-10
Timestamp: 2025-06-26T12:13:32.062Z
Learning: In WooCommerce email editor store initialization (packages/js/email-editor/src/store/initial-state.ts), the current_post_id and current_post_type from window.WooCommerceEmailEditor are required parameters that should cause explicit errors if missing, rather than using fallback values or optional chaining. The design preference is to fail fast when critical initialization data is unavailable.
Learnt from: samueljseay
PR: woocommerce/woocommerce#59142
File: plugins/woocommerce/src/Blocks/BlockTypes/MiniCart.php:594-602
Timestamp: 2025-06-25T06:51:41.381Z
Learning: WooCommerce block templates have a predictable structure where each block has one top-level div with wp-block-woocommerce- class containing arbitrary nested content that should be preserved.
plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/edit.tsx (18)
Learnt from: gigitux
PR: woocommerce/woocommerce#58902
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-specifications/edit.tsx:205-206
Timestamp: 2025-06-17T12:40:54.118Z
Learning: In WordPress blocks, when there's a styling mismatch between editor and frontend, check if the PHP renderer (like in `ProductSpecifications.php`) adds specific classes to the output. If so, add those same classes to the `useBlockProps` className in the editor component (like in `edit.tsx`) to ensure consistent styling. For example, adding `wp-block-table` class to both frontend and editor ensures core table styles and theme customizations apply consistently.
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/blocks/checkout/inner-blocks/checkout-shipping-address-block/customer-address.tsx:76-90
Timestamp: 2025-06-13T13:37:35.793Z
Learning: In plugins/woocommerce/client/blocks/assets/js/blocks/checkout/inner-blocks/checkout-shipping-address-block/customer-address.tsx, the `shouldAnimate` flag is expected to be `false` only on initial render and may remain `true` after the first edit; it does not need to be reset.
Learnt from: samueljseay
PR: woocommerce/woocommerce#59051
File: plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/mini-cart-contents/inner-blocks/mini-cart-footer-block/index.tsx:66-70
Timestamp: 2025-06-23T05:47:52.696Z
Learning: For WooCommerce mini-cart blocks in plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/, the standardized conditional pattern for experimental features should be `if ( isExperimentalMiniCartEnabled() ) { blockSettings.save = () => <InnerBlocks.Content />; }` - defaulting to the traditional Save component and only overriding when the experimental feature is enabled.
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/base/utils/render-frontend.tsx:0-0
Timestamp: 2025-06-16T16:12:12.148Z
Learning: For WooCommerce checkout blocks, lazy loading was removed in favor of direct imports to prevent sequential "popping" effects during component loading. This approach prioritizes user experience over code splitting, with minimal bundle size impact and improved performance (1.7s to 1.1s speed score improvement). The checkout flow benefits from having all components load together rather than incrementally.
Learnt from: samueljseay
PR: woocommerce/woocommerce#58716
File: plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/iapi-frontend.ts:83-101
Timestamp: 2025-06-17T07:07:53.443Z
Learning: In WooCommerce blocks, when porting existing code patterns that have known issues (like parseInt truncating decimal money values), maintain consistency with existing implementation rather than making isolated fixes. The preference is for systematic refactoring approaches (like broader Dinero adoption) over piecemeal changes.
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#59499
File: plugins/woocommerce/src/Internal/ProductFilters/QueryClauses.php:327-332
Timestamp: 2025-07-10T04:22:27.648Z
Learning: In the WooCommerce ProductFilters QueryClauses class, the $chosen_taxonomies parameter in add_taxonomy_clauses() already contains only validated public product taxonomies. The validation occurs upstream in the Params class during parameter registration, so additional taxonomy existence validation in the processing methods is redundant.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/client/admin/client/settings-payments/onboarding/components/stepper/index.tsx:57-67
Timestamp: 2025-06-20T13:08:44.017Z
Learning: For WooCommerce Payments onboarding step tracking in useEffect hooks, only include the active step in the dependency array, not the context object. The sessionEntryPoint is static throughout the onboarding session and tracking should only fire on actual step navigation, not context changes.
Learnt from: vladolaru
PR: woocommerce/woocommerce#59160
File: plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/payment-methods-selection/index.tsx:0-0
Timestamp: 2025-06-26T14:56:54.917Z
Learning: In WooCommerce payments onboarding components (like plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/payment-methods-selection/index.tsx), when updating local React state based on API calls, the local state should only be updated after the API call succeeds to prevent inconsistent state if the save operation fails. The pattern is to move setPaymentMethodsState calls inside the .then() callback of the API promise.
Learnt from: triple0t
PR: woocommerce/woocommerce#59186
File: packages/js/email-editor/src/store/initial-state.ts:9-10
Timestamp: 2025-06-26T12:13:32.062Z
Learning: In WooCommerce email editor store initialization (packages/js/email-editor/src/store/initial-state.ts), the current_post_id and current_post_type from window.WooCommerceEmailEditor are required parameters that should cause explicit errors if missing, rather than using fallback values or optional chaining. The design preference is to fail fast when critical initialization data is unavailable.
Learnt from: NeosinneR
PR: woocommerce/woocommerce#0
File: :0-0
Timestamp: 2025-06-26T14:25:08.421Z
Learning: In WooCommerce transactional emails, product images have historically had display issues due to lazy loading attributes being applied, which email clients cannot process since they don't execute JavaScript. This issue existed in both old and new email templates, but became more visible with the new email template system. The fix involves preventing lazy loading on attachment images specifically during email generation by adding skip classes and data attributes.
Learnt from: opr
PR: woocommerce/woocommerce#0
File: :0-0
Timestamp: 2025-06-20T17:38:16.565Z
Learning: WooCommerce legacy JavaScript files in plugins/woocommerce/client/legacy/js/ must use older JavaScript syntax and cannot use modern features like optional chaining (?.) due to browser compatibility requirements. Explicit null checking with && operators should be used instead.
Learnt from: mikejolley
PR: woocommerce/woocommerce#57961
File: plugins/woocommerce/includes/class-wc-session-handler.php:302-333
Timestamp: 2025-06-19T11:58:57.484Z
Learning: In WooCommerce's session handler, the cart merging behavior was revised to always merge guest and user carts when both contain items, rather than having the guest cart take precedence. The migrate_cart_data() method in class-wc-session-handler.php implements this by using array_merge() to combine both carts when neither is empty.
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#59675
File: .github/workflows/release-bump-as-requirement.yml:48-65
Timestamp: 2025-07-15T15:39:21.815Z
Learning: In WooCommerce core repository, changelog entries for all PRs live in `plugins/woocommerce/changelog/` directory and are processed during releases, not at the repository root level.
Learnt from: Aljullu
PR: woocommerce/woocommerce#58809
File: plugins/woocommerce/src/Blocks/BlockTypes/ProductButton.php:222-225
Timestamp: 2025-06-13T17:11:13.732Z
Learning: In `plugins/woocommerce/src/Blocks/BlockTypes/ProductButton.php`, the team intentionally relies on toggling the `disabled` CSS class (via `data-wp-class--disabled`) instead of binding the `disabled` attribute, to mirror the behavior of the classic WooCommerce template.
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/base/components/cart-checkout/product-details/style.scss:21-26
Timestamp: 2025-06-13T15:24:45.923Z
Learning: In WooCommerce blocks, bold styling for `.wc-block-components-product-details__name` should be scoped only to the Cart block (`.wc-block-cart__main`); on the Checkout block, product names are not bold because prices are highlighted instead.
Learnt from: tpaksu
PR: woocommerce/woocommerce#59172
File: plugins/woocommerce/src/Internal/Fulfillments/Providers/MPLShippingProvider.php:14-21
Timestamp: 2025-06-26T10:47:27.212Z
Learning: In the WooCommerce fulfillments system, only the UPS shipping provider is currently fully implemented. All other shipping provider classes in plugins/woocommerce/src/Internal/Fulfillments/Providers/ are placeholders for future implementations, so empty shipping country arrays and stub methods in these classes are intentional and should not be flagged as issues.
Learnt from: opr
PR: woocommerce/woocommerce#59126
File: docs/block-development/tutorials/integrating-protection-checkout-block.md:63-81
Timestamp: 2025-06-25T14:13:13.090Z
Learning: The wp.data.subscribe() function in WordPress Block Editor accepts two parameters: a listener function (required) and an optional storeNameOrDescriptor (string|StoreDescriptor) to listen to changes on a specific registered store. When the second parameter is provided, the listener only fires on updates to that specific store.
Learnt from: samueljseay
PR: woocommerce/woocommerce#59142
File: plugins/woocommerce/src/Blocks/BlockTypes/MiniCart.php:594-602
Timestamp: 2025-06-25T06:51:41.381Z
Learning: WooCommerce block templates have a predictable structure where each block has one top-level div with wp-block-woocommerce- class containing arbitrary nested content that should be preserved.
plugins/woocommerce/tests/php/src/Blocks/StoreApi/Routes/ProductCollectionData.php (2)
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#59499
File: plugins/woocommerce/src/Internal/ProductFilters/QueryClauses.php:327-332
Timestamp: 2025-07-10T04:22:27.648Z
Learning: In the WooCommerce ProductFilters QueryClauses class, the $chosen_taxonomies parameter in add_taxonomy_clauses() already contains only validated public product taxonomies. The validation occurs upstream in the Params class during parameter registration, so additional taxonomy existence validation in the processing methods is redundant.
Learnt from: mreishus
PR: woocommerce/woocommerce#58891
File: plugins/woocommerce/src/Blocks/Utils/BlocksSharedState.php:0-0
Timestamp: 2025-06-16T21:59:26.255Z
Learning: In WooCommerce's CartSchema::get_item_response() method, when called in the context of BlocksSharedState::register_cart_interactivity(), the method returns a plain array rather than a WP_REST_Response object, making it directly suitable for wp_interactivity_state() without needing to call ->get_data().
plugins/woocommerce/src/StoreApi/Utilities/ProductQueryFilters.php (1)
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#59499
File: plugins/woocommerce/src/Internal/ProductFilters/QueryClauses.php:327-332
Timestamp: 2025-07-10T04:22:27.648Z
Learning: In the WooCommerce ProductFilters QueryClauses class, the $chosen_taxonomies parameter in add_taxonomy_clauses() already contains only validated public product taxonomies. The validation occurs upstream in the Params class during parameter registration, so additional taxonomy existence validation in the processing methods is redundant.
plugins/woocommerce/client/blocks/assets/js/base/context/hooks/collections/use-collection-data.ts (2)
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-06-30T09:26:55.361Z
Learning: Provide clear, step-by-step instructions for how to test the changes in the PR description.
Learnt from: vladolaru
PR: woocommerce/woocommerce#59160
File: plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/payment-methods-selection/index.tsx:0-0
Timestamp: 2025-06-26T14:56:54.917Z
Learning: In WooCommerce payments onboarding components (like plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/payment-methods-selection/index.tsx), when updating local React state based on API calls, the local state should only be updated after the API call succeeds to prevent inconsistent state if the save operation fails. The pattern is to move setPaymentMethodsState calls inside the .then() callback of the API promise.
plugins/woocommerce/src/StoreApi/Schemas/V1/ProductCollectionDataSchema.php (2)
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#59499
File: plugins/woocommerce/src/Internal/ProductFilters/QueryClauses.php:327-332
Timestamp: 2025-07-10T04:22:27.648Z
Learning: In the WooCommerce ProductFilters QueryClauses class, the $chosen_taxonomies parameter in add_taxonomy_clauses() already contains only validated public product taxonomies. The validation occurs upstream in the Params class during parameter registration, so additional taxonomy existence validation in the processing methods is redundant.
Learnt from: mreishus
PR: woocommerce/woocommerce#58891
File: plugins/woocommerce/src/Blocks/Utils/BlocksSharedState.php:0-0
Timestamp: 2025-06-16T21:59:26.255Z
Learning: In WooCommerce's CartSchema::get_item_response() method, when called in the context of BlocksSharedState::register_cart_interactivity(), the method returns a plain array rather than a WP_REST_Response object, making it directly suitable for wp_interactivity_state() without needing to call ->get_data().
🧬 Code Graph Analysis (1)
plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/utils/sort-filter-options.ts (1)
plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/types.ts (1)
FilterOptionItem(13-18)
🪛 PHPMD (2.15.0)
plugins/woocommerce/tests/php/src/Blocks/StoreApi/Routes/ProductCollectionData.php
183-183: Avoid unused local variables such as '$fixtures'. (Unused Code Rules)
(UnusedLocalVariable)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Remind reviewers to also review the testing instructions and test coverage
🔇 Additional comments (35)
plugins/woocommerce/changelog/59608-wooplug-4766-product-collection-data-api-add-support-for-taxonomy (1)
1-4: LGTM! Changelog entry correctly formatted.The changelog entry properly documents the taxonomy support addition to the Product Collection Data API endpoint with appropriate significance level and type.
plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/constants.ts (1)
8-24: LGTM! Improved genericity of preview data.The changes from "Sample Category" to "Sample Item" make the preview data more generic and appropriate for various taxonomy types, not just categories. This aligns well with the block's ability to work with different taxonomies.
plugins/woocommerce/src/StoreApi/Utilities/ProductQuery.php (3)
9-9: LGTM! Interface import added.The import statement for
QueryClausesGeneratorinterface is correctly added to support the interface implementation.
17-17: LGTM! Interface implementation added.The class now properly implements the
QueryClausesGeneratorinterface, which improves code structure and standardizes query clause generation.
350-353: LGTM! Method signature corrected and improved.The changes correctly:
- Fix the type hint from
\WC_Queryto\WP_Query(the previous type was incorrect)- Add proper array type hint for the
$argsparameter- Update PHPDoc to reflect the correct parameter types
These improvements enhance type safety and align with the interface requirements.
docs/apis/store-api/resources-endpoints/product-collection-data.md (4)
10-10: LGTM! Example URL updated correctly.The new example URL properly demonstrates how to use the
calculate_taxonomy_countsparameter with array notation.
13-19: LGTM! Parameter table updated correctly.The parameter table is properly updated to include the new
calculate_taxonomy_countsparameter with correct type (array), requirement (No), and clear description.
25-25: LGTM! Curl example updated correctly.The curl example properly demonstrates how to use the new
calculate_taxonomy_countsparameter alongside existing parameters.
67-81: LGTM! Response example updated correctly.The JSON response example properly shows the new
taxonomy_countsarray format with term IDs and their corresponding counts. The structure is consistent with other count arrays in the response.plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/utils/sort-filter-options.ts (1)
1-29: LGTM! Well-implemented sorting utility function.The function is excellently implemented with:
- Proper TypeScript typing and JSDoc documentation
- Comprehensive sorting options (name and count, both ascending and descending)
- Appropriate use of
localeComparefor internationalization-friendly string sorting- Efficient array sorting implementation
- Reasonable default case handling
The function provides a clean, reusable utility for sorting filter options that will be useful across the product filters functionality.
plugins/woocommerce/src/StoreApi/Schemas/V1/ProductCollectionDataSchema.php (2)
121-143: LGTM! Schema property follows established patterns.The
taxonomy_countsproperty definition is consistent with other count properties in the schema and follows WooCommerce API standards.
164-164: LGTM! Response method updated correctly.The
taxonomy_countsdata is properly included in the response following the same pattern as other count properties.plugins/woocommerce/src/StoreApi/Utilities/ProductQueryFilters.php (1)
217-250: LGTM! Well-implemented method using WooCommerce infrastructure.The
get_taxonomy_countsmethod follows best practices by:
- Removing pagination/sorting parameters consistently with other methods
- Leveraging WooCommerce's internal
FilterDataProviderinstead of custom SQL- Using array union operator to preserve term ID keys when combining results
- Following proper PHP documentation standards
The implementation integrates cleanly with the existing filtering infrastructure.
plugins/woocommerce/tests/php/src/Blocks/StoreApi/Routes/ProductCollectionData.php (4)
55-55: LGTM! Consistent test assertions added.The assertions for
taxonomy_countsbeing null in existing tests maintain consistency with the testing pattern for other count properties.Also applies to: 73-73, 107-107, 143-143, 163-163
179-278: LGTM! Comprehensive test coverage for taxonomy counts.The test method thoroughly covers:
- Single and multiple taxonomy scenarios
- Response structure validation
- Count accuracy verification
- Proper test data setup
The static analysis hint about unused
$fixturesis a false positive - the variable is used for test data creation.
291-291: LGTM! Collection params test updated correctly.The assertion ensures the new
calculate_taxonomy_countsparameter is properly registered in the route's collection parameters.
306-309: LGTM! Schema test properly updated.The schema test updates ensure the new
taxonomy_countsfield is properly validated by creating test data and including the parameter in the test request.Also applies to: 326-329
plugins/woocommerce/src/StoreApi/Routes/V1/ProductCollectionData.php (3)
76-76: LGTM! Response data initialization follows established pattern.The
taxonomy_countsfield is properly initialized to null, consistent with other count properties in the response data.
171-185: LGTM! Taxonomy counts calculation follows established patterns.The implementation properly:
- Validates the parameter and taxonomies array
- Calls the appropriate method on ProductQueryFilters
- Transforms results into the expected object structure
- Follows the same pattern as other count calculations
240-248: LGTM! Parameter definition follows REST API standards.The
calculate_taxonomy_countsparameter is properly defined with:
- Appropriate type (array of strings)
- Clear description
- Sensible default (empty array)
- Proper structure following REST API conventions
plugins/woocommerce/client/blocks/assets/js/base/context/hooks/collections/use-collection-data.ts (4)
49-58: LGTM! Interface updates follow TypeScript best practices.The interface properly adds the new
queryTaxonomyparameter while maintaining consistency with existing properties. The reformatting ofqueryAttributeimproves readability.
40-43: LGTM! Query building logic is consistent and appropriate.The handling of
calculate_taxonomy_countsfollows the established pattern and properly validates the array type before including it in the query.
78-81: LGTM! State management follows established patterns.The state management for
calculateTaxonomyCountsQueryStateproperly:
- Uses the same pattern as other query state management
- Prevents duplicate taxonomy entries
- Maintains array structure appropriately
- Follows React hooks best practices
Also applies to: 92-92, 124-138
65-65: LGTM! Hook parameter properly integrated.The
queryTaxonomyparameter is correctly integrated into the hook's functionality following established patterns.Note: The naming convention discussion from previous comments is acknowledged but marked as out of scope for this experimental PR.
plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/test/block.ts (6)
18-42: Mock implementation looks good!The mock properly preserves the original module's functionality while providing controlled test data for filterable taxonomies.
44-50: Schema selector mocks are appropriately minimal.These mocks prevent namespace errors while keeping the test environment simple and focused.
56-59: Good test setup standardization.Always setting
isPreview: trueensures consistent test behavior for editor preview scenarios.
99-111: Test correctly verifies taxonomy filter display.Good attention to detail in checking that the block label updates based on the selected taxonomy.
152-176: Product counts toggle test is comprehensive.Good coverage of both initial state and post-toggle behavior, with appropriate regex pattern for matching count indicators.
177-292: Excellent test reorganization and coverage expansion.The new test structure better reflects the UI organization with advanced controls grouped separately. The addition of product tags taxonomy test ensures multi-taxonomy support is properly verified.
plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/edit.tsx (5)
11-15: Import additions are appropriate for the new functionality.Good use of WordPress data APIs and type-safe utilities.
34-50: State initialization properly handles preview vs. real data modes.Good conditional logic for initial state based on preview mode.
83-89: Collection data hook properly configured for editor context.Good conditional logic to avoid unnecessary API calls in preview mode.
181-182: Loading state consolidation is well implemented.Combining multiple loading sources ensures consistent UI behavior.
199-216: Empty state handling provides good user feedback.The notice properly informs users when no products are associated with the selected taxonomy, with appropriate translation support.
d9b0409 to
714eb7a
Compare
- Add queryTaxonomy parameter to UseCollectionDataProps interface - Add calculate_taxonomy_counts query building support - Add state management for taxonomy counts with useQueryStateByKey - Add useEffect to handle taxonomy count requests - Enable taxonomy filtering support in product collection data API
…lity - Create reusable sortFilterOptions utility function for filter components - Update taxonomy filter to use real WordPress taxonomy terms via useSelect - Add real product counts via useCollectionData with queryTaxonomy parameter - Implement proper loading states waiting for both data sources - Add empty state handling following attribute filter pattern - Maintain preview mode with fake data for block inserter - Extract sorting logic to reusable utility for code reuse across filters
- Add integration tests for taxonomy filter block functionality - Test basic UI controls: taxonomy selection, product counts toggle - Test advanced controls: sort order, hide empty items - Mock WooCommerce schema selectors to prevent namespace errors - All 8 tests passing, validates core block functionality
- Fix test setup to use 'isPreview' instead of 'previewMode' - This allows UI tests to work with preview data correctly - All 12 tests now passing, including UI interaction tests - Tests cover count indicators, sort order, hide empty, and attribute combinations
714eb7a to
e2364fa
Compare
11 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Submission Review Guidelines:
Changes proposed in this Pull Request:
This PR update the Taxonomy Filters block to use real taxonomy data in the editor.
Closes WOOPLUG-4768.
Closes #59132.
How to test the changes in this Pull Request:
Using the WooCommerce Testing Instructions Guide, include your detailed testing instructions:
Changelog entry
Changelog Entry Details
Significance
Type
Message
Changelog Entry Comment
Comment
Experimental - Use real store data for previewing taxonomy filter block