You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm opening this as a question because it feels like a feature request, documentation request, and bug report all rolled into one.
Describe the issue
PDP product data (ServerProductQuery) is pulled during initial build in getStaticProps, and never revalidated. There is a manual client data refetch, but it uses ClientProductQuery, which is not 1:1.
This has led to at least two concrete issues in our team's experience:
[bug] because the data in the statically-built page is stale, any time the updated data conflicts with the old data there can be a problematic flashing of old data before the new data displays. see the price example video below.
[documentation request] because the ~manual revalidation linked above runs the client version of the product query, any API extensions added to the ServerProductQuery are fetched once during build and never re-executed, leading to an undocumented behavior where you need to extend both the server and client product query to refetch your data. see the example video below - the product's inventory has been restocked since the last app build, but because our call to get live productStock is only in the ServerProductQuery, it isn't updated by the client data refetch.
pdp_price_conflict.mp4
Possible Solution
I think the ideal solve would be to support a revalidate value to pass into getStaticProps inside p.tsx. This would be a low-lift way of allowing users to configure an expected "cache time" for product updates, without forcing teams to rebuild their application periodically to pick up catalog changes.
Also, clarification to the existing documentation would be helpful - while the ServerProductQuery and ClientProductQuery docs call out the fallback / getStaticProps pattern, it would be great to highlight the implications of using two different, overlapping queries to fetch the product data, for how developers should build API extensions / think about the PDP render cycle.
The text was updated successfully, but these errors were encountered:
Hey @batzlerg, first of all thank you for this one, improvements proposals are always welcome and help us to evolve even more the product 🤝
Regarding the bug I have a question: do you think that having slightly different queries being fetched (one on server and the other on client-side) are a problem, or is the refetch itself bad?
Even though the on-demand revalidation (ISR) it's still in our sights, we don't support it on our infrastructure yet, but it would be the best possible solution indeed.
I'm opening this as a question because it feels like a feature request, documentation request, and bug report all rolled into one.
Describe the issue
PDP product data (ServerProductQuery) is pulled during initial build in
getStaticProps
, and never revalidated. There is a manual client data refetch, but it uses ClientProductQuery, which is not 1:1.This has led to at least two concrete issues in our team's experience:
productStock
is only in the ServerProductQuery, it isn't updated by the client data refetch.pdp_price_conflict.mp4
Possible Solution
I think the ideal solve would be to support a
revalidate
value to pass intogetStaticProps
insidep.tsx
. This would be a low-lift way of allowing users to configure an expected "cache time" for product updates, without forcing teams to rebuild their application periodically to pick up catalog changes.A more elegant solution is to allow users to revalidate on demand (for example, we could hook up to receive VTEX catalog changes via broadcaster), but exposing that functionality involves additional work.
Also, clarification to the existing documentation would be helpful - while the ServerProductQuery and ClientProductQuery docs call out the fallback /
getStaticProps
pattern, it would be great to highlight the implications of using two different, overlapping queries to fetch the product data, for how developers should build API extensions / think about the PDP render cycle.The text was updated successfully, but these errors were encountered: