fix(pricing): accelerate pricing added back#7808
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughThe pricing page now displays Prisma Accelerate as a distinct product offering alongside Postgres. Changes extend the Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (3)
apps/site/src/app/pricing/pricing-data.ts (2)
55-60: Consider makingacceleratePointsrequired onPricingPlan.Line 59 is optional, but all plan entries now provide Accelerate bullets (Lines 121-218). Making it required gives compile-time protection against future plan omissions.
Proposed type tightening
export type PricingPlan = { title: string; subtitle: string; points: PlanPoint[]; - acceleratePoints?: PlanPoint[]; + acceleratePoints: PlanPoint[]; price: CurrencyMap; };🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/site/src/app/pricing/pricing-data.ts` around lines 55 - 60, The type PricingPlan currently marks acceleratePoints as optional but every plan object provides it, so tighten the type by removing the optional modifier from acceleratePoints on the PricingPlan type (i.e., make acceleratePoints required) to get compile-time guarantees; update any code that assumed it might be undefined (references to pricingData, map/filter logic, or destructuring that checks for undefined) to treat acceleratePoints as always present or handle accordingly, and run the TypeScript build to catch places that need minor adjustments.
72-85: Currency formatting logic differs between surfaces; consolidate if values overlap.
formatAmountForAllCurrencies(pricing-data.ts, lines 72–85) does not round and uses config-based decimal thresholds, whileformatCurrency(pricing-calculator.tsx, line 83) explicitly rounds values ≥1 and applies a hardcoded ≥1 threshold for decimal selection. Although these formatters primarily serve different contexts—static plan cards vs. dynamic calculations—the divergent logic could produce inconsistent output if the same USD amount is formatted by both. For robustness, extract a shared currency formatter or document why the dual strategies are necessary.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/site/src/app/pricing/pricing-data.ts` around lines 72 - 85, formatAmountForAllCurrencies and formatCurrency use different rounding/decimal-selection rules causing inconsistent displays; create a single shared formatter (e.g., formatCurrencyValue) that takes (amountUsd: number, target: Symbol, digits: number) and centralizes logic: convert via convertFromUsd, consult currencyConfig[typedCode] for decimals and microDecimals, apply consistent rule (e.g., round values >= 1 to config.decimals and use microDecimals when digits > config.decimals or when <1 as needed), then format with toLocaleString using effectiveFractionDigits; replace calls in formatAmountForAllCurrencies and formatCurrency to delegate to this new function (or if keeping two, clearly document why they must differ and ensure both call a common helper for conversion/formatting decisions).apps/site/src/app/pricing/pricing-hero-plans.tsx (1)
50-52: Clarify when static HTML strings become a refactoring priority.Line 50 injects plan content via
dangerouslySetInnerHTML, which is safe today because all bullet points are hardcoded static literals inpricing-data.ts. This includes bothpointsandacceleratePointsarrays—there's no external data source (CMS, API, localization, etc.) feeding these strings.However, the XSS risk is real if this architecture ever changes. If these strings move to a database, user-managed content, or external source in the future, the current approach becomes an injection sink. Consider one of:
- Add a comment explaining why static literals make this safe (and when it should be revisited)
- Plan a refactor to migrate to structured rich-text tokens if dynamic content is planned
For now, the implementation is secure. Flag this for review when the data source model changes.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/site/src/app/pricing/pricing-hero-plans.tsx` around lines 50 - 52, The code is injecting HTML via dangerouslySetInnerHTML using renderPlanPoint(item, currency), which is currently safe because all strings come from static literals in pricing-data.ts (points and acceleratePoints); add an inline code comment next to the dangerouslySetInnerHTML usage referencing renderPlanPoint and pricing-data.ts that states this safety assumption (static literals only), warns that this is an XSS sink if points or acceleratePoints move to external/DB/CMS/localized sources, and instructs to refactor to structured rich-text tokens or a safe renderer when content becomes dynamic; include the function name renderPlanPoint and the arrays points/acceleratePoints in the comment for easy future discovery.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@apps/site/src/app/pricing/pricing-data.ts`:
- Around line 55-60: The type PricingPlan currently marks acceleratePoints as
optional but every plan object provides it, so tighten the type by removing the
optional modifier from acceleratePoints on the PricingPlan type (i.e., make
acceleratePoints required) to get compile-time guarantees; update any code that
assumed it might be undefined (references to pricingData, map/filter logic, or
destructuring that checks for undefined) to treat acceleratePoints as always
present or handle accordingly, and run the TypeScript build to catch places that
need minor adjustments.
- Around line 72-85: formatAmountForAllCurrencies and formatCurrency use
different rounding/decimal-selection rules causing inconsistent displays; create
a single shared formatter (e.g., formatCurrencyValue) that takes (amountUsd:
number, target: Symbol, digits: number) and centralizes logic: convert via
convertFromUsd, consult currencyConfig[typedCode] for decimals and
microDecimals, apply consistent rule (e.g., round values >= 1 to config.decimals
and use microDecimals when digits > config.decimals or when <1 as needed), then
format with toLocaleString using effectiveFractionDigits; replace calls in
formatAmountForAllCurrencies and formatCurrency to delegate to this new function
(or if keeping two, clearly document why they must differ and ensure both call a
common helper for conversion/formatting decisions).
In `@apps/site/src/app/pricing/pricing-hero-plans.tsx`:
- Around line 50-52: The code is injecting HTML via dangerouslySetInnerHTML
using renderPlanPoint(item, currency), which is currently safe because all
strings come from static literals in pricing-data.ts (points and
acceleratePoints); add an inline code comment next to the
dangerouslySetInnerHTML usage referencing renderPlanPoint and pricing-data.ts
that states this safety assumption (static literals only), warns that this is an
XSS sink if points or acceleratePoints move to external/DB/CMS/localized
sources, and instructs to refactor to structured rich-text tokens or a safe
renderer when content becomes dynamic; include the function name renderPlanPoint
and the arrays points/acceleratePoints in the comment for easy future discovery.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: d9532109-ed78-4645-9d27-a9c6e1443984
📒 Files selected for processing (2)
apps/site/src/app/pricing/pricing-data.tsapps/site/src/app/pricing/pricing-hero-plans.tsx
aidankmcalister
requested review from
AmanVarshney01,
ArthurGamby,
carlagn and
mhartington
2 participants
Summary by CodeRabbit
Release Notes