demo(product-list): implement third-party data enrichment for Coveo products #6162
Conversation
louis-bompart
temporarily deployed
to
PR Artifacts
GitHub Actions
Inactive
louis-bompart
temporarily deployed
to
PR Artifacts
GitHub Actions
Inactive
louis-bompart
temporarily deployed
to
PR Artifacts
GitHub Actions
Inactive
Pull Request ReportPR Title❌ Title should follow the conventional commit spec: Example: Live demo linksBundle Size
|
louis-bompart
temporarily deployed
to
Prerelease (CDN)
GitHub Actions
Inactive
louis-bompart
changed the title
louis-bompart
force-pushed
the
demo/result-enrichment-ssr
branch
from
772604e to
fccb725
Compare
louis-bompart
temporarily deployed
to
PR Artifacts
GitHub Actions
Inactive
louis-bompart
temporarily deployed
to
PR Artifacts
GitHub Actions
Inactive
louis-bompart
temporarily deployed
to
PR Artifacts
GitHub Actions
Inactive
louis-bompart
temporarily deployed
to
Prerelease (CDN)
GitHub Actions
Inactive
louis-bompart
force-pushed
the
demo/result-enrichment-ssr
branch
from
fccb725 to
0a06fe8
Compare
louis-bompart
temporarily deployed
to
PR Artifacts
GitHub Actions
Inactive
louis-bompart
temporarily deployed
to
PR Artifacts
GitHub Actions
Inactive
louis-bompart
temporarily deployed
to
PR Artifacts
GitHub Actions
Inactive
louis-bompart
temporarily deployed
to
Prerelease (CDN)
GitHub Actions
Inactive
There was a problem hiding this comment.
AI alert for this; I used prop drillin' then asked Copilot to refactor this with a context.
If it smells, say so
| * A fake 3rd party API that returns the availability of a product based on its id. | ||
| * | ||
| * The returned value of this fake API are random. | ||
| * The "response time" of the API is however rigged to illustrate various scenarios: |
There was a problem hiding this comment.
Intuitively, I'd say that in a real-life scenario you'd probably be able to fetch this information in a single batch (i.e., get availability status for all products in the result list). Otherwise you'd really be hammering the external service with requests.
With that in mind, we could still simulate latency, but it could just be:
- 1st call -> optimistic
- 2nd call -> normal
- 3rd call -> slow, and reset
There was a problem hiding this comment.
Intuitively, I'd say that in a real-life scenario you'd probably be able to fetch this information in a single batch (i.e., get availability status for all products in the result list). Otherwise you'd really be hammering the external service with requests.
With that in mind, we could still simulate latency, but it could just be:
- 1st call -> optimistic
- 2nd call -> normal
- 3rd call -> slow, and reset
Yeah we could do that. The goal with my current approach is that you can see suspense in action in one page load.
There was a problem hiding this comment.
I understand, but I wonder if there's any use in demonstrating that unless we can think of a more realistic / common use case. It seems to me like an API that would accept only one product at a time would be incredibly inefficient.
| export enum Availability { | ||
| High = 'high', | ||
| Medium = 'medium', | ||
| Low = 'low', | ||
| OutOfStock = 'out-of-stock', | ||
| } |
There was a problem hiding this comment.
Realistically, product availability would more likely be a discrete number of units, no?
There was a problem hiding this comment.
I'd rename the file to "product-availability-api-provider"
2 participants
No description provided.