Product Collection - Add Inherit query from template control #9485
Conversation
- `InspectorControls` from './inspector-controls' is now imported in `edit.tsx` and used in the returned JSX of `Edit` function. - A new file `columns-control.tsx` is added under 'product-collection' block's 'inspector-controls' directory which exports a `ColumnsControl` component. This component uses `RangeControl` from '@wordpress/components' to control the number of columns in the product collection display layout when the layout type is 'flex'. - The types file (`types.ts`) for 'product-collection' block is updated. The `Attributes` interface is renamed to `ProductCollectionAttributes` and the `ProductCollectionContext` interface is removed. The `ProductCollectionAttributes` now includes 'queryContext', 'templateSlug', and 'displayLayout' properties.
This commit simplifies the fallback return value of the ColumnsControl component. Instead of returning an empty fragment (<> </>), it now returns null when the condition isn't met. This change improves readability and aligns with best practices for conditional rendering in React.
This commit adds a new 'Order By' control to the product collection inspector. The control allows users to specify the order of products in a collection by various attributes such as title and date. To support this, a new component 'OrderByControl' has been created and included in the product collection inspector. Additionally, the types for 'order' and 'orderBy' attributes have been updated and exported for reuse.
…ocks into 9359-product-collection-editor-settings-order-by
|
The release ZIP for this PR is accessible via: Script Dependencies ReportThere is no changed script dependency between this branch and trunk. This comment was automatically generated by the TypeScript Errors Report
🎉 🎉 This PR does not introduce new TS errors. |
|
Size Change: +534 B (0%) Total Size: 1.1 MB
ℹ️ View Unchanged
|
The main changes include: 1. Added a new property 'isProductCollectionBlock' in the block.json to denote if a block is a product collection block. 2. In the ProductCollection PHP class, a new initialization function has been defined to hook into the WordPress lifecycle, register the block, and update the query based on this block. 3. Added methods to manage query parameters for both frontend rendering and the Editor. 4. Expanded allowed 'collection_params' for the REST API to include custom 'orderby' values. 5. Defined a function to build the query based on block attributes, filters, and global WP_Query. 6. Created utility functions to handle complex query operations such as merging queries, handling custom sort values, and merging arrays recursively. These improvements allow for more flexible and robust handling of product collections in both the front-end display and the WordPress editor. It also extends support for custom 'orderby' values in the REST API, which allows for more advanced sorting options in product collections.
kmanijak
added
skip-changelog
woocommercebot
requested review from
a team and
albarin
and removed request for
a team
There was a problem hiding this comment.
Hi @kmanijak, great job as always! 🙌🏻
I have tested the pull request, and it's working as described in the testing steps. 🚀
I wanted to mention that currently, in the Products beta block, we hide the "Inherit query from template" setting when it doesn't make sense, such as when adding the block to a post. Maybe we should do the same for the Product Collection block as well. What do you think? 🙂
At the moment initial query settings are hardcoded in the Product Collection. Change the default settings, for example by changing the order to desc in here
I merged the trunk with this branch, and now we have an option in the sidebar settings to change the order. Therefore, we won't need to perform this step 🙂
@imanish003, I agree. I added this logic in this commit, but there's a problem that I won't have time to fix. When adding the Product Collection, attributes are correctly set in the Editor (client-side rendered), but when you save with no changes and go to frontend then query is not consumed. This is due to fact that until any change is made in the inspector control and until
I tried extending this initial
|
…ocks into 9361-product-collection-filters-on-sale
…ction block This commit introduces several changes to the product collection block. - First, it adds a new 'on sale' filter that can be used to display only the products that are currently on sale. - It also refactors the settings management in the product collection block to use the experimental ToolsPanel component from WordPress, which provides a more flexible and intuitive way to manage block settings. - It moves the 'Columns' control into the ToolsPanel, along with the 'Order by' control. - A new utility function `setQueryAttribute` is introduced to simplify setting nested query parameters. - The structure of the `ProductCollectionAttributes` and `ProductCollectionQuery` types have been adjusted to accommodate the changes. - Finally, it makes corresponding changes in the PHP part to handle the new 'on sale' query parameter. This should enhance the flexibility and user-friendliness of the product collection block.
the taxonomy controls have been enhanced in the following ways: 1. Modified the BASE_QUERY object to include 'slug' in the '_fields' property. This will ensure that the 'slug' of the taxonomy term is fetched along with its 'id' and 'name'. 2. Added a 'slug' property to the Term type to store the 'slug' of each term. 3. Updated the useEffect hook inside the TaxonomyItem function to generate suggestions based on search results. The suggestions now include the 'slug' of a term if the term's name is not unique. This change will help users distinguish between terms with the same name but different slugs.
Following changes were made: 1. The useSelect hooks which were being used to fetch existing terms and search results have been moved into their own custom hooks named 'useExistingTerms' and 'useSearchResults' respectively. This simplifies the TaxonomyItem function's body and makes the hooks' purposes clearer. 2. The comments and props destructuring for the TaxonomyItem function have been moved up to make it easier to understand the function's purpose and the props it receives. 3. This refactor does not introduce any changes in functionality. It only changes how the code is organized and presented, which will make future development easier.
This commit enhances the `TaxonomyControls` component within `product-collection` block by adding memoization and improving term uniqueness handling. Changes: 1. Imported `useMemo` from `@wordpress/element` for memoizing certain results. 2. `getTermIdByTermValue` function has been modified to use a `termIdToNameMap` (term ids as keys and term names as values). This provides a more efficient and direct mapping for term search. 3. Introduced `useTermIdToNameMap` function, which returns a `Map` where term ids are keys and term names are values. It handles duplicate term names by appending the term slug to the name, ensuring unique term names. 4. Updated the `useExistingTerms` and `useSearchResults` to include `taxonomy` in their dependency arrays for `useSelect` hook. This will force re-computation when `taxonomy` changes. 5. Changed `TaxonomyItem` from a function declaration to a const arrow function, consistent with the rest of the codebase. 6. Updated `onTermsChange` function in `TaxonomyItem` to accommodate the changes in `getTermIdByTermValue` and the introduction of `termIdToNameMap`. 7. Replaced `Set` with a standard array for storing new term IDs in `onTermsChange`. The `Set` was unnecessary as term IDs are unique by default. 8. Updated `TaxonomyItem`'s effects and rendering to work with `termIdToNameMap`, ensuring the displayed term names are unique. This update will result in more efficient term search and handling, and it will solve issues related to duplicate term names.
This commit restructures the taxonomy controls in the product collection block for improved clarity and maintainability. - The file `taxonomy-controls.tsx` has been deleted, and its functionality has been divided into two new files: `index.tsx` and `taxonomy-item.tsx`. - The `index.tsx` file contains the main TaxonomyControls component, which is responsible for displaying taxonomy-related options in the block's inspector controls. It includes a custom hook `useTaxonomies` that fetches and returns taxonomies associated with product post type. - The `taxonomy-item.tsx` file, on the other hand, contains a TaxonomyItem component that handles the rendering of individual taxonomy items. It also contains some utility functions for mapping term names and ids and fetching terms based on the search query. This refactor aims to improve code readability and separation of concerns, thus making future changes and maintenance easier.
…github.com/woocommerce/woocommerce-blocks into add/product-collection-inherit
imanish003
changed the title
imanish003
changed the base branch from
trunk
to
9364-product-collection-filters-taxonomies
This change enhances the search functionality of the FormTokenField by introducing support for case insensitive search. This has been achieved by adding a lower-case version of the term name to the 'termNameToIdMap'. This is an important enhancement as it will make the search process more user-friendly and resilient to different casing inputs. Users will now be able to find the desired taxonomy term regardless of their input's case.
This commit does a couple of important things: 1. Reorders the definition of constants in `TaxonomyItemProps` for clarity. 2. Refactors the `getTermIdByTermValue` function. Instead of checking for an exact term name match in a convoluted manner, it now directly tries to fetch the `id` from the `searchTerm` if it is an object. If the `searchTerm` is not an object, the function tries to match it against the `termNameToIdMap` in both normal and lowercase forms. This simplification makes the function more readable and concise. 3. Updates the `newSuggestions` mapping in the `TaxonomyItem` component. It now has a fallback to `searchResult.name` if a term's name is not found in `termIdToNameMap`. This change ensures that even if the term's name is not in the map for some reason, we can still display a suggestion using the original name of the term.
This commit introduces a couple of improvements to the TaxonomyItem component. 1. The initial state of the 'search' state variable has been updated to 'undefined'. This change helps prevent unnecessary initial fetching of terms when the search input is empty. 2. Term fetching logic has been optimized to only enable term fetching when necessary: a) Fetching based on the search query is only enabled when 'search' is not 'undefined'. b) Fetching existing terms is only enabled when there are term IDs. 3. The block of code responsible for fetching existing terms and setting the current value has been moved upwards. This reordering of code does not change the functionality, but it groups together similar pieces of code, enhancing readability and maintainability. These optimizations make the component more efficient by reducing unnecessary requests and computations, and they improve the code organization.
…oduct-collection-inherit
…ocks into add/product-collection-inherit
| @@ -22,6 +22,8 @@ import { getDefaultSettings } from '../constants'; | |||
| const ColumnsControl = ( | |||
| props: BlockEditProps< ProductCollectionAttributes > | |||
| ) => { | |||
| if ( ! props.attributes.displayLayout ) return null; | |||
There was a problem hiding this comment.
I'm a bit confused by this change, does it have any relation to the rest of the PR or is it a generic code cleanup? (Sorry if it might seem obvious, but wanted to make sure I'm not missing anything)
As a side note, I noticed the ColumnsControl doesn't have any title or label. Is that on purpose? I feel it's a bit confusing to have a range input field without any info about what it does:
(No need to fix it in this PR, but wanted to mention it anyway 🙂 )
There was a problem hiding this comment.
I'm a bit confused by this change, does it have any relation to the rest of the PR or is it a generic code cleanup? (Sorry if it might seem obvious, but wanted to make sure I'm not missing anything)
Actually, there was an issue where the displayLayout sometimes became null. Therefore, I added an early return statement. However, I have now removed it in 34762c5 as it's no longer necessary due to other changes made in the commit.
I truly appreciate your thorough PR reviews. 🙇♂️
There was a problem hiding this comment.
As a side note, I noticed the ColumnsControl doesn't have any title or label. Is that on purpose? I feel it's a bit confusing to have a range input field without any info about what it does:
I have also added a missing label in 34762c5. Thanks for pointing this out 🙌🏻
| query={ | ||
| props.attributes.query as ProductCollectionQuery | ||
| } |
There was a problem hiding this comment.
Nit: this could be changed to query, now that we define it in line 33, no? Also, on the first render after inserting the block, query might be undefined, so I would remove or update the type (as ProductCollectionQuery). What do you think?
There was a problem hiding this comment.
Updated, Thanks for pointing this out 🙌🏻
| setQueryAttribute( { | ||
| inherit: initialValue, | ||
| } ); |
There was a problem hiding this comment.
Sometimes, when adding the Product Collection block into the Site Editor, I get this JS warning in the console:
Warning: Cannot update a component (
DocumentActions) while rendering a different component (InheritQueryControl). To locate the bad setState() call insideInheritQueryControl, follow the stack trace as described in...
Can you reproduce as well?
I think the error is caused by this setQueryAttribute(). If I'm understanding the code correctly, it's trying to update the state during the render function, which causes an unnecessary re-render and might cause other side effects. I think we should set the value of inherit to initialValue right when we read it, so in assets/js/blocks/product-collection/inspector-controls/index.tsx. Would that work? 🤔
There was a problem hiding this comment.
I can also see this warning. I have relocated the code responsible for calculating the inherit value to:
edit.tsx.
Now, I am setting the inherit value while defining the default attributes. Additionally, I have made some other minor improvements in 34762c5.
What are your thoughts on the recent changes? Do they look good to you?
There was a problem hiding this comment.
Yup, looks good. I initially thought the useEffect() would not be necessary, but I guess because of WordPress/gutenberg#7342, there is no way we can avoid it. 😞
This commit makes several changes: 1. The useEffect that sets the default attributes was moved and modified. This now includes a `query` attribute that utilizes the imported function `getDefaultValueOfInheritQueryFromTemplate`. 2. An early return was added in `edit.tsx` to prevent rendering until default attributes are set. 3. In `columns-control.tsx`, the early return was removed and a label was added to the `RangeControl` component. 4. In `inherit-query-control.tsx`, logic related to `inherit` value initial setting was refactored using a `useMemo` hook with `getDefaultValueOfInheritQueryFromTemplate` function. This logic was moved to a separate utility function in `utils`. 5. The `query` attribute is no longer optional in `types.ts`. 6. A new utility function `getDefaultValueOfInheritQueryFromTemplate` was created in `utils.tsx` to encapsulate the logic of deciding the default value of `inherit` query attribute based on the current template. These changes aim to improve code clarity and maintainability.
|
@Aljullu I have made the changes. Can you please take a look? 🙂 Also, I am immensely grateful for yet another remarkable PR review you have provided. Your consistent delivery of exceptional feedback is truly appreciated. Thank you for consistently going above and beyond in providing such outstanding feedback. 🙌🏻 🙇♂️ |
There was a problem hiding this comment.
Thanks for all the improvements, @imanish003. It looks good to me! 🚢
| @@ -10,11 +10,12 @@ import { useEffect } from '@wordpress/element'; | |||
| * Internal dependencies | |||
| */ | |||
| import { ImageSizing } from '../../atomic/blocks/product-elements/image/types'; | |||
| import { ProductCollectionAttributes } from './types'; | |||
| import { ProductCollectionAttributes, ProductCollectionQuery } from './types'; | |||
There was a problem hiding this comment.
Nit: should we intentionally use import type here?
| import { ProductCollectionAttributes, ProductCollectionQuery } from './types'; | |
| import type { ProductCollectionAttributes, ProductCollectionQuery } from './types'; |
There was a problem hiding this comment.
Although I don't have a strong opinion about this so I will go ahead and add the type with import. It might help in clarifying the intent. 🤝
| setQueryAttribute( { | ||
| inherit: initialValue, | ||
| } ); |
There was a problem hiding this comment.
Yup, looks good. I initially thought the useEffect() would not be necessary, but I guess because of WordPress/gutenberg#7342, there is no way we can avoid it. 😞
This PR adds a setting to Product Collection to inherit the global query.
When enabled:
Fixes #9358
Testing
Testing with Product Archive templates
shirteffectively displays related products.Here is a quick demo:
Screen.Recording.2023-05-30.at.5.47.05.PM.mov
Testing in Post
inherit query from templatedoes not appear in the list of options. This is because it's relevant only for Product Archive pages and should not be visible in this context.Screen.Recording.2023-05-30.at.5.48.55.PM.mov
WooCommerce Visibility
Changelog