Product Collection block - data flow

[kmanijak]

Background

A few weeks ago we kicked off the development of Product Collection block. The idea behind this block is that it will replace the Products (Beta) block. Products (Beta) block was built as a variation of Query Loop block which gave us an advantage at the beginning, but we also faced multiple limitations while developing more advanced features. Based on the GitHub discussion: https://github.com/woocommerce/woocommerce-blocks/discussions/9010 we decided to start development of a standalone block that will cover Products (Beta) block functionalities, and, thanks to greater flexibility, allow us to provide more features in a shorter time.

Problem statement - data fetching

One of the challenges we faced with the Products (Beta) block was data (over)fetching in Editor.

Note: that applies only to Editor side - frontend is server-side-rendered, while Editor side is client-side-rendered and that’s where data fetching could be optimised.

In short:

Query Loop block does its own fetching of product postType data via getEntityRecords method (wp-json/wp/v2/product). Some of that data is then passed down through the context to the blocks like core/post-title. There’s one request for the whole set of products (posts) being rendered within the Query Loop.

Products (Beta) block is using Product Elements as inner blocks (e.g. woocommerce/product-price or woocommerce/product-rating and others). All of the Product Elements share the same React context. The first element that gets to be rendered for a particular product, triggers data fetch from Store API for this product (wp-json/wc/store/v1/products?include={id}). There are as many requests as many products are rendered within Query Loop.
(ref: per0F9-tT-p2)

As we can see there are opportunities here to optimise data fetching.

Products (Beta) is a variation of Query Loop block, hence we’re constrained by its implementation, however, with Product Collection block being a standalone block, we can optimize it significantly which is a scope of this issue: https://github.com/woocommerce/woocommerce-blocks/issues/9268.

Product Collection optimisations

Idea 1 - get all products from Store API in one request

The first approach to optimize data fetching was to stop using getEntityRecords and rely fully on the Store API. Also, instead of making requests for each product separately, we could get all the products at once and pass them downstream to the inner blocks.

Pros	Cons
Straightforward solution	Relies on the Store API as a data source
Doesn't require data transformation	Product Title and Product Summary are still core blocks variation, hence require their own data
	We should probably use Product Title and Product Summary from Product Elements
	Because of the way Product Elements are structured, there's still additional request being made for products that we cannot get rid of without major refactoring. More details in a spoiler below *

It was suggested to explore other paths of getting the data to make Product Collection block better suited for other views (like Product Editor).

This idea was implemented as a first one and is available at this commit (be aware it still had troubles with Product Title and Product Summary which were not displayed correctly at that commit).

* More details about an unnecessary call mentioned in Pros and Cons table

There's still one unnecessary request made for products (with incorrect query details). This is due to the way with-product-data-context HOC is organized. There's a hook to fetch the product data and even though the product is provided and data from the hook will be ignored (check [if statement here](https://github.com/woocommerce/woocommerce-blocks/blob/trunk/assets/js/shared/hocs/with-product-data-context.js#L35)), it's still making a request. By default, it would make a request per each product separately, however thanks to the different data structure, the id [here](https://github.com/woocommerce/woocommerce-blocks/blob/trunk/assets/js/shared/hocs/with-product-data-context.js#L24), is not defined, hence there's just a single call made. This requires rethinking/refactoring, however, we need to keep in mind All Products and Products block (and potentially others) in which Product Elements are in use.

Idea 2 - rely on getEntityRecords and redirect the call with api-fetch middleware to WooCommerce REST API

This idea was raised as a code review idea.

WooCommerce Blocks relies mostly on Store API developed way before the entity data store (@wordpress/core-data) was created.
The idea is that we should rely on getEntityRecords method and intercept the request to redirect it to WooCommerce REST API in order to fetch the products data by @wordpress/api-fetch middleware. In that case, we rely on the core mechanism to get data and API that's designed to be used in the admin site.
(Ref: pdToLP-Aj-p2)

The data flow in such a scenario is as follows:

1. In Product Template block we get the data through getEntityRecords( 'postType', 'product', finalQuery ) which underneath makes a call to WordPress REST API (/wp/v2/product). It returns data about the products as posts which is not useful for us.
2. We register a middleware via @wordpress/api-fetch which intercepts the request and redirect it to WooCommerce REST API (/wc/v3/products). At this stage we need to map the query parameters from one API to another, so they’re compatible and make a request. Worth to mention that middleware API is pretty limited and doesn't give access to the whole request, but only to a subset of data. In most cases, it's just a path, sometimes headers.
3. Returned data is in an incompatible shape, so we need to transform it to the shape that we would get from Store API (/wc/store/v1/products). This is also happening in the scope of the middleware.

The biggest problem here is that we cannot reconstruct the expected data shape based only on the fetched data, but we need to reach out to other resources as well.
But we need to keep in mind it happens on the front-end and we don’t have access to all the data available in the back-end, so that may require additional API calls.

Let’s take a look at images property as an example:

images from Store API:

images: [
    {
        id: 44,
        src: 'http://your-shop-domain/wp-content/uploads/2023/04/album-1.jpg',
        thumbnail:
            'http://your-shop-domain/wp-content/uploads/2023/04/album-1-450x450.jpg',
        srcset: 'http://your-shop-domain/wp-content/uploads/2023/04/album-1.jpg 800w, http://your-shop-domain/wp-content/uploads/2023/04/album-1-450x450.jpg 450w, http://your-shop-domain/wp-content/uploads/2023/04/album-1-100x100.jpg 100w, http://your-shop-domain/wp-content/uploads/2023/04/album-1-600x600.jpg 600w, http://your-shop-domain/wp-content/uploads/2023/04/album-1-300x300.jpg 300w, http://your-shop-domain/wp-content/uploads/2023/04/album-1-150x150.jpg 150w, http://your-shop-domain/wp-content/uploads/2023/04/album-1-768x768.jpg 768w',
        sizes: '(max-width: 800px) 100vw, 800px',
        name: 'album-1.jpg',
        alt: '',
    },
],

images from WooCommerce Store API:

images: [
    {
        id: 44,
        date_created: '2023-04-19T12:15:15',
        date_created_gmt: '2023-04-19T12:15:15',
        date_modified: '2023-04-19T12:15:15',
        date_modified_gmt: '2023-04-19T12:15:15',
        src: 'http://your-shop-domain/wp-content/uploads/2023/04/album-1.jpg',
        name: 'album-1.jpg',
        alt: '',
    },
],

Our Image block relies on srcset , and sizes properties. These properties are easily accessible via:

• wp_get_attachment_image_srcset
• wp_get_attachment_image_sizes

methods on Product object, but we don’t have direct access to it on the front-end.

Options to overcome this:

• One option to get this data is to request them via Store API (requesting for products). I don’t think that’s a good idea - we want to avoid that call.
• Reimplement the logic of these methods in a scope of the transition layer. This doesn’t sound like a good idea, as it opens the path to duplicate a lot of core logic in the front-end.
• Extend the WooCommerce REST API. I haven’t tried that yet, but found some examples (example). But I think it would get messy, if we have to extend the API on the back-end side, to still intercept the request and manipulate the data on the front-end.
• The best option from my perspective would be to start contributing to the WooCommerce REST API and extend the responses with additional fields that would allow us to use the responses directly with only some data transformation.

If there are any other options you see - I’m open to suggestions!

Let’s keep in mind there are more differences like that, but some of them are easier to resolve. Also, I'd like to highlight that the data flow from the diagram is equivalent to calling the Store API directly from Product Template because essentially we get back a Store API-like data shape.

This whole idea is partially implemented in WIP PR.

Pros	Cons
Gets us closer to the stage where Product Collection could be more reusable (e.g. Product Editor)	Gets complicated, while at the same time, it's not the final state we'd like to achieve
Allows to use Title and Summary blocks as variations.	It's not optimal as it requires additional data fetching
	Eventually, from a blocks perspective, this pattern is equivalent to calling Store API (except for the permissions)
	Adds maintenance cost by keeping the compatibility between WooCommerce REST API and Store API

Idea 3 - rely on getEntityRecords and redirect the call with api-fetch middleware to Store API

We could implement the previous solution, but redirect the request to the Store API instead. In that case, we make a step towards getting data in a standardized way, but for the time being, we avoid the overhead of adjusting the data from WooCommerce REST API to Product Elements.

Also, with little response modification (showcased in this commit), we can easily use Product Title and Product Summary blocks as data is already stored in a store from which those blocks take the data.

Pros	Cons
Fairly straightforward - still uses middleware, but data manipulation is very little	Doesn't utilize WooCommerce REST API
Allows us to easily use core blocks variations (Title and Summary)

Suggested next steps

My suggestion is to go with "Idea 3 - rely on getEntityRecords and redirect the call with api-fetch middleware to Store API". It simplifies the data fetching that's happening in Products (Beta) block. This allows us to easily use Product Title and Product Summary as a variation of core blocks.

Also, even though I see potential benefits of "Idea 2 - rely on getEntityRecords and redirect the call with api-fetch middleware to WooCommerce REST API", I don't think the value of this solution outweighs the effort and complexity it requires.

Feedback required

I’d like to get feedback on how you think we should proceed with this before investing too much time into Idea 2 which is currently being implemented.

CC: @nerrad (I'd really appreciate your input considering you suggested exploring the Idea 2 🙏 ), @imanish003, @tjcafferkey

[tjcafferkey]

Thanks for bringing this discussion up @kmanijak! I appreciate the thought you've put into this, providing us with multiple possible solutions and giving us a detailed brief with the pros and cons that come with each option.

From my point of view Idea 3 sounds like the best solution based on how you've presented them so I think we're aligned on this. However, I am also interested to hear from @nerrad on his thoughts, specifically on Idea 2. Mostly because it appears to be quite complex and I'm wondering if we're missing some additional context on why this could be a good option to go with.

As for Idea 1, given that it still leaves us with some additional requests being made, it still reduces the overall requests (I think, right?) so even though there may still be some performance concerns it's still an improvement which can be further iterated on in future. I'm also interested to hear why "Relies on the Store API as a data source" is listed as a con here. Since @\opr did a talk at WCEU which included usage of, and ways to extend the Store API I'm wondering why we're seeing this as a "con" so some more information would be helpful here!

In summary, I'm aligned with you on Idea 3. I think it addresses both a reduction in complexity and improved performance but let's wait to see some further thoughts from others. Perhaps I'm missing something! (It wouldn't be the first time haha)

[imanish003]

Hi @kmanijak, Thank you for a very detailed post. This will be very helpful in making the right decision. 🙌🏻

I concur with your & @tjcafferkey's assessment and find "Idea 3 - rely on getEntityRecords and redirect the call with api-fetch middleware to Store API" the most appealing due to its relative simplicity and minimized data manipulation. It also facilitates compatibility with core blocks like Title and Summary, which aligns with the overall philosophy of Gutenberg blocks.

Regarding "Idea 2", I share the same concerns that it might introduce additional complexity and maintenance cost. Although I acknowledge that it might provide a path to a more reusable Product Collection block in the long run, the trade-off between potential benefits and the implementation complexity appears unfavorable at this stage.

Regarding "Idea 1", I don't think this is a good solution because this isn't compatible with variations.

In conclusion, I believe "Idea 3" provides the most straightforward, maintainable approach for the present.

I'm eager to hear other perspectives on this, particularly from @nerrad, as his input could provide additional insights and factors to consider. 🙂

[joshuatf]

Thanks for this fantastic write-up @kmanijak!

Idea 3 - rely on getEntityRecords and redirect the call with api-fetch middleware to Store API

I think this at first glance seems like a good short-term solution, but has the potential to set us up for issues long-term. The product editor also uses middleware to route requests from the /wp/v2/product endpoint to /wc/v3/products and currently does so only if it detects that we're on one of the new product editor pages.

This seemingly works well and would guard against calls to the wrong API, however, as we move towards more React client-side routes, there is potential to hit the same getEntityRecords selector and query, resulting in showing the cached resolution of the previous call. If the Product Collection block initially made a call and then subsequently a new (not yet created) Products List page made this call, the shape of the data would be mismatched and unexpected by the consumer.

While #37621 implemented a quick solution, I think we should look at reverting back to using the server-side registered endpoint and making calls for product information consistent, at least wherever we're using getEntityRecords.

The best option from my perspective would be to start contributing to the WooCommerce REST API and extend the responses with additional fields that would allow us to use the responses directly with only some data transformation.

I tend to agree with this as long as the information being added is not specific to blocks, but useful to all consumers of the REST API. Note that we can also return different data by passing a context param. This context param could also be used with the middleware solution to act as a form of cache-busting or differentiation between the requester of the entity records and still use the Store API in some cases, but I think this could also get messy quickly and would favor pushing changes upstream to core's API response if possible.

[gigitux]

This seemingly works well and would guard against calls to the wrong API, however, as we move towards more React client-side routes, there is potential to hit the same getEntityRecords selector and query, resulting in showing the cached resolution of the previous call. If the Product Collection block initially made a call and then subsequently a new (not yet created) Products List page made this call, the shape of the data would be mismatched and unexpected by the consumer.

Great observation. I'm not sure how it works and how much is powerful, but it seems that there is a way to invalidate the cache.

My main concern is how to invalidate the cache across multiple tabs experience. A user has two tabs:

1. Product Editor
2. Post Editor

If the user adds a product via the product editor and adds a new Product Collection block on the post editor, the cache will not invalidate, the user will not see the new product.

[kmanijak]

Great observation. I'm not sure how it works and how much is powerful, but it seems that there is a way to invalidate the cache.

I didn't dive deep into this, but I think that with forced cache invalidation, we lose the benefits of the entity store if we decide to invalidate cache with each call to the store 🤔 Or you think to have some criteria whether to invalidate cache?

[gigitux]

Or you think to have some criteria whether to invalidate cache?
This. We should find some criteria. We need to do an exploration.

If the Product Collection block initially made a call and then subsequently a new (not yet created) Products List page made this call, the shape of the data would be mismatched and unexpected by the consumer.

At this stage, I think that this could happen only when the merchant has two tabs open (as I described above).

[joshuatf]

Can I confirm you mean to avoid using the middleware and use addEntities to register a new endpoint (in our case Store API) like in this Stack Overflow example? That's a nice idea to explore!

If we were to go with something along the lines of idea 3, yes, I think that registering a new entity could be an option.

But I would opt for moving towards something more along the lines of idea 2, including any information needed upstream in the REST API response of those core routes, and then adjusting blocks slightly to be able to adapt to the response. I think this is in line with what @nerrad is thinking as well, but correct me if you were thinking something different, Darren.

Great observation. I'm not sure how it works and how much is powerful, but it seems that there is a way to invalidate the cache.

Definitely @gigitux! We can invalidate via invalidateResolution or invalidateResolutionForStoreSelector within the store's dispatch actions. But as you mentioned, this would require both editors to be aware of the cached state and what the shape of that data looks like in order to invalidate, which is not sustainable.

I didn't dive deep into this, but I think that with forced cache invalidation, we lose the benefits of the entity store if we decide to invalidate cache with each call to the store 🤔 Or you think to have some criteria whether to invalidate cache?

@kmanijak it's feasible to create a context provider which determines the area of the admin we're in and applies middleware as well as invalidates cache if resolution has already been completed. However, this feels like a cascading issue where we'd be forced to constantly be aware of this custom context and which endpoint the entity store is actually hitting. This applies to not only work done within WooCommerce core and WooCommerce Blocks, but any other plugins that may use entity data, including 3PD plugins.

Even though it's possible to change the endpoint and shape of data returned for a specific entity, we should attempt to keep these consistent for a specific entity across all plugins.

At this stage, I think that this could happen only when the merchant has two tabs open (as I described above).

I believe data stores don't persist across tabs, but only a single tab so this would be very hard to hit at this moment. Though as we migrate towards something of a "universal" block and client-side routing, this will become a more prominent issue.

[nerrad]

I think this is in line with what @nerrad is thinking as well, but correct me if you were thinking something different, Darren.

Yup, this would allow for using WP core blocks that rely on the entity data from the post entity.

[nerrad]

The biggest problem with Idea 3 is that the Store API is a unauthed endpoint with no built-in permissions. In the editor context we need to use an endpoint that does support permissions checks so we could also implement the useCanEditEntity hook (eventually). Without that, it will be much harder to eventually implement in place editing of product data. The other benefit is that we could potentially support using the same block in all editor contexts including product editor.

I don't think we should necessarily worry about changing the shape of the incoming request to the same as the Store API, but instead adapt the blocks to consume from the wc/v3/products endpoint. The point I made elsewhere about adapting the shape was more about enhancing the response (or modifying the response via middleware if possible) to include the data in the shape the WP core blocks (Title, Featured Image) would expect when retrieving from the entity store. Since it's apparent you're not able to do that via the request middleware, we'd have to investigate modifying the wc/v3/products response to include that data (or maybe a v4 that is more aligned with the WP response objects).

To be clear, there's a couple of important caveats:

• The All Products and blocks specific to it that are rendered on the frontend using the data stores should be excluded from this change. Obviously they must be using a unauthed endpoint. It may be time to aggressively deprecate those blocks (and I know it expands the scope because we currently share some blocks between those contexts. Depending on the degree of changes, we may need to look at lifting up the changes to a provider that handles using the entity data store, or the storeAPI store and implement it over the relevant blocks.
• Cart and Checkout blocks (and their inner blocks) as well as the Mini-Cart block, should continue to use the existing hooks consuming the Store API. Given their context, they will never have product related content edited in the editor.

[kmanijak]

Thanks @nerrad!

Since it's apparent you're not able to do that via the request middleware, we'd have to investigate modifying the wc/v3/products response to include that data (or maybe a v4 that is more aligned with the WP response objects).

Do you know when v4 may be available to use?

About extending/modifying the WC API this is in line with other suggestions as well (e.g. @nefeline 's comment here). This is also something we've discussed with @imanish003.

Considering that this work (including potential changes to the providers and product elements themselves) may be pretty time-consuming, I think we may postpone implementing it until the first iteration of Product Collection block is released with the current data fetching strategy. In that case, we'd be able to collect feedback about the block and then focus on improving data provisioning. In the meantime, we can still continue to discuss it. What do you think about that? Do you consider this work a must-have before releasing the block?

The All Products and blocks [...] It may be time to aggressively deprecate those blocks (and I know it expands the scope because we currently share some blocks between those contexts. Depending on the degree of changes, we may need to look at lifting up the changes to a provider that handles using the entity data store, or the storeAPI store and implement it over the relevant blocks.

By "be time to aggressively deprecate those blocks", do you mean the whole blocks including the UI layer, or just the provider layer? I think we would be able and actually should reuse the UI of these blocks, but rather deprecate/replace the data provision layer only (which now I understand better that you actually started to experiment with within Price block, am I right?) 🤔

[nerrad]

Do you know when v4 may be available to use?
I think that would largely be up to whoever contributes to it and the collaboration with other teams that could be consumers. It's still not a definite thing that a v4 is needed though.

Considering that this work (including potential changes to the providers and product elements themselves) may be pretty time-consuming, I think we may postpone implementing it until the first iteration of Product Collection block is released with the current data fetching strategy. In that case, we'd be able to collect feedback about the block and then focus on improving data provisioning. In the meantime, we can still continue to discuss it. What do you think about that? Do you consider this work a must-have before releasing the block?

I don't think it's necessarily a must-have before the initial release (would appreciate your input here on that point too @joshuatf) but definitely something that should be tackled soon after. There are some particular concerns around the data layer and the work on the Product Image Gallery block since that's likely the best block to do some initial explorations for it working in the product editor context too.

By "be time to aggressively deprecate those blocks", do you mean the whole blocks including the UI layer, or just the provider layer?

Depends on how much the layers are coupled in the current implementations. From my work on the price block I did see some coupling that would be hard to untangle for certain blocks.

[joshuatf]

I don't think it's necessarily a must-have before the initial release (would appreciate your input here on that point too @joshuatf) but definitely something that should be tackled soon after. There are some particular concerns around the data layer and the work on the Product Image Gallery block since that's likely the best block to do some initial explorations for it working in the product editor context too.

@kmanijak @nerrad I don't think this is an absolute "must-have," but agree that we should aim to tackle this as soon as possible. Mentioned in this comment but short-term where we'll see conflicts is in "universal" (shared) blocks.

As long as we understand that by doing this we are creating a combination of blocks and core versions that are incompatible due to entity store shape, I think it's okay to release this. This is probably not a major issue since:

1. We don't yet share the blocks and will still have an opportunity to correct this problem in the editor by replacing it with the blocks version when the time comes.
2. The product editor is still very much in its infancy and breaking changes are expected at this point.

Ultimately, I'd like avoid middleware for enhancing or changing data shape as this will lead to unexpected responses for consumers relying on those data stores. The server-side registered endpoint for a post type is the one consumers should rely on and I would even argue that the code registering the post type should be solely responsible for defining this endpoint.

[nerrad]

Specific to images

I think we should try to make sure that our endpoints return images in the same shape as WP core REST endpoints do. Having srcset information (at a minimum) is fairly important for consumers.

[gigitux]

Thanks for starting this discussion, @kmanijak!

The biggest problem with Idea 3 is that the Store API is a unauthed endpoint with no built-in permissions.

I agree.
I suggest following idea 2 (use WooCommerce API) as a long-term solution. Using the same endpoint of the new product editor could help us re-use some logic across the two projects and share some blocks!

[nefeline]

Thanks for your work on this and for sharing this detailed exploration @kmanijak! My thoughts on this topic are:

IMO, the best solution is extending the WooCommerce REST API to fit our needs and upstream only the changes that can benefit the whole community. WooCommerce already has at least three different APIs: the core API, the store API, and the analytics API: IMO, this is an excellent opportunity to improve the current version of the core's API, and/or help pave the path for a new version. I believe this also allows us to move towards consolidating it into a single source of truth and perhaps deprecate the Store API at some point in the future (def. not right away, as @nerrad mentioned that other blocks still consume it).

Elaborating a bit more on my opinion:

Extend the WooCommerce REST API. I haven’t tried that yet, but found some examples (example). But I think it would get messy, if we have to extend the API on the back-end side, to still intercept the request and manipulate the data on the front-end.

It is true that we would still need to intercept the request, but if we extend the WooCommerce REST API, we can shape the data to 100% fit our needs, so manipulating the data on the front end is unnecessary. Also, from my perspective, this is the ideal scenario: with the API returning the data with the shape and form we need, our components are cleaner/streamlined and solely focused on display/styles rather than modifying the API's response as an initial step.

The best option from my perspective would be to start contributing to the WooCommerce REST API and extend the responses with additional fields that would allow us to use the responses directly with only some data transformation.

From my perspective, focusing 100% on extending the core's API to serve our needs in this first moment is the ideal path to expedite things, as not all of our use cases will be fully aligned with what the rest of the community needs. As a follow-up task, we can then evaluate each one of our customizations and, in collaboration with other teams (most likely Proton), decide which ones are beneficial enough on a large scale and incorporate those into the core.

[nerrad]

perhaps deprecate the Store API at some point in the future (def. not right away, as @nerrad mentioned that other blocks still consume it).

I don't think we need to deprecate the Store API. It has a very specific use case geared towards public non authenticated endpoints (including handling Cart and Checkout flows). There is still value in keeping this separate from the other WooCommerce REST routes.

[nefeline]

It has a very specific use case geared towards public non authenticated endpoints (including handling Cart and Checkout flows - which will be "shopper authenticated"). There is still value in keeping this separate from the other WooCommerce REST routes.

👍 Gotcha, thanks! Out of curiosity, do you see value in incorporating this API into the core at some point (or maybe parts of it)? Could someone implementing a headless store of some sort benefit from it as well? If the answer is no, is it because it's too tailor-made to our use case?

ps: I edited my question as I noticed the first version wasn't very clear =).

[nerrad]

I guess we should avoid saying the Store API will never eventually be merged into some other API, but keep in mind Store API is already considered a stable API for WooCommerce core and also has had work done on it to make it more useful for "headless" shopper experiences or_ other use-cases (which is one of the reasons why it is a separate API). WooPay is using it.

Think of this way:

• WooCommerce REST API - merchant/store management context.
• Store API - shopper context.

The distinction above has always been a bit blurry because the WP editor is WYSIWYG so things like Cart and Checkout are using the Store API even in the editor views. Yet, we're moving the rest of the Woo Blocks to be primarily server rendered for the shopper view. Those blocks still need to use a REST API in the editor context but here it's important to consider things like permissions etc for not only editing the block layout and styles but also its actual content.

[nefeline]

Gotcha, makes sense: thanks for clarifying!

[Aljullu]

Just chiming in to mention that in the Command Palette we are also using getEntityRecords( 'postType', 'product', query ). I was trying to refactor it because hitting the WP endpoint instead of the WC one has some drawbacks: WC-specific filters are ignored, the implementation is tied to Products being a Custom Post Type, etc.

However, after playing around with different solutions and reading this combo (thanks @imanish003 for pointing it out to me!), I'm leaning towards leaving it as-is until we have a generic solution that we can use everywhere. In the Command Palette, we only need the Product name and Product ID, so going with an interim solution would be straightforward. But I'm wary of implementing it with the risk of making things more difficult in the future, as it would be yet another instance to update. That's why I'm leaning towards not doing anything with it right now. I don't have a strong position on this, so happy to listen to your opinions if you think otherwise.

I also wanted to bring it here mostly for awareness, as the Command Palette is a usage of getEntityRecords() that was introduced very recently into the code.

[nerrad]

Thanks for chiming in here Albert, it lends further support to implementing a solution that makes use of the Entity Record API in the editor/admin context.