Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stale product data on PDP #2399

Open
batzlerg opened this issue Aug 6, 2024 · 1 comment
Open

Stale product data on PDP #2399

batzlerg opened this issue Aug 6, 2024 · 1 comment
Labels
question Further information is requested

Comments

@batzlerg
Copy link
Contributor

batzlerg commented Aug 6, 2024

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.

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.

@batzlerg batzlerg added good first issue question Further information is requested labels Aug 6, 2024
@lucasfp13
Copy link
Contributor

lucasfp13 commented Aug 23, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants