Payments app design fixes#1375
Open
Developing-Gamer wants to merge 24 commits intodevfrom
Open
Conversation
Introduce a canonical dialog surface with structured header/body/footer slots and styling controls so feature pages can reuse a consistent modal foundation. Made-with: Cursor
Expose the new dialog component and related helper types from the package root so dashboard pages can import the shared modal API consistently. Made-with: Cursor
Add guidance for when and how to use DesignDialog so modal redesign work follows a single documented pattern across dashboard routes. Made-with: Cursor
Replace the hand-wired trigger history dialog chrome with the shared DesignDialog wrapper while preserving the existing summary header and trigger list behavior. Made-with: Cursor
Show confirmation, rich-header, tester, and parity examples so agents and developers can copy the shared modal patterns directly. Made-with: Cursor
Introduce a dedicated dialog playground entry with shape presets and generated snippets to make modal experimentation and reuse easier. Made-with: Cursor
Ensures popover content receives pointer events consistently in stack-ui and the dashboard shadcn wrapper. Made-with: Cursor
Split hover, focus, and data-[highlighted] so keyboard navigation matches pointer hover for menu and select items. Made-with: Cursor
Payments product flows use the updated repeating list behavior and styling. Made-with: Cursor
Aligns the payments item dialog with the new form and popover patterns. Made-with: Cursor
Applies the updated UI patterns to the product line creation flow. Made-with: Cursor
Refactors included item editing to match the new dialog and input UX. Made-with: Cursor
Aligns price editing with the shared dialog and form components. Made-with: Cursor
Wires the new product flow to the refactored dialogs and pricing UI. Made-with: Cursor
Replace generic Card layout with DesignCard, shared StatusRow, and DesignBadge/DesignButton for consistent status styling across not connected, incomplete setup, and connected states. Made-with: Cursor
Use DesignCard with gradient by state and DesignBadge for the test-mode feature list when active, matching the updated payments settings visuals. Made-with: Cursor
Swap Card for DesignCard, move save/cancel into card actions, refine rows and accordions, and add a Modified badge for pending toggles on controllable and platform-managed sections. Made-with: Cursor
Replace SettingSwitch with a DesignCard, optimistic Switch updates, and tighter section spacing to match the rest of the payments settings page. Made-with: Cursor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
📝 WalkthroughWalkthroughIntroduces a new Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 3❌ Failed checks (2 warnings, 1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
Greptile SummaryThis PR applies a visual design refresh to the payments section of the dashboard, migrating dialogs and form controls from the base shadcn primitives (
Confidence Score: 4/5Mostly safe to merge after fixing the null-guard crash in the new product form. One P1 issue (unsafe property access that causes a TypeError during a normal user flow) should be resolved before merging. The remaining P2 findings are async handler hygiene that won't block users but violate the team convention. apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/products/new/page-client.tsx — unsafe productLines lookup at line 385. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[User opens Create Product page] --> B{Has customerType or productLineId in URL?}
B -- Yes --> D[Skip selection, init form]
B -- No --> C[CustomerTypeSelection screen]
C -->|select type| D
D --> E[Render product form]
E --> F{productLineId state non-empty?}
F -- Yes --> G[Access productLines productLineId .customerType - No null guard!]
F -- No --> H[effectiveProductLineId = empty]
G -->|ID exists in config| I[effectiveProductLineId = productLineId]
G -->|ID NOT in config e.g. mid-flight after handleCreateProductLine| J[TypeError crash]
I --> K[Form renders normally]
H --> K
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| title="Not connected" | ||
| description="Set up Stripe to start accepting payments." | ||
| action={ | ||
| <DesignButton onClick={setupPayments} size="sm" className="gap-1.5"> |
Contributor
There was a problem hiding this comment.
runAsynchronouslyWithAlert
setupPayments is an async function used directly as an onClick prop. Per the team convention, async button handlers must be wrapped with runAsynchronouslyWithAlert so that errors are surfaced to the user rather than silently swallowed as unhandled promise rejections.
Rule Used: Use runAsynchronouslyWithAlert from `@stackframe... (source)
Learned From
stack-auth/stack-auth#943
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/settings/stripe-connection-check.tsx
Line: 91
Comment:
**Async handler not wrapped with `runAsynchronouslyWithAlert`**
`setupPayments` is an async function used directly as an `onClick` prop. Per the team convention, async button handlers must be wrapped with `runAsynchronouslyWithAlert` so that errors are surfaced to the user rather than silently swallowed as unhandled promise rejections.
**Rule Used:** Use `runAsynchronouslyWithAlert` from `@stackframe... ([source](https://app.greptile.com/review/custom-context?memory=5e671275-7493-402a-93a8-969537ec4d63))
**Learned From**
[stack-auth/stack-auth#943](https://github.com/stack-auth/stack-auth/pull/943)
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| <DesignDialogClose asChild> | ||
| <DesignButton variant="secondary" size="sm" type="button">Cancel</DesignButton> | ||
| </DesignDialogClose> | ||
| <DesignButton size="sm" type="button" onClick={validateAndSave}> |
Contributor
There was a problem hiding this comment.
runAsynchronouslyWithAlert
validateAndSave is an async function used directly as onClick. If onSave throws (e.g. the usage in new/page-client.tsx throws "Operation cancelled" to keep the dialog open), the rejection propagates silently. Per team rule, async button handlers should be wrapped with runAsynchronouslyWithAlert.
Rule Used: Use runAsynchronouslyWithAlert from `@stackframe... (source)
Learned From
stack-auth/stack-auth#943
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/dashboard/src/components/payments/item-dialog.tsx
Line: 113
Comment:
**Async handler not wrapped with `runAsynchronouslyWithAlert`**
`validateAndSave` is an async function used directly as `onClick`. If `onSave` throws (e.g. the usage in `new/page-client.tsx` throws `"Operation cancelled"` to keep the dialog open), the rejection propagates silently. Per team rule, async button handlers should be wrapped with `runAsynchronouslyWithAlert`.
**Rule Used:** Use `runAsynchronouslyWithAlert` from `@stackframe... ([source](https://app.greptile.com/review/custom-context?memory=5e671275-7493-402a-93a8-969537ec4d63))
**Learned From**
[stack-auth/stack-auth#943](https://github.com/stack-auth/stack-auth/pull/943)
How can I resolve this? If you propose a fix, please make it concise.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR modernizes several dashboard surfaces to align with the shared “design-components” language (notably introducing a canonical DesignDialog) and applies a set of UI/interaction fixes across Payments and other dashboard areas.
Changes:
- Add
DesignDialogto@stackframe/dashboard-ui-components, re-export it, and document it as the canonical dashboard modal surface. - Migrate multiple dashboard screens (Payments settings/products, Sign-up rules, Auth methods, playground/design-language demos) to use design-components styling and new dialog/menu patterns.
- Apply interaction/visual fixes to Radix-based primitives (popover pointer events; select/dropdown highlighted styles) and extend
ActionDialogto support richer behavior/class overrides.
Reviewed changes
Copilot reviewed 26 out of 26 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| skills-lock.json | Adds skills lock metadata for agent tooling. |
| .agents/skills/roids/SKILL.md | Introduces “roids” skill documentation for variant comparison flows. |
| packages/stack-ui/src/components/ui/popover.tsx | Adds pointer-events-auto to popover content. |
| packages/dashboard-ui-components/src/components/dialog.tsx | Adds new DesignDialog wrapper component with consistent shell/regions. |
| packages/dashboard-ui-components/src/index.ts | Re-exports DesignDialog and related types/components. |
| apps/dashboard/DESIGN-GUIDE.md | Documents DesignDialog as canonical modal surface + usage guidelines. |
| apps/dashboard/src/components/ui/select.tsx | Improves hover/focus/highlight styling for select items. |
| apps/dashboard/src/components/ui/dropdown-menu.tsx | Improves hover/focus/highlight styling for menu items. |
| apps/dashboard/src/components/ui/popover.tsx | Adds pointer-events-auto to dashboard popover content. |
| apps/dashboard/src/components/ui/action-dialog.tsx | Adds outside-interaction behavior toggle + content class override support. |
| apps/dashboard/src/components/repeating-input.tsx | Restyles repeating input and swaps custom interval controls to design-components. |
| apps/dashboard/src/components/payments/item-dialog.tsx | Migrates item create/edit dialog to DesignDialog + design inputs/buttons. |
| apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/sign-up-rules/page-client.tsx | Significant UI refactor: new dialog shell, richer rule editor/rows, tester layout. |
| apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/settings/test-mode-toggle.tsx | Restyles Test Mode card using design-components. |
| apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/settings/stripe-connection-check.tsx | Restyles Stripe connection status card using design-components. |
| apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/settings/payment-methods.tsx | Restyles payment methods configuration + adds clearer pending-change actions. |
| apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/settings/page-client.tsx | Restyles “block new purchases” control into a design-components card with optimistic UX. |
| apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/products/pricing-section.tsx | Migrates buttons to DesignButton and standardizes button semantics. |
| apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/products/price-edit-dialog.tsx | Migrates price edit flow to DesignDialog + design inputs/dropdowns/popovers. |
| apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/products/new/page-client.tsx | Restyles product creation flow with design inputs/buttons and updated menus. |
| apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/products/included-item-dialog.tsx | Migrates included-item dialog to DesignDialog + design inputs/dropdowns. |
| apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/products/create-product-line-dialog.tsx | Migrates product-line dialog to DesignDialog + design inputs/buttons. |
| apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/design-language/page-client.tsx | Adds DesignDialog demos and prop documentation. |
| apps/dashboard/src/app/(main)/(protected)/(outside-dashboard)/playground/page-client.tsx | Adds DesignDialog playground surface and prop controls/snippet generation. |
| apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/auth-methods/providers.tsx | Redesigns provider dialogs/cards using design-components and new chrome options. |
| apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/auth-methods/page-client.tsx | Large redesign of auth methods/settings UI with design-components + new helper hooks. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
1
to
+16
| "use client"; | ||
|
|
||
| import { EmailVerificationSetting } from "@/components/email-verification-setting"; | ||
| import { InlineSaveDiscard } from "@/components/inline-save-discard"; | ||
| import { SettingCard, SettingSelect, SettingSwitch } from "@/components/settings"; | ||
| import { ActionDialog, Badge, BrandIcons, BrowserFrame, Button, DropdownMenu, DropdownMenuContent, DropdownMenuItem, DropdownMenuTrigger, Input, SelectItem, SimpleTooltip, Typography } from "@/components/ui"; | ||
| import { ActionDialog, BrandIcons, BrowserFrame, Label, SimpleTooltip, Switch, Typography } from "@/components/ui"; | ||
| import { useUpdateConfig } from "@/lib/config-update"; | ||
| import { AsteriskIcon, DotsThreeIcon, KeyIcon, LinkIcon, PlusCircleIcon } from "@phosphor-icons/react"; | ||
| import { | ||
| DesignAlert, | ||
| DesignBadge, | ||
| DesignButton, | ||
| DesignCard, | ||
| DesignCardTint, | ||
| DesignInput, | ||
| } from "@stackframe/dashboard-ui-components"; | ||
| import { DesignMenu, type DesignMenuActionItem } from "@/components/design-components/menu"; | ||
| import { DesignSelectorDropdown } from "@/components/design-components/select"; | ||
| import { |
Comment on lines
+22
to
+37
| const [optimisticBlocked, setOptimisticBlocked] = useState<boolean | null>(null); | ||
| const blocked = optimisticBlocked ?? paymentsConfig.blockNewPurchases; | ||
|
|
||
| const handleBlockChange = (checked: boolean) => { | ||
| setOptimisticBlocked(checked); | ||
| runAsynchronouslyWithAlert((async () => { | ||
| try { | ||
| await updateConfig({ | ||
| adminApp, | ||
| configUpdate: { "payments.blockNewPurchases": checked }, | ||
| pushable: true, | ||
| }); | ||
| } finally { | ||
| setOptimisticBlocked(null); | ||
| } | ||
| })()); |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 12
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (5)
apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/settings/test-mode-toggle.tsx (1)
16-22:⚠️ Potential issue | 🟠 MajorDon't void the
handleTogglepromise — errors will be silently swallowed.
Switch'sonCheckedChangeexpects a synchronous(checked: boolean) => void, so passing the asynchandleToggledirectly at Line 61 fire-and-forgets the promise: ifupdateConfigrejects (network/Stripe/API error), nothing catches it, there's no toast/alert, and no loading state is shown while the write is in flight. The user just sees the switch snap but the server state may not have updated.Per coding guidelines: "NEVER try-catch-all, NEVER void a promise, and NEVER .catch(console.error) (or similar). Use
runAsynchronouslyorrunAsynchronouslyWithAlertinstead..." and "always carefully deal with loading and error states ... make sure errors are NEVER just silently swallowed."🛡️ Suggested fix
+import { runAsynchronouslyWithAlert } from "@stackframe/stack-shared/dist/utils/promises"; @@ - const handleToggle = async (enabled: boolean) => { - await updateConfig({ - adminApp, - configUpdate: { "payments.testMode": enabled }, - pushable: false, - }); - }; + const handleToggle = (enabled: boolean) => { + runAsynchronouslyWithAlert(updateConfig({ + adminApp, + configUpdate: { "payments.testMode": enabled }, + pushable: false, + })); + };Consider also reflecting optimistic/in-flight state on the
Switchto avoid flicker when the server rejects the change.As per coding guidelines: "NEVER try-catch-all, NEVER void a promise, and NEVER .catch(console.error) (or similar). Use
runAsynchronouslyorrunAsynchronouslyWithAlertinstead..."Also applies to: 61-61
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/settings/test-mode-toggle.tsx around lines 16 - 22, The async handleToggle function is being passed directly to the Switch onCheckedChange which fire-forgets the promise and can silently swallow errors; replace the direct use by invoking runAsynchronously or runAsynchronouslyWithAlert when the Switch changes so the returned promise is handled, show an in-flight/loading state (e.g., a local isSaving or optimistic state) while updateConfig (the function called inside handleToggle) runs, and on failure revert the optimistic state and surface an alert/error to the user; update code references include handleToggle, updateConfig, and the Switch onCheckedChange handler to ensure you do not void the promise and you handle loading and error states correctly.apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/products/create-product-line-dialog.tsx (1)
55-62:⚠️ Potential issue | 🟠 MajorWait for create success before clearing and closing.
onCreatecan be async, but this fires it in the background and closes the dialog immediately. A failure leaves the user with a cleared form and no blocking alert.Proposed fix
-import { runAsynchronously } from "@stackframe/stack-shared/dist/utils/promises"; +import { runAsynchronouslyWithAlert } from "@stackframe/stack-shared/dist/utils/promises";- runAsynchronously(onCreate({ id: productLineId.trim(), displayName: displayName.trim() })); - - // Reset form - setDisplayName(""); - setProductLineId(""); - setHasManuallyEditedId(false); - setErrors({}); - onOpenChange(false); + runAsynchronouslyWithAlert(async () => { + await onCreate({ id: productLineId.trim(), displayName: displayName.trim() }); + handleClose(); + });As per coding guidelines, "When building frontend code, always carefully deal with loading and error states" and errors should not be silently swallowed.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/products/create-product-line-dialog.tsx around lines 55 - 62, The current code fires runAsynchronously(onCreate(...)) and immediately clears the form and closes the dialog, which loses state on failure; change the flow so you await the result of onCreate (or handle its returned promise) instead of backgrounding it, set a loading flag while awaiting, and only call setDisplayName(""), setProductLineId(""), setHasManuallyEditedId(false), setErrors({}), and onOpenChange(false) after onCreate resolves successfully; if onCreate rejects, catch the error, update the component error state (via setErrors or a new error setter) and clear the loading flag without resetting the form so the user can correct and retry (reference functions: onCreate, runAsynchronously, setDisplayName, setProductLineId, setHasManuallyEditedId, setErrors, onOpenChange).apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/sign-up-rules/page-client.tsx (1)
1509-1538:⚠️ Potential issue | 🟡 MinorClear analytics loading on failures too.
If the stats request fails or returns non-OK,
setIsLoading(false)is never reached, so the UI can stay in a perpetual loading state after the alert.Proposed fix
const fetchAnalytics = async () => { - const response = await (stackAdminApp as any)[stackAppInternalsSymbol].sendRequest( - '/internal/sign-up-rules-stats', - { method: 'GET' }, - 'admin' - ); - if (cancelled) return; - - if (!response.ok) { - throw new StackAssertionError(`Failed to fetch sign-up rules stats: ${response.status} ${response.statusText}`); - } - - const data = await response.json(); - setTimespanHours(data.analytics_hours); - - const analyticsMap = new Map<string, RuleAnalytics>(); - for (const trigger of data.rule_triggers ?? []) { - analyticsMap.set(trigger.rule_id, { - ruleId: trigger.rule_id, - countInTimespan: trigger.total_count, - allTimeCount: trigger.all_time_count, - hourlyCounts: trigger.hourly_counts ?? [], - }); - } - - setAnalytics(analyticsMap); - setIsLoading(false); + try { + const response = await (stackAdminApp as any)[stackAppInternalsSymbol].sendRequest( + '/internal/sign-up-rules-stats', + { method: 'GET' }, + 'admin' + ); + if (cancelled) return; + + if (!response.ok) { + throw new StackAssertionError(`Failed to fetch sign-up rules stats: ${response.status} ${response.statusText}`); + } + + const data = await response.json(); + setTimespanHours(data.analytics_hours); + + const analyticsMap = new Map<string, RuleAnalytics>(); + for (const trigger of data.rule_triggers ?? []) { + analyticsMap.set(trigger.rule_id, { + ruleId: trigger.rule_id, + countInTimespan: trigger.total_count, + allTimeCount: trigger.all_time_count, + hourlyCounts: trigger.hourly_counts ?? [], + }); + } + + setAnalytics(analyticsMap); + } finally { + if (!cancelled) setIsLoading(false); + } };As per coding guidelines, "When building frontend code, always carefully deal with loading and error states."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/sign-up-rules/page-client.tsx around lines 1509 - 1538, The fetchAnalytics function can throw or return early without clearing the loading flag, leaving the UI stuck; wrap the body of fetchAnalytics in try/catch/finally (or ensure runAsynchronouslyWithAlert handles finally) so that setIsLoading(false) is always called regardless of errors or non-OK responses; specifically update the fetchAnalytics implementation (referencing fetchAnalytics, setIsLoading, setAnalytics and the StackAssertionError non-OK branch) to call setIsLoading(false) in a finally block and preserve the cancelled check and error logging/throwing in the catch.apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/settings/payment-methods.tsx (2)
203-218:⚠️ Potential issue | 🟠 MajorDisable method toggles while saving.
The Save/Cancel actions are locked, but the switches remain active. A toggle made during
handleSavecan be overwritten byloadConfig()and then cleared bysetPendingChanges({}), silently dropping the user’s latest change.🐛 Proposed fix
<Switch checked={isEnabled} + disabled={saving} onCheckedChange={() => handleToggle(method.id, isEnabled)} />🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/settings/payment-methods.tsx around lines 203 - 218, The Switch controls remain active while a save is in progress, allowing toggles to be lost; update the Switch rendering (the Switch using checked={isEnabled} and onCheckedChange={() => handleToggle(method.id, isEnabled)}) to be disabled when saving (use the saving state to either set a disabled prop on the Switch or short-circuit onCheckedChange) so user toggles are blocked during handleSave; ensure any UI that relies on hasPendingChanges/loadConfig/setPendingChanges remains consistent by preventing state changes from Switch while saving.
66-73:⚠️ Potential issue | 🟡 MinorClear pending state when a toggle returns to its saved value.
With the new “Modified” badge/actions, toggling a method off and then back on still leaves it in
pendingChanges, so the UI keeps showing a modification and can submit a no-op update.🐛 Proposed fix
const handleToggle = (methodId: string, currentEnabled: boolean) => { - setPendingChanges(prev => ({ - ...prev, - [methodId]: !currentEnabled, - })); + const nextEnabled = !currentEnabled; + const savedEnabled = config?.methods.find(m => m.id === methodId)?.enabled; + + setPendingChanges(prev => { + const next = { ...prev }; + if (savedEnabled === nextEnabled) { + delete next[methodId]; + } else { + next[methodId] = nextEnabled; + } + return next; + }); };Also applies to: 175-201
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/settings/payment-methods.tsx around lines 66 - 73, handleToggle currently always writes a toggled value into pendingChanges, so reverting a toggle back to the saved value still leaves an entry and shows a spurious "Modified" state; update handleToggle to compute the newEnabled value and compare it to the persisted/saved value for that method (use whatever source holds saved state for the method, e.g., the methods list or a savedEnabled map), and then call setPendingChanges to either remove the methodId key when newEnabled === savedEnabled or set it when different. Ensure you update the same logic used elsewhere (the other toggle handler that manipulates pendingChanges) so hasPendingChanges reflects only actual modifications.
🧹 Nitpick comments (9)
apps/dashboard/src/components/repeating-input.tsx (2)
256-259: Pluralization only handles Englishs.
label: \${u}${... !== 1 ? 's' : ''}`will produce labels like "days"/"months", which is fine today but (a) will not localize and (b) won't match the pluralization used bygetIntervalLabelifuseDurationLabelsis true (which emits"1 day"/"2 days"`). If the custom popover is intended to mirror duration labels, reuse the same label helper to avoid drift.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/src/components/repeating-input.tsx` around lines 256 - 259, The label construction for options uses a naive English plural ('s') and can diverge from localized or existing duration labels; update the options mapping in repeating-input.tsx (where normalizedUnits, effectiveSelection, intervalCount are used) to reuse the same label helper used by getIntervalLabel / useDurationLabels so labels mirror the component's duration formatting and localization (pass the unit and count into that helper instead of manually appending 's', ensuring the custom popover and duration labels stay consistent).
163-176: Native<input>loses the shared DesignInput styling/behavior.The value input was migrated to a raw
<input>while the custom-count input right below (Line 237) still usesDesignInput. This splits input styling between two sources of truth — future tweaks toDesignInput(validation states, font sizing, focus ring, forwarded refs) won't propagate here. If the goal was to visually fuse the input into the composite trigger/popover control, consider avariant="seamless"/unstyledprop onDesignInputrather than dropping it entirely, to keep one input implementation.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/src/components/repeating-input.tsx` around lines 163 - 176, The raw <input> used in the RepeatingInput component breaks shared styling/behavior from DesignInput; replace the native element with the DesignInput component (e.g., use <DesignInput ... />) and pass the same props (type/inputType, value, onChange -> onValueChange, placeholder, disabled || readOnly, and merge inputClassName) while adding a variant (e.g., variant="seamless" or unstyled) so it visually matches the composite trigger; also ensure the forwarded ref and any existing focus/validation behavior from DesignInput are preserved in RepeatingInput so future styling/behavior changes flow through a single input implementation.packages/dashboard-ui-components/src/components/dialog.tsx (1)
105-105: Redundant fallback; type remainsstring | undefined.
dialogSurfaceClasses.get(variant) ?? dialogSurfaceClasses.get("glassmorphic")still has typestring | undefinedper TS'sMap.getsignature, so the fallback buys nothing type-wise and also doesn't throw on an unknown variant. Per the repo guideline "Use?? throwErr(...)" for states that should never happen, prefer:- const resolvedSurfaceClass = dialogSurfaceClasses.get(variant) ?? dialogSurfaceClasses.get("glassmorphic"); + const resolvedSurfaceClass = dialogSurfaceClasses.get(variant) + ?? throwErr(`Unknown DesignDialog variant: ${variant}`);As per coding guidelines: "Use
?? throwErr(...)instead of?? 0or?? """ and "If there is a state that should never happen, either update the types or throw an error."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/dashboard-ui-components/src/components/dialog.tsx` at line 105, The current expression using dialogSurfaceClasses.get(variant) ?? dialogSurfaceClasses.get("glassmorphic") is redundant because Map.get returns string | undefined, so the fallback doesn't change the type; replace the fallback with a thrown error to enforce the invariant: if dialogSurfaceClasses.get(variant) is undefined, call the project's throwErr (or a small helper that throws) with a clear message so resolvedSurfaceClass is guaranteed to be a string; update the code referencing resolvedSurfaceClass accordingly and ensure throwErr is imported/available.apps/dashboard/src/components/ui/action-dialog.tsx (1)
86-89: Prefercn()for className composition.The filter/join pattern works, but the rest of the codebase uses
cn(...)from@/lib/utilswhich also handles tailwind-merge conflicts cleanly.♻️ Proposed refactor
- className={[ - props.preventClose ? "[&>button]:hidden" : "", - props.contentClassName ?? "", - ].filter(Boolean).join(" ")} + className={cn( + props.preventClose && "[&>button]:hidden", + props.contentClassName, + )}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/src/components/ui/action-dialog.tsx` around lines 86 - 89, Replace the manual array/filter/join class composition with the project's cn utility: change the className assignment to use cn(...) passing the conditional class and props.contentClassName (e.g., cn(props.preventClose && "[&>button]:hidden", props.contentClassName)); also ensure cn is imported from '@/lib/utils' at the top of the module if it's not already imported. This affects the className expression where props.preventClose and props.contentClassName are used.apps/dashboard/src/components/payments/item-dialog.tsx (1)
193-196: Validate the selected customer type instead of casting it.
value as typeof customerTypebypasses the type system and would silently accept an invalid dropdown value if the option list changes.🛡️ Proposed fix
+ const isCustomerType = (value: string): value is typeof customerType => + value === "user" || value === "team" || value === "custom"; + <DesignSelectorDropdown value={customerType} - onValueChange={(value) => setCustomerType(value as typeof customerType)} + onValueChange={(value) => { + if (!isCustomerType(value)) { + throw new Error(`Unknown customer type "${value}"`); + } + setCustomerType(value); + }} options={customerTypeDropdownOptions}As per coding guidelines, "Do NOT use
as/any/type casts or anything else like that to bypass the type system."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/src/components/payments/item-dialog.tsx` around lines 193 - 196, The onValueChange handler currently force-casts the incoming value (value as typeof customerType) which bypasses type-safety; instead validate the selected value against the allowed options (customerTypeDropdownOptions) before calling setCustomerType: implement a small type-guard or inclusion check that confirms the value exists in customerTypeDropdownOptions (or derive the allowed union type from that options array) and only then call setCustomerType(value), otherwise ignore or handle invalid selection; update the DesignSelectorDropdown onValueChange to use this validation and remove the cast.apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/auth-methods/page-client.tsx (2)
412-417: Document or avoid the dynamic admin API cast.This mirrors the existing onboarding call pattern, but the new
(stackAdminApp as any)needs the same local justification or a small typed wrapper so future readers know this is intentional.📝 Proposed fix
if (next && !projectConfig.onboarding.requireEmailVerification) { + // any cast needed: previewAffectedUsersByOnboardingChange is a dynamically-typed admin API method const preview = await (stackAdminApp as any).previewAffectedUsersByOnboardingChange( { requireEmailVerification: true }, 10, );As per coding guidelines, "Try to avoid the
anytype. Whenever you need to useany, leave a comment explaining why you're using it."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/auth-methods/page-client.tsx around lines 412 - 417, The dynamic cast to (stackAdminApp as any) inside handleChange when calling previewAffectedUsersByOnboardingChange should be avoided or justified: either create a narrow typed wrapper/interface for the admin API (e.g., StackAdminApp with previewAffectedUsersByOnboardingChange signature) and cast stackAdminApp to that type before calling the method, or retain the cast but add an explanatory comment above it describing why a precise type cannot be provided (e.g., dynamic runtime admin client, non-exported types) and what shape is expected; update references to previewAffectedUsersByOnboardingChange and handleChange accordingly so the call is typed instead of using plain any.
601-606: Remove the avoidableanyand merge-strategy cast.
Record<string, any>andvalue as OAuthAccountMergeStrategyare both avoidable here; validate the dropdown value and narrow the config update type.🛡️ Proposed fix
const handleSignUpConfirmed = async (newAllowSignUp: boolean) => { - const configUpdate: Record<string, any> = { 'auth.allowSignUp': newAllowSignUp }; + const configUpdate: Record<string, boolean | OAuthAccountMergeStrategy> = { 'auth.allowSignUp': newAllowSignUp }; if (localMergeStrategy !== undefined) { configUpdate['auth.oauth.accountMergeStrategy'] = localMergeStrategy; } await updateConfig({ adminApp: stackAdminApp, configUpdate, pushable: true }); @@ const onMergeStrategyChange = (value: string) => { - const next = value as OAuthAccountMergeStrategy; + if (value !== "link_method" && value !== "raise_error" && value !== "allow_duplicates") { + throw new Error(`Unknown OAuth account merge strategy "${value}"`); + } + const next = value; setLocalMergeStrategy(next === config.auth.oauth.accountMergeStrategy ? undefined : next); };As per coding guidelines, "Do NOT use
as/any/type casts or anything else like that to bypass the type system."Also applies to: 652-655
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/auth-methods/page-client.tsx around lines 601 - 606, Replace the loose-typed configUpdate and the explicit cast by giving configUpdate a concrete typed shape and validating localMergeStrategy before assigning: in handleSignUpConfirmed, declare configUpdate as the exact config type (e.g., { 'auth.allowSignUp': boolean; 'auth.oauth.accountMergeStrategy'?: OAuthAccountMergeStrategy }) and only set configUpdate['auth.oauth.accountMergeStrategy'] when localMergeStrategy is one of the valid OAuthAccountMergeStrategy enum/string values (perform a runtime check like if (localMergeStrategy === '...') or a type-guard), then call updateConfig with that typed object; apply the same change to the other similar block that sets auth.oauth.accountMergeStrategy so you never use Record<string, any> or an as-cast.apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/auth-methods/providers.tsx (1)
246-250: Encode the provider slug before building the docs URL.This keeps URL construction consistent with the repo convention and avoids raw path interpolation.
Proposed fix
function DocsTextLink({ providerId }: { providerId: string }) { + const docsProviderId = encodeURIComponent(providerId === "x" ? "x-twitter" : providerId); + return ( <Link - href={`https://docs.stack-auth.com/docs/concepts/auth-providers/${providerId === "x" ? "x-twitter" : providerId}`} + href={`https://docs.stack-auth.com/docs/concepts/auth-providers/${docsProviderId}`} target="_blank" className="inline-flex items-center gap-1 text-xs font-medium text-foreground/70 hover:text-foreground transition-colors" >As per coding guidelines, "Use urlString`` or encodeURIComponent() instead of normal string interpolation for URLs, for consistency even if it's not strictly necessary."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/auth-methods/providers.tsx around lines 246 - 250, In DocsTextLink, the providerId is interpolated directly into the docs URL; update the URL construction in the DocsTextLink component so the provider slug is encoded (use urlString`` or encodeURIComponent on the computed slug) before building the href (handle the special-case mapping providerId === "x" -> "x-twitter" first, then encode it), and pass the encoded slug into the Link href to ensure consistent, safe URLs.apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/products/new/page-client.tsx (1)
1047-1053: Validate the dropdown value instead of casting it.Line 1049 bypasses the unit type with
as; guard the value before updating state so an invalid selector value fails explicitly.♻️ Proposed fix
+const isFreeTrialUnit = (value: string): value is Product['freeTrial'] extends [number, infer Unit] ? Unit : never => + FREE_TRIAL_UNIT_OPTIONS.some((option) => option.value === value); + <DesignSelectorDropdown value={freeTrial[1]} - onValueChange={(value) => setFreeTrial([freeTrial[0], value as 'day' | 'week' | 'month' | 'year'])} + onValueChange={(value) => { + if (!isFreeTrialUnit(value)) { + throw new Error(`Invalid free trial unit selected: ${value}`); + } + setFreeTrial([freeTrial[0], value]); + }} options={freeTrialUnitSelectOptions}As per coding guidelines, “Do NOT use
as/any/type casts or anything else like that to bypass the type system.”🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/products/new/page-client.tsx around lines 1047 - 1053, The dropdown currently force-casts the selected value in the DesignSelectorDropdown onValueChange handler; replace the cast by validating the incoming value against the allowed unit set before calling setFreeTrial. In the onValueChange for DesignSelectorDropdown (the handler that calls setFreeTrial([freeTrial[0], value as 'day' | 'week' | 'month' | 'year'])), check that value is one of 'day','week','month','year' (or derive valid values from freeTrialUnitSelectOptions) and only call setFreeTrial with the validated unit; otherwise handle the invalid case explicitly (e.g., no-op, throw, or log) so the type system is not bypassed. Ensure you reference DesignSelectorDropdown, setFreeTrial, freeTrial, and freeTrialUnitSelectOptions when making the change.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.agents/skills/roids/SKILL.md:
- Around line 1-20: The added SKILL.md (name: roids) under .agents/skills/roids
appears unrelated to the payments UI changes in this PR; either confirm it
belongs here or remove it from this branch and create a separate PR. Locate the
file referenced by the unique header "name: roids" and the Source entry
"`https://tryroids.com/SKILL.txt`" and either (A) add a brief PR note confirming
this asset is intentionally bundled with the payment changes, or (B) revert/move
the file out of this PR into a dedicated branch/PR so the current review remains
scoped to the dashboard payments UI work.
In `@apps/dashboard/DESIGN-GUIDE.md`:
- Line 67: Update the stale section reference in the guidance sentence that
recommends using DesignDialog: locate the line mentioning "DesignDialog" and
replace the incorrect "see §22 below" reference with the correct section "see
§4.14 below" so readers are directed to the new DesignDialog contract; keep the
rest of the sentence intact and ensure references to Dialog, DialogContent, and
DialogHeader remain unchanged.
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/design-language/page-client.tsx:
- Around line 1236-1251: Update the props docs text that instructs wrapping
footer close buttons to use the design-system alias: locate the PropsTable props
array (the PropsTable invocation in page-client.tsx) and change the "footer"
prop description from "Wrap close buttons in DialogClose asChild." to use the
design-system component name, e.g. "Wrap close buttons in DesignDialogClose." so
examples align with the DesignDialog API.
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/products/included-item-dialog.tsx:
- Around line 138-144: The select uses the ambiguous sentinel 'create-new' which
may collide with real item IDs; update the logic that builds itemSelectOptions
(and the similar block around the second occurrence) to use a namespaced
sentinel (e.g., '__create_new_item__' or similar unlikely-to-collide token)
instead of 'create-new', and only append that sentinel option when a create
handler exists (e.g., when onCreate or handleCreate is defined); ensure
downstream selection handling checks for this exact sentinel value to trigger
the create flow.
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/products/price-edit-dialog.tsx:
- Around line 193-220: The free-trial count from the DesignInput (managed by
setPriceFreeTrialCount and held in priceFreeTrialCount) can be negative because
parseInt(...) || 1 preserves negative numbers; before calling
onEditingPriceChange to save the edited price (in the onClick handler that sets
freeTrialEnabled, freeTrialCount, freeTrialUnit), clamp priceFreeTrialCount to a
minimum of 1 (and optionally a sane max) and pass the clamped value as
freeTrialCount so negative or zero values cannot be saved.
- Around line 101-108: The click handler on DesignButton allows concurrent async
saves because runAsynchronouslyWithAlert only logs errors; add a local saving
guard (e.g., isSaving state) and use it to short-circuit repeated clicks and to
disable the button; in the onClick for the button (referencing DesignButton,
editingPrice, runAsynchronouslyWithAlert, onSave, isAdding) set isSaving=true
before awaiting the async save, await onSave(editingPrice, isAdding) inside a
try/finally (or finally-style callback) to ensure isSaving is reset to false
even on error, and update the button disabled prop to include isSaving so the UI
prevents duplicate submissions.
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/products/pricing-section.tsx:
- Around line 117-125: Add descriptive accessible labels to the icon-only
destructive buttons by adding an aria-label prop to the DesignButton instances
that contain only a TrashIcon (e.g., the button using DesignButton with
onClick={() => handleRemovePrice(id)} and the other similar occurrences in the
same file). Use clear text such as "Remove price" (or "Remove price for
[context]" if context is available) so assistive technologies can distinguish
these remove actions from other buttons like "make paid"; ensure you update each
DesignButton that wraps TrashIcon (including the other two occurrences
referenced) to include the aria-label.
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/settings/page-client.tsx:
- Around line 25-38: handleBlockChange currently uses runAsynchronouslyWithAlert
to fire-and-forget the update, allowing rapid toggles to race and cause stale
state; change the logic so updates to payments.blockNewPurchases are serialized:
ensure any in-flight update started by handleBlockChange (the promise returned
from updateConfig/runAsynchronouslyWithAlert) is awaited or queued before
starting the next update, and only clear setOptimisticBlocked after the
corresponding awaited update completes; specifically modify handleBlockChange to
await the previous pending promise (or use a per-component mutex/queue) around
the call to updateConfig/runAsynchronouslyWithAlert and reference the existing
symbols handleBlockChange, setOptimisticBlocked, runAsynchronouslyWithAlert, and
updateConfig so toggles are applied sequentially and cannot overwrite newer
values with older completions.
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/sign-up-rules/page-client.tsx:
- Around line 436-439: The finally block currently uses "if (nextRequestId !==
latestRequestIdRef.current) return;", which is unsafe; remove the return and
preserve the stale-request guard by either moving the check out of finally
(place it immediately after the try/catch) or by replacing the return with a
conditional that only executes the loading-state updates when the IDs match
(e.g., if (nextRequestId === latestRequestIdRef.current) { if (reset)
setIsInitialLoading(false); else setIsLoadingMore(false); }). Keep references:
nextRequestId, latestRequestIdRef.current, reset, setIsInitialLoading,
setIsLoadingMore, and the finally block.
In `@apps/dashboard/src/components/ui/action-dialog.tsx`:
- Around line 82-90: The DialogContent currently sets three handlers to block
outside dismissals; simplify by removing onPointerDownOutside and onFocusOutside
and only use onInteractOutside to call e.preventDefault() when
blockDismissOnOutside is true — edit the DialogContent props so only
onInteractOutside={blockDismissOnOutside ? (e) => e.preventDefault() :
undefined} remains; keep the existing className logic (props.preventClose and
props.contentClassName) unchanged and ensure the unique component/Dialog element
referenced is DialogContent in the file.
In `@packages/dashboard-ui-components/src/components/dialog.tsx`:
- Around line 84-103: The Playground is missing demonstrations for several
DesignDialog props; update the Playground story/component that renders
DesignDialog to add interactive controls and visual examples for customHeader
(show both passing a React node and a render callback), a toggle for
noBodyPadding to show padded vs non-padded body, and string inputs or knobs for
className, overlayClassName, headerClassName, bodyClassName, and footerClassName
so users can apply and see custom styles; ensure you reference the DesignDialog
prop names (customHeader, noBodyPadding, className, overlayClassName,
headerClassName, bodyClassName, footerClassName) and render examples that
visibly reflect changes (e.g., custom header content, removed body padding, and
CSS class effects) in the Playground UI.
- Line 109: The current shouldRenderBody logic uses
React.Children.count(children) which treats boolean values as children and
causes DialogBody to render empty padding; update the check in the Dialog
component to only consider renderable children (e.g., replace
React.Children.count(children) > 0 with a filter that ignores
falsy/non-renderable entries such as
React.Children.toArray(children).filter(Boolean).length > 0 or an explicit check
like children != null && children !== false) so DialogBody only renders when
there are real child elements; adjust the variable/method where shouldRenderBody
is computed and ensure DialogBody rendering uses this updated value.
---
Outside diff comments:
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/products/create-product-line-dialog.tsx:
- Around line 55-62: The current code fires runAsynchronously(onCreate(...)) and
immediately clears the form and closes the dialog, which loses state on failure;
change the flow so you await the result of onCreate (or handle its returned
promise) instead of backgrounding it, set a loading flag while awaiting, and
only call setDisplayName(""), setProductLineId(""),
setHasManuallyEditedId(false), setErrors({}), and onOpenChange(false) after
onCreate resolves successfully; if onCreate rejects, catch the error, update the
component error state (via setErrors or a new error setter) and clear the
loading flag without resetting the form so the user can correct and retry
(reference functions: onCreate, runAsynchronously, setDisplayName,
setProductLineId, setHasManuallyEditedId, setErrors, onOpenChange).
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/settings/payment-methods.tsx:
- Around line 203-218: The Switch controls remain active while a save is in
progress, allowing toggles to be lost; update the Switch rendering (the Switch
using checked={isEnabled} and onCheckedChange={() => handleToggle(method.id,
isEnabled)}) to be disabled when saving (use the saving state to either set a
disabled prop on the Switch or short-circuit onCheckedChange) so user toggles
are blocked during handleSave; ensure any UI that relies on
hasPendingChanges/loadConfig/setPendingChanges remains consistent by preventing
state changes from Switch while saving.
- Around line 66-73: handleToggle currently always writes a toggled value into
pendingChanges, so reverting a toggle back to the saved value still leaves an
entry and shows a spurious "Modified" state; update handleToggle to compute the
newEnabled value and compare it to the persisted/saved value for that method
(use whatever source holds saved state for the method, e.g., the methods list or
a savedEnabled map), and then call setPendingChanges to either remove the
methodId key when newEnabled === savedEnabled or set it when different. Ensure
you update the same logic used elsewhere (the other toggle handler that
manipulates pendingChanges) so hasPendingChanges reflects only actual
modifications.
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/settings/test-mode-toggle.tsx:
- Around line 16-22: The async handleToggle function is being passed directly to
the Switch onCheckedChange which fire-forgets the promise and can silently
swallow errors; replace the direct use by invoking runAsynchronously or
runAsynchronouslyWithAlert when the Switch changes so the returned promise is
handled, show an in-flight/loading state (e.g., a local isSaving or optimistic
state) while updateConfig (the function called inside handleToggle) runs, and on
failure revert the optimistic state and surface an alert/error to the user;
update code references include handleToggle, updateConfig, and the Switch
onCheckedChange handler to ensure you do not void the promise and you handle
loading and error states correctly.
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/sign-up-rules/page-client.tsx:
- Around line 1509-1538: The fetchAnalytics function can throw or return early
without clearing the loading flag, leaving the UI stuck; wrap the body of
fetchAnalytics in try/catch/finally (or ensure runAsynchronouslyWithAlert
handles finally) so that setIsLoading(false) is always called regardless of
errors or non-OK responses; specifically update the fetchAnalytics
implementation (referencing fetchAnalytics, setIsLoading, setAnalytics and the
StackAssertionError non-OK branch) to call setIsLoading(false) in a finally
block and preserve the cancelled check and error logging/throwing in the catch.
---
Nitpick comments:
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/auth-methods/page-client.tsx:
- Around line 412-417: The dynamic cast to (stackAdminApp as any) inside
handleChange when calling previewAffectedUsersByOnboardingChange should be
avoided or justified: either create a narrow typed wrapper/interface for the
admin API (e.g., StackAdminApp with previewAffectedUsersByOnboardingChange
signature) and cast stackAdminApp to that type before calling the method, or
retain the cast but add an explanatory comment above it describing why a precise
type cannot be provided (e.g., dynamic runtime admin client, non-exported types)
and what shape is expected; update references to
previewAffectedUsersByOnboardingChange and handleChange accordingly so the call
is typed instead of using plain any.
- Around line 601-606: Replace the loose-typed configUpdate and the explicit
cast by giving configUpdate a concrete typed shape and validating
localMergeStrategy before assigning: in handleSignUpConfirmed, declare
configUpdate as the exact config type (e.g., { 'auth.allowSignUp': boolean;
'auth.oauth.accountMergeStrategy'?: OAuthAccountMergeStrategy }) and only set
configUpdate['auth.oauth.accountMergeStrategy'] when localMergeStrategy is one
of the valid OAuthAccountMergeStrategy enum/string values (perform a runtime
check like if (localMergeStrategy === '...') or a type-guard), then call
updateConfig with that typed object; apply the same change to the other similar
block that sets auth.oauth.accountMergeStrategy so you never use Record<string,
any> or an as-cast.
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/auth-methods/providers.tsx:
- Around line 246-250: In DocsTextLink, the providerId is interpolated directly
into the docs URL; update the URL construction in the DocsTextLink component so
the provider slug is encoded (use urlString`` or encodeURIComponent on the
computed slug) before building the href (handle the special-case mapping
providerId === "x" -> "x-twitter" first, then encode it), and pass the encoded
slug into the Link href to ensure consistent, safe URLs.
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/products/new/page-client.tsx:
- Around line 1047-1053: The dropdown currently force-casts the selected value
in the DesignSelectorDropdown onValueChange handler; replace the cast by
validating the incoming value against the allowed unit set before calling
setFreeTrial. In the onValueChange for DesignSelectorDropdown (the handler that
calls setFreeTrial([freeTrial[0], value as 'day' | 'week' | 'month' | 'year'])),
check that value is one of 'day','week','month','year' (or derive valid values
from freeTrialUnitSelectOptions) and only call setFreeTrial with the validated
unit; otherwise handle the invalid case explicitly (e.g., no-op, throw, or log)
so the type system is not bypassed. Ensure you reference DesignSelectorDropdown,
setFreeTrial, freeTrial, and freeTrialUnitSelectOptions when making the change.
In `@apps/dashboard/src/components/payments/item-dialog.tsx`:
- Around line 193-196: The onValueChange handler currently force-casts the
incoming value (value as typeof customerType) which bypasses type-safety;
instead validate the selected value against the allowed options
(customerTypeDropdownOptions) before calling setCustomerType: implement a small
type-guard or inclusion check that confirms the value exists in
customerTypeDropdownOptions (or derive the allowed union type from that options
array) and only then call setCustomerType(value), otherwise ignore or handle
invalid selection; update the DesignSelectorDropdown onValueChange to use this
validation and remove the cast.
In `@apps/dashboard/src/components/repeating-input.tsx`:
- Around line 256-259: The label construction for options uses a naive English
plural ('s') and can diverge from localized or existing duration labels; update
the options mapping in repeating-input.tsx (where normalizedUnits,
effectiveSelection, intervalCount are used) to reuse the same label helper used
by getIntervalLabel / useDurationLabels so labels mirror the component's
duration formatting and localization (pass the unit and count into that helper
instead of manually appending 's', ensuring the custom popover and duration
labels stay consistent).
- Around line 163-176: The raw <input> used in the RepeatingInput component
breaks shared styling/behavior from DesignInput; replace the native element with
the DesignInput component (e.g., use <DesignInput ... />) and pass the same
props (type/inputType, value, onChange -> onValueChange, placeholder, disabled
|| readOnly, and merge inputClassName) while adding a variant (e.g.,
variant="seamless" or unstyled) so it visually matches the composite trigger;
also ensure the forwarded ref and any existing focus/validation behavior from
DesignInput are preserved in RepeatingInput so future styling/behavior changes
flow through a single input implementation.
In `@apps/dashboard/src/components/ui/action-dialog.tsx`:
- Around line 86-89: Replace the manual array/filter/join class composition with
the project's cn utility: change the className assignment to use cn(...) passing
the conditional class and props.contentClassName (e.g., cn(props.preventClose &&
"[&>button]:hidden", props.contentClassName)); also ensure cn is imported from
'@/lib/utils' at the top of the module if it's not already imported. This
affects the className expression where props.preventClose and
props.contentClassName are used.
In `@packages/dashboard-ui-components/src/components/dialog.tsx`:
- Line 105: The current expression using dialogSurfaceClasses.get(variant) ??
dialogSurfaceClasses.get("glassmorphic") is redundant because Map.get returns
string | undefined, so the fallback doesn't change the type; replace the
fallback with a thrown error to enforce the invariant: if
dialogSurfaceClasses.get(variant) is undefined, call the project's throwErr (or
a small helper that throws) with a clear message so resolvedSurfaceClass is
guaranteed to be a string; update the code referencing resolvedSurfaceClass
accordingly and ensure throwErr is imported/available.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 0c01966f-5a26-4b17-aff6-0d728ba10166
📒 Files selected for processing (26)
.agents/skills/roids/SKILL.mdapps/dashboard/DESIGN-GUIDE.mdapps/dashboard/src/app/(main)/(protected)/(outside-dashboard)/playground/page-client.tsxapps/dashboard/src/app/(main)/(protected)/projects/[projectId]/auth-methods/page-client.tsxapps/dashboard/src/app/(main)/(protected)/projects/[projectId]/auth-methods/providers.tsxapps/dashboard/src/app/(main)/(protected)/projects/[projectId]/design-language/page-client.tsxapps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/products/create-product-line-dialog.tsxapps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/products/included-item-dialog.tsxapps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/products/new/page-client.tsxapps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/products/price-edit-dialog.tsxapps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/products/pricing-section.tsxapps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/settings/page-client.tsxapps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/settings/payment-methods.tsxapps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/settings/stripe-connection-check.tsxapps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/settings/test-mode-toggle.tsxapps/dashboard/src/app/(main)/(protected)/projects/[projectId]/sign-up-rules/page-client.tsxapps/dashboard/src/components/payments/item-dialog.tsxapps/dashboard/src/components/repeating-input.tsxapps/dashboard/src/components/ui/action-dialog.tsxapps/dashboard/src/components/ui/dropdown-menu.tsxapps/dashboard/src/components/ui/popover.tsxapps/dashboard/src/components/ui/select.tsxpackages/dashboard-ui-components/src/components/dialog.tsxpackages/dashboard-ui-components/src/index.tspackages/stack-ui/src/components/ui/popover.tsxskills-lock.json
Comment on lines
+1
to
+20
| --- | ||
| name: roids | ||
| description: Use when presenting more than one comparable UI direction, or proactively whenever you ship multiple layout options for the user to choose—do not wait for the user to mention Roids or type /roids. Use for comparison, preview-first, or pick-a-winner flows before cleanup. Default to a small set of variants (~2–5) unless the user specifies how many. | ||
| metadata: | ||
| version: "1.0.0" | ||
| --- | ||
|
|
||
| # Roids | ||
|
|
||
| Compare variants in the browser with the hosted runtime and markup contract. | ||
|
|
||
| ## How it works | ||
|
|
||
| 1. Fetch the source URL below (documentation only—never load it as `<script src>`). | ||
| 2. Follow `SKILL.txt` exactly—wire `https://tryroids.com/roid-tool.js` and `data-roid-*` when showing multiple variants. | ||
| 3. Do not use custom tabs, selects, or one-off pickers for those variants. | ||
|
|
||
| ## Source | ||
|
|
||
| `https://tryroids.com/SKILL.txt` |
Contributor
There was a problem hiding this comment.
This file looks out-of-scope for the PR’s stated objective.
SKILL.md under .agents/skills/roids/ does not appear related to payments UI/design fixes in the dashboard product code. Please confirm this is intentionally bundled here; otherwise it should be moved to a separate PR to keep review/risk boundaries clean.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.agents/skills/roids/SKILL.md around lines 1 - 20, The added SKILL.md (name:
roids) under .agents/skills/roids appears unrelated to the payments UI changes
in this PR; either confirm it belongs here or remove it from this branch and
create a separate PR. Locate the file referenced by the unique header "name:
roids" and the Source entry "`https://tryroids.com/SKILL.txt`" and either (A)
add a brief PR note confirming this asset is intentionally bundled with the
payment changes, or (B) revert/move the file out of this PR into a dedicated
branch/PR so the current review remains scoped to the dashboard payments UI
work.
| - complex layout containers where design-components does not provide one | ||
| - highly specialized editor internals | ||
|
|
||
| For any general-purpose modal surface (rich detail dialogs, tester surfaces, data dialogs, settings popovers presented as modals), use `DesignDialog` instead of wiring `Dialog` + `DialogContent` + `DialogHeader` etc. by hand. `DesignDialog` is the canonical glassmorphic dialog surface for the dashboard — see §22 below. |
Contributor
There was a problem hiding this comment.
Fix the stale section reference.
see §22 below appears incorrect; the new DesignDialog contract is section 4.14, so this link/reference will confuse readers.
📝 Proposed fix
-For any general-purpose modal surface (rich detail dialogs, tester surfaces, data dialogs, settings popovers presented as modals), use `DesignDialog` instead of wiring `Dialog` + `DialogContent` + `DialogHeader` etc. by hand. `DesignDialog` is the canonical glassmorphic dialog surface for the dashboard — see §22 below.
+For any general-purpose modal surface (rich detail dialogs, tester surfaces, data dialogs, settings popovers presented as modals), use `DesignDialog` instead of wiring `Dialog` + `DialogContent` + `DialogHeader` etc. by hand. `DesignDialog` is the canonical glassmorphic dialog surface for the dashboard — see §4.14 below.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| For any general-purpose modal surface (rich detail dialogs, tester surfaces, data dialogs, settings popovers presented as modals), use `DesignDialog` instead of wiring `Dialog` + `DialogContent` + `DialogHeader` etc. by hand. `DesignDialog` is the canonical glassmorphic dialog surface for the dashboard — see §22 below. | |
| For any general-purpose modal surface (rich detail dialogs, tester surfaces, data dialogs, settings popovers presented as modals), use `DesignDialog` instead of wiring `Dialog` + `DialogContent` + `DialogHeader` etc. by hand. `DesignDialog` is the canonical glassmorphic dialog surface for the dashboard — see §4.14 below. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/dashboard/DESIGN-GUIDE.md` at line 67, Update the stale section
reference in the guidance sentence that recommends using DesignDialog: locate
the line mentioning "DesignDialog" and replace the incorrect "see §22 below"
reference with the correct section "see §4.14 below" so readers are directed to
the new DesignDialog contract; keep the rest of the sentence intact and ensure
references to Dialog, DialogContent, and DialogHeader remain unchanged.
Comment on lines
+1236
to
+1251
| <PropsTable props={[ | ||
| { name: "trigger", type: "ReactNode", description: "Element wrapped in a DialogTrigger. Optional when controlling externally via open/onOpenChange." }, | ||
| { name: "open / onOpenChange / defaultOpen", type: "boolean / fn / boolean", description: "Standard controlled or uncontrolled state for the dialog." }, | ||
| { name: "size", type: "'sm' | 'md' | 'lg' | 'xl' | '2xl' | ... | '7xl' | 'full'", default: "'lg'", description: "Width preset for the modal surface." }, | ||
| { name: "variant", type: "'glassmorphic' | 'plain'", default: "'glassmorphic'", description: "Visual style for the surface and overlay." }, | ||
| { name: "icon", type: "ElementType | null", description: "Icon component for the header chip. Pass null to skip the chip." }, | ||
| { name: "title / description", type: "ReactNode", description: "Standard header text. `title` is wired into DialogTitle for a11y." }, | ||
| { name: "headerContent", type: "ReactNode", description: "Rich content rendered below the icon/title block (summary cards, badges, etc)." }, | ||
| { name: "customHeader", type: "ReactNode", description: "Override the entire header. You become responsible for rendering DialogTitle." }, | ||
| { name: "footer", type: "ReactNode", description: "Footer node. Renders in a styled bottom bar. Wrap close buttons in DialogClose asChild." }, | ||
| { name: "noBodyPadding", type: "boolean", default: "false", description: "Disable the default px-6 py-4 padding for full-bleed content." }, | ||
| { name: "hideTopCloseButton", type: "boolean", default: "false", description: "Hide the top-right close button rendered by DialogContent." }, | ||
| { name: "className", type: "string", description: "Extra classes for the modal surface container." }, | ||
| { name: "overlayClassName", type: "string", description: "Overlay classes, useful for custom backdrop opacity/blur." }, | ||
| { name: "headerClassName / bodyClassName / footerClassName", type: "string", description: "Region-specific class overrides for exact parity migrations." }, | ||
| ]} /> |
Contributor
There was a problem hiding this comment.
Use the design-system close alias in the props docs.
The examples consistently use DesignDialogClose, but the props table says DialogClose asChild; that can encourage mixing raw dialog primitives with DesignDialog.
📝 Proposed fix
- { name: "footer", type: "ReactNode", description: "Footer node. Renders in a styled bottom bar. Wrap close buttons in DialogClose asChild." },
+ { name: "footer", type: "ReactNode", description: "Footer node. Renders in a styled bottom bar. Wrap close buttons in DesignDialogClose asChild." },📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| <PropsTable props={[ | |
| { name: "trigger", type: "ReactNode", description: "Element wrapped in a DialogTrigger. Optional when controlling externally via open/onOpenChange." }, | |
| { name: "open / onOpenChange / defaultOpen", type: "boolean / fn / boolean", description: "Standard controlled or uncontrolled state for the dialog." }, | |
| { name: "size", type: "'sm' | 'md' | 'lg' | 'xl' | '2xl' | ... | '7xl' | 'full'", default: "'lg'", description: "Width preset for the modal surface." }, | |
| { name: "variant", type: "'glassmorphic' | 'plain'", default: "'glassmorphic'", description: "Visual style for the surface and overlay." }, | |
| { name: "icon", type: "ElementType | null", description: "Icon component for the header chip. Pass null to skip the chip." }, | |
| { name: "title / description", type: "ReactNode", description: "Standard header text. `title` is wired into DialogTitle for a11y." }, | |
| { name: "headerContent", type: "ReactNode", description: "Rich content rendered below the icon/title block (summary cards, badges, etc)." }, | |
| { name: "customHeader", type: "ReactNode", description: "Override the entire header. You become responsible for rendering DialogTitle." }, | |
| { name: "footer", type: "ReactNode", description: "Footer node. Renders in a styled bottom bar. Wrap close buttons in DialogClose asChild." }, | |
| { name: "noBodyPadding", type: "boolean", default: "false", description: "Disable the default px-6 py-4 padding for full-bleed content." }, | |
| { name: "hideTopCloseButton", type: "boolean", default: "false", description: "Hide the top-right close button rendered by DialogContent." }, | |
| { name: "className", type: "string", description: "Extra classes for the modal surface container." }, | |
| { name: "overlayClassName", type: "string", description: "Overlay classes, useful for custom backdrop opacity/blur." }, | |
| { name: "headerClassName / bodyClassName / footerClassName", type: "string", description: "Region-specific class overrides for exact parity migrations." }, | |
| ]} /> | |
| <PropsTable props={[ | |
| { name: "trigger", type: "ReactNode", description: "Element wrapped in a DialogTrigger. Optional when controlling externally via open/onOpenChange." }, | |
| { name: "open / onOpenChange / defaultOpen", type: "boolean / fn / boolean", description: "Standard controlled or uncontrolled state for the dialog." }, | |
| { name: "size", type: "'sm' | 'md' | 'lg' | 'xl' | '2xl' | ... | '7xl' | 'full'", default: "'lg'", description: "Width preset for the modal surface." }, | |
| { name: "variant", type: "'glassmorphic' | 'plain'", default: "'glassmorphic'", description: "Visual style for the surface and overlay." }, | |
| { name: "icon", type: "ElementType | null", description: "Icon component for the header chip. Pass null to skip the chip." }, | |
| { name: "title / description", type: "ReactNode", description: "Standard header text. `title` is wired into DialogTitle for a11y." }, | |
| { name: "headerContent", type: "ReactNode", description: "Rich content rendered below the icon/title block (summary cards, badges, etc)." }, | |
| { name: "customHeader", type: "ReactNode", description: "Override the entire header. You become responsible for rendering DialogTitle." }, | |
| { name: "footer", type: "ReactNode", description: "Footer node. Renders in a styled bottom bar. Wrap close buttons in DesignDialogClose asChild." }, | |
| { name: "noBodyPadding", type: "boolean", default: "false", description: "Disable the default px-6 py-4 padding for full-bleed content." }, | |
| { name: "hideTopCloseButton", type: "boolean", default: "false", description: "Hide the top-right close button rendered by DialogContent." }, | |
| { name: "className", type: "string", description: "Extra classes for the modal surface container." }, | |
| { name: "overlayClassName", type: "string", description: "Overlay classes, useful for custom backdrop opacity/blur." }, | |
| { name: "headerClassName / bodyClassName / footerClassName", type: "string", description: "Region-specific class overrides for exact parity migrations." }, | |
| ]} /> |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/design-language/page-client.tsx
around lines 1236 - 1251, Update the props docs text that instructs wrapping
footer close buttons to use the design-system alias: locate the PropsTable props
array (the PropsTable invocation in page-client.tsx) and change the "footer"
prop description from "Wrap close buttons in DialogClose asChild." to use the
design-system component name, e.g. "Wrap close buttons in DesignDialogClose." so
examples align with the DesignDialog API.
Comment on lines
+138
to
+144
| const itemSelectOptions = useMemo(() => [ | ||
| ...existingItems.map(item => ({ | ||
| value: item.id, | ||
| label: `${item.displayName || item.id} (${item.customerType.toUpperCase()} · ${item.id})`, | ||
| })), | ||
| { value: 'create-new', label: '+ Create new item' }, | ||
| ], [existingItems]); |
Contributor
There was a problem hiding this comment.
Avoid colliding the “create new” sentinel with real item IDs.
create-new can be a valid item id, so selecting that item would open the create flow instead. Also hide the option when no create handler exists.
Proposed fix
+const CREATE_NEW_ITEM_OPTION = "__stack:create-new-item__";
+
export function IncludedItemDialog({ const itemSelectOptions = useMemo(() => [
...existingItems.map(item => ({
value: item.id,
label: `${item.displayName || item.id} (${item.customerType.toUpperCase()} · ${item.id})`,
})),
- { value: 'create-new', label: '+ Create new item' },
- ], [existingItems]);
+ ...(onCreateNewItem ? [{ value: CREATE_NEW_ITEM_OPTION, label: '+ Create new item' }] : []),
+ ], [existingItems, onCreateNewItem]); value={selectedItemId}
onValueChange={(value) => {
- if (value === 'create-new') {
- onCreateNewItem?.();
+ if (value === CREATE_NEW_ITEM_OPTION) {
+ onCreateNewItem?.();
} else {Also applies to: 190-193
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/products/included-item-dialog.tsx
around lines 138 - 144, The select uses the ambiguous sentinel 'create-new'
which may collide with real item IDs; update the logic that builds
itemSelectOptions (and the similar block around the second occurrence) to use a
namespaced sentinel (e.g., '__create_new_item__' or similar unlikely-to-collide
token) instead of 'create-new', and only append that sentinel option when a
create handler exists (e.g., when onCreate or handleCreate is defined); ensure
downstream selection handling checks for this exact sentinel value to trigger
the create flow.
Comment on lines
+101
to
+108
| <DesignButton | ||
| size="sm" | ||
| type="button" | ||
| disabled={!editingPrice} | ||
| onClick={() => { | ||
| if (!editingPrice) return; | ||
| runAsynchronouslyWithAlert(() => onSave(editingPrice, isAdding)); | ||
| }} |
Contributor
There was a problem hiding this comment.
Add a saving guard for async price saves.
runAsynchronouslyWithAlert reports errors but does not set loading or prevent repeated clicks, so an async onSave can run concurrently.
Proposed fix
onSave,
}: PriceEditDialogProps) {
+ const [isSaving, setIsSaving] = useState(false);
const [priceFreeTrialPopoverOpen, setPriceFreeTrialPopoverOpen] = useState(false); <DesignButton
size="sm"
type="button"
- disabled={!editingPrice}
+ disabled={!editingPrice || isSaving}
+ loading={isSaving}
onClick={() => {
- if (!editingPrice) return;
- runAsynchronouslyWithAlert(() => onSave(editingPrice, isAdding));
+ if (!editingPrice || isSaving) return;
+ runAsynchronouslyWithAlert(async () => {
+ try {
+ setIsSaving(true);
+ await onSave(editingPrice, isAdding);
+ } finally {
+ setIsSaving(false);
+ }
+ });
}}
>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| <DesignButton | |
| size="sm" | |
| type="button" | |
| disabled={!editingPrice} | |
| onClick={() => { | |
| if (!editingPrice) return; | |
| runAsynchronouslyWithAlert(() => onSave(editingPrice, isAdding)); | |
| }} | |
| import { useState } from 'react'; | |
| // ... other imports and code ... | |
| export function PriceEditDialog({ | |
| onSave, | |
| }: PriceEditDialogProps) { | |
| const [isSaving, setIsSaving] = useState(false); | |
| const [priceFreeTrialPopoverOpen, setPriceFreeTrialPopoverOpen] = useState(false); | |
| // ... other component code ... | |
| <DesignButton | |
| size="sm" | |
| type="button" | |
| disabled={!editingPrice || isSaving} | |
| loading={isSaving} | |
| onClick={() => { | |
| if (!editingPrice || isSaving) return; | |
| runAsynchronouslyWithAlert(async () => { | |
| try { | |
| setIsSaving(true); | |
| await onSave(editingPrice, isAdding); | |
| } finally { | |
| setIsSaving(false); | |
| } | |
| }); | |
| }} | |
| > |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/products/price-edit-dialog.tsx
around lines 101 - 108, The click handler on DesignButton allows concurrent
async saves because runAsynchronouslyWithAlert only logs errors; add a local
saving guard (e.g., isSaving state) and use it to short-circuit repeated clicks
and to disable the button; in the onClick for the button (referencing
DesignButton, editingPrice, runAsynchronouslyWithAlert, onSave, isAdding) set
isSaving=true before awaiting the async save, await onSave(editingPrice,
isAdding) inside a try/finally (or finally-style callback) to ensure isSaving is
reset to false even on error, and update the button disabled prop to include
isSaving so the UI prevents duplicate submissions.
Comment on lines
+25
to
+38
| const handleBlockChange = (checked: boolean) => { | ||
| setOptimisticBlocked(checked); | ||
| runAsynchronouslyWithAlert((async () => { | ||
| try { | ||
| await updateConfig({ | ||
| adminApp, | ||
| configUpdate: { "payments.blockNewPurchases": checked }, | ||
| pushable: true, | ||
| }); | ||
| } finally { | ||
| setOptimisticBlocked(null); | ||
| } | ||
| })()); | ||
| }; |
Contributor
There was a problem hiding this comment.
Serialize the optimistic checkout-control update.
runAsynchronouslyWithAlert fire-and-forgets without queueing, so rapid switch toggles can race and persist an older value after a newer toggle.
Proposed fix
const [optimisticBlocked, setOptimisticBlocked] = useState<boolean | null>(null);
const blocked = optimisticBlocked ?? paymentsConfig.blockNewPurchases;
+ const isBlockUpdatePending = optimisticBlocked !== null;
const handleBlockChange = (checked: boolean) => {
+ if (isBlockUpdatePending) return;
setOptimisticBlocked(checked);
runAsynchronouslyWithAlert((async () => {
try {
await updateConfig({- <Switch checked={blocked} onCheckedChange={handleBlockChange} />
+ <Switch checked={blocked} onCheckedChange={handleBlockChange} disabled={isBlockUpdatePending} />Also applies to: 75-75
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/payments/settings/page-client.tsx
around lines 25 - 38, handleBlockChange currently uses
runAsynchronouslyWithAlert to fire-and-forget the update, allowing rapid toggles
to race and cause stale state; change the logic so updates to
payments.blockNewPurchases are serialized: ensure any in-flight update started
by handleBlockChange (the promise returned from
updateConfig/runAsynchronouslyWithAlert) is awaited or queued before starting
the next update, and only clear setOptimisticBlocked after the corresponding
awaited update completes; specifically modify handleBlockChange to await the
previous pending promise (or use a per-component mutex/queue) around the call to
updateConfig/runAsynchronouslyWithAlert and reference the existing symbols
handleBlockChange, setOptimisticBlocked, runAsynchronouslyWithAlert, and
updateConfig so toggles are applied sequentially and cannot overwrite newer
values with older completions.
Comment on lines
436
to
+439
| } finally { | ||
| if (nextRequestId !== latestRequestIdRef.current) { | ||
| return; | ||
| } | ||
| if (reset) { | ||
| setIsInitialLoading(false); | ||
| } else { | ||
| setIsLoadingMore(false); | ||
| } | ||
| if (nextRequestId !== latestRequestIdRef.current) return; | ||
| if (reset) setIsInitialLoading(false); | ||
| else setIsLoadingMore(false); |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify Biome noUnsafeFinally is cleared.
pnpm lintRepository: stack-auth/stack-auth
Length of output: 20163
🏁 Script executed:
sed -n '430,450p' apps/dashboard/src/app/\(main\)/\(protected\)/projects/\[projectId\]/sign-up-rules/page-client.tsxRepository: stack-auth/stack-auth
Length of output: 875
🏁 Script executed:
# Check ESLint config
cat apps/dashboard/.eslintrc.json 2>/dev/null || cat apps/dashboard/.eslintrc.js 2>/dev/null || cat apps/dashboard/eslint.config.js 2>/dev/null || echo "Checking root config"Repository: stack-auth/stack-auth
Length of output: 85
🏁 Script executed:
# Also search for eslint config in the project root
find . -maxdepth 2 -name "eslint.config.*" -o -name ".eslintrc*" | head -10Repository: stack-auth/stack-auth
Length of output: 86
🏁 Script executed:
# Look at lines around 1509-1538 as mentioned in the scratchpad
sed -n '1509,1545p' apps/dashboard/src/app/\(main\)/\(protected\)/projects/\[projectId\]/sign-up-rules/page-client.tsxRepository: stack-auth/stack-auth
Length of output: 1244
🏁 Script executed:
# Look for ESLint config in dashboard
find apps/dashboard -maxdepth 2 \( -name "eslint.config.*" -o -name ".eslintrc*" \) -type fRepository: stack-auth/stack-auth
Length of output: 93
🏁 Script executed:
# Check the extends and rules in root eslint config
cat .eslintrc.json 2>/dev/null | head -50Repository: stack-auth/stack-auth
Length of output: 47
🏁 Script executed:
# Check if no-unsafe-finally is mentioned anywhere in configs
rg "no-unsafe-finally|noUnsafeFinally" --type jsonRepository: stack-auth/stack-auth
Length of output: 110
🏁 Script executed:
# Check the biome.json configuration
cat biome.jsonRepository: stack-auth/stack-auth
Length of output: 1324
🏁 Script executed:
# Check if Biome is in the lint script
cat package.json | grep -A 5 '"lint"'Repository: stack-auth/stack-auth
Length of output: 322
🏁 Script executed:
# Check the dashboard's eslint config to see if it uses Biome
cat apps/dashboard/.eslintrc.cjsRepository: stack-auth/stack-auth
Length of output: 2150
🏁 Script executed:
# Check if Biome is invoked anywhere in the lint pipeline
rg "biome" package.json apps/dashboard/package.jsonRepository: stack-auth/stack-auth
Length of output: 47
🏁 Script executed:
# Double-check by looking at the actual error output - was there any Biome output?
# Search for any biome invocation in configs
rg "biome" configs/ 2>/dev/null || echo "No biome in configs"Repository: stack-auth/stack-auth
Length of output: 84
Remove the return from the finally block.
Returning from a finally block is unsafe as it masks control flow from the preceding try/catch. Keep the stale-request guard, but avoid returning from finally.
Proposed fix
} finally {
- if (nextRequestId !== latestRequestIdRef.current) return;
- if (reset) setIsInitialLoading(false);
- else setIsLoadingMore(false);
+ if (nextRequestId === latestRequestIdRef.current) {
+ if (reset) setIsInitialLoading(false);
+ else setIsLoadingMore(false);
+ }
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| } finally { | |
| if (nextRequestId !== latestRequestIdRef.current) { | |
| return; | |
| } | |
| if (reset) { | |
| setIsInitialLoading(false); | |
| } else { | |
| setIsLoadingMore(false); | |
| } | |
| if (nextRequestId !== latestRequestIdRef.current) return; | |
| if (reset) setIsInitialLoading(false); | |
| else setIsLoadingMore(false); | |
| } finally { | |
| if (nextRequestId === latestRequestIdRef.current) { | |
| if (reset) setIsInitialLoading(false); | |
| else setIsLoadingMore(false); | |
| } | |
| } |
🧰 Tools
🪛 Biome (2.4.11)
[error] 437-437: Unsafe usage of 'return'.
(lint/correctness/noUnsafeFinally)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/sign-up-rules/page-client.tsx
around lines 436 - 439, The finally block currently uses "if (nextRequestId !==
latestRequestIdRef.current) return;", which is unsafe; remove the return and
preserve the stale-request guard by either moving the check out of finally
(place it immediately after the try/catch) or by replacing the return with a
conditional that only executes the loading-state updates when the IDs match
(e.g., if (nextRequestId === latestRequestIdRef.current) { if (reset)
setIsInitialLoading(false); else setIsLoadingMore(false); }). Keep references:
nextRequestId, latestRequestIdRef.current, reset, setIsInitialLoading,
setIsLoadingMore, and the finally block.
Comment on lines
82
to
90
| <DialogContent | ||
| onInteractOutside={props.preventClose ? (e) => e.preventDefault() : undefined} | ||
| className={props.preventClose ? "[&>button]:hidden" : ""} | ||
| onInteractOutside={blockDismissOnOutside ? (e) => e.preventDefault() : undefined} | ||
| onPointerDownOutside={blockDismissOnOutside ? (e) => e.preventDefault() : undefined} | ||
| onFocusOutside={blockDismissOnOutside ? (e) => e.preventDefault() : undefined} | ||
| className={[ | ||
| props.preventClose ? "[&>button]:hidden" : "", | ||
| props.contentClassName ?? "", | ||
| ].filter(Boolean).join(" ")} | ||
| > |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Radix UI Dialog onInteractOutside vs onPointerDownOutside vs onFocusOutside behavior
💡 Result:
In Radix UI Dialog (which uses DismissableLayer internally), the three events on Dialog.Content control dismissal behavior when interactions occur outside the dialog bounds. All can be prevented with event.preventDefault to stop the dialog from closing. onPointerDownOutside: Fires on pointerdown (mouse down, touch start) outside the component. Specific to pointer input start. Use to handle/prevent dismissal from clicks/taps outside. [1,2,10,14] onFocusOutside: Fires when focus moves outside the component (e.g., tabbing away or programmatic focus shift). Specific to keyboard/screen reader navigation. Prevents dismissal on focus loss. [14,16] onInteractOutside: Convenience handler that fires for ANY outside interaction—either pointerdown OR focus change. Called before the specific handlers. Use when you want unified handling for both pointer and focus events. Type: PointerDownOutsideEvent | FocusOutsideEvent. [2,10,14,16,18] Key differences: - Granular control: Use specific handlers (onPointerDownOutside/onFocusOutside) when you need different logic per event type. - Broad control: Use onInteractOutside for simple cases (e.g., always prevent both: onInteractOutside={(e) => e.preventDefault}). - Order: onInteractOutside first, then specifics if not prevented. - Modal prop (Dialog.Root): When true (default), adds extra protections like pointer-events: none on body, but these events still fire for dismissal. Examples: Prevent click-outside only: onPointerDownOutside={(e) => e.preventDefault} Prevent all outside interactions: onInteractOutside={(e) => e.preventDefault} Allow focus-out but not clicks: onPointerDownOutside={(e) => e.preventDefault}; omit others.
Citations:
- 1: https://www.radix-ui.com/docs/primitives/components/dialog
- 2: Why does the modal dialog allow dismissal by clicking outside by default? radix-ui/primitives#1997
- 3: https://contextqmd.com/libraries/radix-ui-website/versions/latest/pages/data-primitives-docs-components-dialog
- 4: https://radix-ui-primitives.mintlify.app/api/dismissable-layer
- 5: https://jsr.io/@radix-ui-fork/react-dismissable-layer/doc/~/DismissableLayerProps
- 6: [DismissableLayer] Re-add
onInteractOutsideand reimplementonFocusOutsideradix-ui/primitives#671
🏁 Script executed:
cat -n apps/dashboard/src/components/ui/action-dialog.tsxRepository: stack-auth/stack-auth
Length of output: 7066
🏁 Script executed:
cat -n apps/dashboard/src/components/ui/dialog.tsx | head -100Repository: stack-auth/stack-auth
Length of output: 4442
🏁 Script executed:
rg "keepOpenOnOutsideInteraction|blockDismissOnOutside" apps/dashboard/src --type tsx --type ts -A 3 -B 3Repository: stack-auth/stack-auth
Length of output: 92
🏁 Script executed:
rg "keepOpenOnOutsideInteraction|blockDismissOnOutside" apps/dashboard/src -A 3 -B 3Repository: stack-auth/stack-auth
Length of output: 2387
🏁 Script executed:
rg "keepOpenOnOutsideInteraction\s*[:=]" apps/dashboard/src --context 2Repository: stack-auth/stack-auth
Length of output: 47
🏁 Script executed:
rg "ActionDialog" apps/dashboard/src --context 5 | head -100Repository: stack-auth/stack-auth
Length of output: 8808
🏁 Script executed:
rg "keepOpenOnOutsideInteraction" apps/dashboard/src --context 10Repository: stack-auth/stack-auth
Length of output: 4038
🏁 Script executed:
rg "keepOpenOnOutsideInteraction\s*[=:]" apps/dashboard/srcRepository: stack-auth/stack-auth
Length of output: 47
🏁 Script executed:
fd -type f -name "*.tsx" -o -name "*.ts" apps/dashboard/src | xargs grep -l "keepOpenOnOutsideInteraction"Repository: stack-auth/stack-auth
Length of output: 237
🏁 Script executed:
grep -r "keepOpenOnOutsideInteraction" apps/dashboard/srcRepository: stack-auth/stack-auth
Length of output: 302
🏁 Script executed:
grep -r "keepOpenOnOutsideInteraction\s*[=:]" apps/dashboard/src --include="*.tsx" --include="*.ts"Repository: stack-auth/stack-auth
Length of output: 47
🏁 Script executed:
grep -r "preventClose" apps/dashboard/src --context 3 | grep -A 5 -B 5 "ActionDialog"Repository: stack-auth/stack-auth
Length of output: 1075
🏁 Script executed:
web_search
Radix Dialog dismissable layer onInteractOutside prevents specific handlersRepository: stack-auth/stack-auth
Length of output: 159
🌐 Web query:
Radix UI Dialog onInteractOutside preventDefault blocks onPointerDownOutside onFocusOutside
💡 Result:
In Radix UI Dialog (built on DismissableLayer), calling preventDefault in onInteractOutside blocks dismissal for both pointer down events outside (onPointerDownOutside) and focus events outside (onFocusOutside). This is the intended behavior. onInteractOutside is a convenience handler called before the specific handlers (onPointerDownOutside and onFocusOutside). Calling e.preventDefault in onInteractOutside prevents the dismissal trigger from propagating to those specific handlers, effectively blocking both types of outside interactions from dismissing the dialog. To prevent dismissal on outside interactions (both pointer and focus), use: <DialogContent onInteractOutside={(e) => e.preventDefault} /> To prevent only pointer outside dismissal (common for modals), use onPointerDownOutside={(e) => e.preventDefault} instead. This matches official docs and GitHub discussions where onInteractOutside={(e) => e.preventDefault} is recommended to disable outside click closing.
Citations:
- 1: https://radix-ui-primitives.mintlify.app/api/dismissable-layer
- 2: https://www.radix-ui.com/primitives/docs/components/dialog
- 3: https://www.radix-ui.com/docs/primitives/components/dialog
- 4: Why does the modal dialog allow dismissal by clicking outside by default? radix-ui/primitives#1997
- 5: Anyway to disable dialog close on outside click ? radix-ui/primitives#2497
- 6: https://stackoverflow.com/questions/79793493/shadcn-how-do-i-prevent-a-dialog-from-closing-when-clicking-outside
Simplify to use only onInteractOutside for blocking outside interactions.
Radix Dialog's onInteractOutside is a convenience handler that fires for any outside interaction (pointer or focus) and is called before the specific handlers. Calling preventDefault() on onInteractOutside prevents dismissal from both pointer and focus events, making the separate onPointerDownOutside and onFocusOutside handlers redundant. Use only:
onInteractOutside={blockDismissOnOutside ? (e) => e.preventDefault() : undefined}
This achieves the same blocking behavior while being cleaner and following Radix's recommended pattern.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/dashboard/src/components/ui/action-dialog.tsx` around lines 82 - 90, The
DialogContent currently sets three handlers to block outside dismissals;
simplify by removing onPointerDownOutside and onFocusOutside and only use
onInteractOutside to call e.preventDefault() when blockDismissOnOutside is true
— edit the DialogContent props so only onInteractOutside={blockDismissOnOutside
? (e) => e.preventDefault() : undefined} remains; keep the existing className
logic (props.preventClose and props.contentClassName) unchanged and ensure the
unique component/Dialog element referenced is DialogContent in the file.
Comment on lines
+84
to
+103
| export function DesignDialog({ | ||
| trigger, | ||
| size = "lg", | ||
| variant = "glassmorphic", | ||
| icon: Icon = null, | ||
| title, | ||
| description, | ||
| headerContent, | ||
| customHeader, | ||
| footer, | ||
| noBodyPadding = false, | ||
| hideTopCloseButton = false, | ||
| className, | ||
| overlayClassName, | ||
| headerClassName, | ||
| bodyClassName, | ||
| footerClassName, | ||
| children, | ||
| ...dialogRootProps | ||
| }: DesignDialogProps) { |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
fd -t f 'playground' apps/dashboard/src | xargs rg -nP -C2 '\bDesignDialog\b' || trueRepository: stack-auth/stack-auth
Length of output: 21854
🏁 Script executed:
grep -n "dialogVariant\|dialogSize\|dialogIcon\|dialogTitle\|dialogDescription\|dialogHeaderContent\|dialogCustomHeader\|dialogNoBodyPadding\|dialogHideClose\|dialogClassName\|dialogOverlayClassName\|dialogHeaderClassName\|dialogBodyClassName\|dialogFooterClassName" apps/dashboard/src/app/\(main\)/\(protected\)/\(outside-dashboard\)/playground/page-client.tsx | head -100Repository: stack-auth/stack-auth
Length of output: 1391
🏁 Script executed:
grep -n "headerContent\|customHeader\|noBodyPadding\|hideTopCloseButton\|headerClassName\|bodyClassName\|footerClassName\|overlayClassName" apps/dashboard/src/app/\(main\)/\(protected\)/\(outside-dashboard\)/playground/page-client.tsxRepository: stack-auth/stack-auth
Length of output: 691
🏁 Script executed:
grep -n "dialogShowIcon\|dialogShape\|dialogHideTopClose\|customHeader\|noBodyPadding\|useState" apps/dashboard/src/app/\(main\)/\(protected\)/\(outside-dashboard\)/playground/page-client.tsx | grep -E "(dialogShowIcon|dialogShape|dialogHideTopClose|customHeader|noBodyPadding|useState.*dialog)" | head -50Repository: stack-auth/stack-auth
Length of output: 1574
🏁 Script executed:
grep -n "dialogFooter\|footer.*dialog\|dialogShowFooter" apps/dashboard/src/app/\(main\)/\(protected\)/\(outside-dashboard\)/playground/page-client.tsx | head -20Repository: stack-auth/stack-auth
Length of output: 336
🏁 Script executed:
sed -n '84,110p' packages/dashboard-ui-components/src/components/dialog.tsxRepository: stack-auth/stack-auth
Length of output: 963
Playground is missing demonstrations for customHeader, noBodyPadding, and className variants.
The Playground page demonstrates size, variant, icon, title, description, headerContent, footer, and hideTopCloseButton — but does not include interactive controls for customHeader, noBodyPadding, className, overlayClassName, headerClassName, bodyClassName, or footerClassName. Add showcases for these props to ensure comprehensive Playground coverage.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/dashboard-ui-components/src/components/dialog.tsx` around lines 84 -
103, The Playground is missing demonstrations for several DesignDialog props;
update the Playground story/component that renders DesignDialog to add
interactive controls and visual examples for customHeader (show both passing a
React node and a render callback), a toggle for noBodyPadding to show padded vs
non-padded body, and string inputs or knobs for className, overlayClassName,
headerClassName, bodyClassName, and footerClassName so users can apply and see
custom styles; ensure you reference the DesignDialog prop names (customHeader,
noBodyPadding, className, overlayClassName, headerClassName, bodyClassName,
footerClassName) and render examples that visibly reflect changes (e.g., custom
header content, removed body padding, and CSS class effects) in the Playground
UI.
| const resolvedOverlayClass = cn(dialogOverlayClasses.get(variant), overlayClassName); | ||
| const shouldRenderTopHeaderRow = Icon != null || title != null || description != null; | ||
| const shouldRenderHeader = customHeader != null || shouldRenderTopHeaderRow || headerContent != null; | ||
| const shouldRenderBody = React.Children.count(children) > 0; |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
React.Children.count null undefined boolean behavior
💡 Result:
React.Children.count(children) counts the number of "slots" or nodes in the opaque children data structure, equivalent to how many times a callback would be invoked by Children.map or Children.forEach. Specific behavior: - null (top-level): 0 - undefined (top-level): 0 - false (top-level): 1 - true (top-level): 1 (as Booleans count per docs) - [] (top-level): 0 - [null]: 1 (array slot counts, even if null inside) - [undefined]: 1 - ["hello"]: 1 - Single React element: 1 - Multiple children: sums their individual counts Empty nodes like null/undefined/Booleans count as individual nodes when they occupy slots (e.g. in arrays or as direct falsy booleans except top-level null/undefined). This differs from Children.toArray, which skips unrenderable values like null, undefined, false, true. To count only renderable children, use React.Children.toArray(children).filter(Boolean).length or similar. This behavior is intentional (confirmed in React GitHub issues #7685, #14564) and documented in current React docs (react.dev/reference/react/Children#children-count-caveats): "Empty nodes (null, undefined, and Booleans), strings, numbers, and React elements count as individual nodes."
Citations:
- 1: https://react.dev/reference/react/Children
- 2: React.Children.count is incorrect for false value facebook/react#7685
- 3: React.Children.count returns invalid number of children facebook/react#14564
- 4: https://dev.to/boywithsilverwings/counting-react-children-kde
🏁 Script executed:
# First, let's locate the file
find . -name "dialog.tsx" -path "*/dashboard-ui-components/*" | head -20Repository: stack-auth/stack-auth
Length of output: 125
🏁 Script executed:
# Let's examine the file around lines 109 and 167-177
cat -n ./packages/dashboard-ui-components/src/components/dialog.tsx | sed -n '100,120p'Repository: stack-auth/stack-auth
Length of output: 1017
🏁 Script executed:
# And the second location
cat -n ./packages/dashboard-ui-components/src/components/dialog.tsx | sed -n '160,185p'Repository: stack-auth/stack-auth
Length of output: 908
🏁 Script executed:
# Let's check the context more broadly to understand the props
cat -n ./packages/dashboard-ui-components/src/components/dialog.tsx | sed -n '1,110p'Repository: stack-auth/stack-auth
Length of output: 3917
🏁 Script executed:
# Let's also search for usages of DesignDialog in the codebase to see if the false/boolean pattern is actually used
rg "DesignDialog" --type tsx --type ts -A 5 -B 2 | head -100Repository: stack-auth/stack-auth
Length of output: 92
🏁 Script executed:
# Better search for DesignDialog usages
rg "DesignDialog" -g "*.ts" -g "*.tsx" -g "*.js" -g "*.jsx" -A 3 | head -150Repository: stack-auth/stack-auth
Length of output: 15009
Boolean children render empty DialogBody with unnecessary padding.
React.Children.count(children) counts boolean values (true/false) and other non-renderable values, so <DesignDialog>{condition && <Foo/>}</DesignDialog> with a falsy condition will still render an empty DialogBody (with its padding and borders). Use React.Children.toArray(children).filter(Boolean).length > 0 to count only renderable children, or children != null && children !== false for explicit null/boolean checks.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/dashboard-ui-components/src/components/dialog.tsx` at line 109, The
current shouldRenderBody logic uses React.Children.count(children) which treats
boolean values as children and causes DialogBody to render empty padding; update
the check in the Dialog component to only consider renderable children (e.g.,
replace React.Children.count(children) > 0 with a filter that ignores
falsy/non-renderable entries such as
React.Children.toArray(children).filter(Boolean).length > 0 or an explicit check
like children != null && children !== false) so DialogBody only renders when
there are real child elements; adjust the variable/method where shouldRenderBody
is computed and ensure DialogBody rendering uses this updated value.
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
| type="number" | ||
| min={1} | ||
| value={priceFreeTrialCount} | ||
| onChange={(e) => setPriceFreeTrialCount(parseInt(e.target.value) || 1)} |
There was a problem hiding this comment.
Suggested change
| onChange={(e) => setPriceFreeTrialCount(parseInt(e.target.value) || 1)} | |
| onChange={(e) => setPriceFreeTrialCount(Math.max(1, parseInt(e.target.value) || 1))} |
Negative free-trial count values can be entered and saved because the || 1 fallback doesn't protect against negative numbers.
|
|
||
| const handleBlockChange = (checked: boolean) => { | ||
| setOptimisticBlocked(checked); | ||
| runAsynchronouslyWithAlert((async () => { |
There was a problem hiding this comment.
Race condition in optimistic UI update causes UI flicker when user toggles switch rapidly
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
New Features
Design & UI
Documentation