When the @automattic/shopping-cart package was refactored to support adding multiple carts (https://github.com/Automattic/wp-calypso/pull/54667), it meant that components which used the manager (usually via useShoppingCart or withShoppingCart) became responsible for knowing the cart key of the cart they wished to fetch. If the component is not ready to fetch the cart, it should provide the cart key undefined to the cart manager.
Most of the time, this key is the site ID of the selected site, which is stored in Redux state. And so I created getCartKey and its automated forms, useCartKey and withCartKey. These functions take the Redux state data and return the appropriate cart key for the selected site.
However, there are two special cart keys: no-user and no-site. These are used when no user exists or when no site exists, respectively and are used for several different flows. In order to return those values, getCartKey tried to replicate the existing logic for determining if the current context called for a userless or siteless cart, but unfortunately that logic was somewhat unclear. As a result, getCartKey will return no-site if it can't determine the correct cart key to use.
The result is that sometimes an unnecessary call to the shopping-cart endpoint is made with the no-site key when the consumer is not yet ready.
I hadn't considered this a major problem as the consumer component could ignore the result of getCartKey and pass undefined manually to the cart manager (when used with withShoppingCart this requires the use of its mapPropsToCartKeyfunction), but in practice this never happens.
A better solution would be for getCartKey to return undefined when a siteless flow is not explicitly needed. We just need to make sure that no siteless flow is relying on the existing behavior.
When the
@automattic/shopping-cart
package was refactored to support adding multiple carts (https://github.com/Automattic/wp-calypso/pull/54667), it meant that components which used the manager (usually viauseShoppingCart
orwithShoppingCart
) became responsible for knowing the cart key of the cart they wished to fetch. If the component is not ready to fetch the cart, it should provide the cart keyundefined
to the cart manager.Most of the time, this key is the site ID of the selected site, which is stored in Redux state. And so I created
getCartKey
and its automated forms,useCartKey
andwithCartKey
. These functions take the Redux state data and return the appropriate cart key for the selected site.However, there are two special cart keys:
no-user
andno-site
. These are used when no user exists or when no site exists, respectively and are used for several different flows. In order to return those values,getCartKey
tried to replicate the existing logic for determining if the current context called for a userless or siteless cart, but unfortunately that logic was somewhat unclear. As a result,getCartKey
will returnno-site
if it can't determine the correct cart key to use.The result is that sometimes an unnecessary call to the shopping-cart endpoint is made with the
no-site
key when the consumer is not yet ready.I hadn't considered this a major problem as the consumer component could ignore the result of
getCartKey
and passundefined
manually to the cart manager (when used withwithShoppingCart
this requires the use of itsmapPropsToCartKey
function), but in practice this never happens.A better solution would be for
getCartKey
to returnundefined
when a siteless flow is not explicitly needed. We just need to make sure that no siteless flow is relying on the existing behavior.