RFC: Product Collection vs Synced Patterns and Template Parts #46791
Replies: 4 comments 27 replies
-
Hey @kmanijak -- here's my understanding of the problem:
Some additional observations:
Some ideas that may point to a solution:
|
Beta Was this translation helpful? Give feedback.
-
What scenarios would have people use Product Collections in a synced pattern? Is it feasible to not enable usage in synced patterns or template parts for now while figuring out the UX issues for those cases? |
Beta Was this translation helpful? Give feedback.
-
Some other thoughts/questions. I'm wary of coupling context/area to saved patterns. I'm thinking of the scenario where there are layouts that have to be duplicated for all the different contexts/areas that the pattern might be used in. Rather than always coupling context have we considered:
|
Beta Was this translation helpful? Give feedback.
-
I love the ongoing dialogue and appreciate the those of you flashing the warning lights of "overengineering" :) It sounds like some of us don't like the idea of formalizing context at the Pattern level -- the voices worrying that we might be engineering something major here just to address something minor must be heard.
At the block level, we want to expose additional (contextual) capabilities in a way that feels intuitive to the user and requires no additional decisions to be made, and therefore:
Not sure yet. I prefer to keep things simple at all costs though :) As I said, I don't want us to be solving problems that the user doesn't have or doesn't care about. Here's something we have to decide first. Consider the following Scenario:
In this scenario, should the user see any of the contextual capabilities that they enabled on the Product Collection block ("current taxonomy" filters) while editing the Pattern, or not? If your answer here is "yes", remember that this is what creates the need to introduce constraints/guardrails around the use of this Pattern relative to context. Thinking about this myself, I would say "no", because:
For non-synced patterns, it's easy for me to imagine that they have to expose only context-less features (=render assuming "Site" context) when the Pattern is edited. The "context-sensitive" configuration will be provided by (and exposed to) the user depending on where they utilize the Pattern. So far so good. As @nerrad said:
Now consider this:
In this scenario, I believe that contextual capabilities should be:
What should users experience when they insert the Pattern in any context?
And what will users experience when they create a synced Pattern from scratch? I think that a good simplification (and way forward) here would be to disable all contextual capabilities in this environment/scenario (= assume "Site" context only). Thoughts? |
Beta Was this translation helpful? Give feedback.
-
This RFC touches on the conflict between the contextual nature of the blocks (example of Product Collection in contextless places like Synced Patterns and Template Parts. We don’t have a good answer on how to proceed with that conflict and if the features/requirements we came up with for Product Collection are feasible long-term.
Problem – in short
Some blocks, especially Product Collection and its Collections generate content that is only meaningful in association with an object:
Some collections/blocks may behave differently in different contexts (e.g. product vs cart upsells) and/or may expose different/additional capabilities/options to the user (e.g. contextual filters, such as “current category”, and/or other options).
Context influences what can be previewed in Editor. From a preview perspective, context can be partially or fully resolved in the Editor. For example:
We know that we’re Editing in the “product” context when we’re editing the Single Product template.
If we’re editing the Single Product template of a specific product, we also know its ID.
In the latter case, we can render content that more closely resembles what shoppers will see in the frontend. We anticipate that this will become more and more important as we work to enable more store customization capabilities at the product level — for example, knowing a context fully could enable us to render additional Add To Cart Form inner blocks, to enable users to customize the presentation of individual product features, such as variations, add-ons, bundled products, etc.
In many cases, and for blocks that require a primary working context, we want to allow the user to provide it manually. For example, a user may want to put together a Product Comparison Table on a landing page, complete with Price and Add To Cart button blocks. Because the products associated with these blocks cannot be known in the context of a WP page or post, we want to guide users to manually do the association.
Based on the above, we have identified 5 contexts that we want to formally define (and may later extend): Site (generic), Product, Archive, Cart, and Order.
Our ability to detect “Woo context” in the Editor fails when a block is inserted in a Template Part or Synced Pattern.
We could fall back to “Site” context, however, the user may intend to utilize that Template Part or Pattern in a location where context might reveal additional capabilities:
Problem – long version
What is Product Collection block and collections?
In terms of functionality, Product Collection is a block similar to Query Loop. Query Loop displays a list of posts, while Product Collection displays a list of products. One of the key differences is the Product Collection is multipurpose.
We introduced a concept of “collections” to address different merchants’ needs. For instance, there are “On Sale” or “New Arrivals” collections. Collections have the same UI representation but their query attributes differ. For example:
onSale
flag set to true,alphabetical
order by default.newest to oldest
order.So far, so good.
Contextual collections
Choosing context manually
We plan more complex collections that generate different results depending on the context, for instance, “Upsells” or “Cross-Sells”. These collections need to know product context. This is not a new problem – often this is solved by prompting merchants to choose the product like in Reviews by Product block:
Detecting context automatically
We want to make Product Collection smarter than that and detect the context automatically based on location in the Editor and only if unavailable, prompt the user to choose one. Here’s the flow on the diagram with the Upsells as an example:
The above use case was just an example, but there’s more:
Viewed but not Bought
which is added by the Product Recommendations plugin. It’ll be visible in the order context but hidden in others.Same as currently viewed
to use the available context.These are the context/location types we defined (that list may be extended in the future):
product_cat
orproduct_tag
taxonomies.We implemented the context/location recognition in this PR: #43997.
The problem: context in Template Parts or Synced Patterns.
All the contextual mechanisms fail when we combine Product Collection with Template Parts or Synced Patterns.
Viewed but not Bought
that should be available only in Order context).Request for Comments, Questions, and Concerns
These are examples based on designs we have but obviously there’s bigger potential in the contextual nature of blocks. However, we should not continue exploring them until we answer the key questions:
Thank you!
Beta Was this translation helpful? Give feedback.
All reactions