apps/dashboard/src/components/app-warning-modal.tsx (2)

182-186: Consider using <Button> with async handler for loading state.

Per coding guidelines, button components like <Button> support async callbacks with built-in loading state. If onConfirm is async (e.g., enabling an app), the current implementation won't show loading feedback and allows double-clicks.

Consider importing and using the Button component from @stackframe/stack-ui with async onClick to leverage built-in loading state handling, similar to the Cancel button pattern.

---

87-92: Add aria-label to close button for accessibility.

The close button only has an X icon without accessible text for screen readers.

             <button
               onClick={onClose}
               className="p-1.5 rounded-lg hover:bg-gray-100 dark:hover:bg-gray-800 transition-colors"
+              aria-label="Close modal"
             >
               <X className="w-4 h-4 text-gray-500" />
             </button>

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/(overview)/charts-section-with-data.tsx (1)

93-93: Consider typing user data instead of any.

Both user mappings use any type annotation, losing type safety. If a user type exists in the codebase, applying it would catch potential property access errors at compile time.

Also applies to: 157-157

apps/dashboard/src/components/app-store-entry.tsx (1)

23-28: Consider making features configurable per app.

The comment suggests future customization, but consider defining this in apps-config.ts or apps-frontend.tsx now to avoid hardcoded marketing claims that may not apply to all apps (e.g., "Production Ready" for alpha apps).

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/apps/page-client.tsx (2)

56-57: Use installedAppsSet for O(1) lookup instead of includes().

Line 57 uses installedApps.includes(appId) while installedAppsSet was created specifically for O(1) lookups. This inconsistency also appears in getCategoryCount at line 90.

     // Apply category filter
     if (selectedCategory === "installed") {
-      apps = apps.filter(appId => installedApps.includes(appId));
+      apps = apps.filter(appId => installedAppsSet.has(appId));
     } else if (selectedCategory !== "all") {

Also update line 90:

   const getCategoryCount = (categoryId: string) => {
-    if (categoryId === "installed") return installedApps.length;
+    if (categoryId === "installed") return installedAppsSet.size;

---

88-102: Consider memoizing getCategoryCount with useCallback.

getCategoryCount is called for each category tab during every render. While the computation is lightweight, wrapping it in useCallback would be consistent with the memoization strategy used elsewhere in this component.

apps/dashboard/src/components/app-square.tsx (1)

201-277: AppListItem looks good but consider consistent error handling.

The onEnable callback at line 267 is fire-and-forget. If the caller passes an async function, errors won't be handled. Consider documenting this expectation or wrapping in runAsynchronously.

apps/dashboard/src/components/settings.tsx (1)

66-69: Wrap async callback with runAsynchronouslyWithAlert.

If propOnCheckedChange throws, the error will propagate but may not be handled by the Switch component's event system. Consider wrapping with error handling.

   const onCheckedChange = useCallback(async (checked: boolean) => {
     setCheckedState(checked);
-    await propOnCheckedChange(checked);
+    await propOnCheckedChange(checked); 
   }, [propOnCheckedChange]);

Since this is called directly (not via runAsynchronously), ensure callers handle errors, or wrap the call site:

           <Switch
             id={id}
             checked={checked}
-            onCheckedChange={onCheckedChange}
+            onCheckedChange={(checked) => runAsynchronouslyWithAlert(onCheckedChange(checked))}
             disabled={props.disabled}
           />

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/(overview)/metrics-page.tsx (4)

50-77: Avoid try-catch with console.error for error handling.

The loadConfig function uses try-catch with console.error, which violates the coding guidelines. Per project conventions, use runAsynchronously or runAsynchronouslyWithAlert for error handling instead of try-catch blocks.

However, since this is a synchronous localStorage read during initialization, consider either:

1. Letting the error propagate (localStorage errors are rare)
2. Using a silent fallback without logging

 function loadConfig(): DashboardConfig {
   if (typeof window === 'undefined') return DEFAULT_CONFIG;
-  try {
-    const stored = localStorage.getItem(STORAGE_KEY);
-    if (stored) {
-      const parsed = JSON.parse(stored);
-      // Validate and merge with defaults for any new widgets
-      const validWidgetIds = new Set(AVAILABLE_WIDGETS.map(w => w.id));
-      const enabledWidgets = (parsed.enabledWidgets || []).filter((id: string) => validWidgetIds.has(id as WidgetId));
-      const widgetOrder = (parsed.widgetOrder || []).filter((id: string) => validWidgetIds.has(id as WidgetId));
-      
-      // Add any new widgets that aren't in the stored config
-      for (const widget of AVAILABLE_WIDGETS) {
-        if (!widgetOrder.includes(widget.id)) {
-          widgetOrder.push(widget.id);
-          if (widget.defaultEnabled) {
-            enabledWidgets.push(widget.id);
-          }
+  const stored = localStorage.getItem(STORAGE_KEY);
+  if (stored) {
+    const parsed = JSON.parse(stored);
+    // Validate and merge with defaults for any new widgets
+    const validWidgetIds = new Set(AVAILABLE_WIDGETS.map(w => w.id));
+    const enabledWidgets = (parsed.enabledWidgets || []).filter((id: string) => validWidgetIds.has(id as WidgetId));
+    const widgetOrder = (parsed.widgetOrder || []).filter((id: string) => validWidgetIds.has(id as WidgetId));
+    
+    // Add any new widgets that aren't in the stored config
+    for (const widget of AVAILABLE_WIDGETS) {
+      if (!widgetOrder.includes(widget.id)) {
+        widgetOrder.push(widget.id);
+        if (widget.defaultEnabled) {
+          enabledWidgets.push(widget.id);
         }
       }
-      
-      return { enabledWidgets, widgetOrder };
     }
-  } catch (e) {
-    console.error('Failed to load dashboard config:', e);
+    
+    return { enabledWidgets, widgetOrder };
   }
   return DEFAULT_CONFIG;
 }

---

79-87: Remove unused saveConfig function.

The saveConfig function is defined but never called. The TODO comment indicates it will be used when widget configuration UI is implemented, but dead code should not be committed. Consider removing it and adding it back when the feature is implemented.

---

121-128: Replace any types with proper typing.

The reduce callback uses any types which reduces type safety. Since DataPoint has a defined structure, use proper types.

-    const filteredData = timeRange === '7d' ? dailyUsers.slice(-7) : dailyUsers.slice(-30);
-    return filteredData.reduce((sum: any, point: { activity: any; }) => sum + point.activity, 0);
+    const filteredData = timeRange === '7d' ? dailyUsers.slice(-7) : dailyUsers.slice(-30);
+    return filteredData.reduce((sum: number, point: { activity: number }) => sum + point.activity, 0);

---

194-204: Replace any type for data prop with a proper interface.

Both DailyActiveUsersWidget and DailySignUpsWidget use data: any which loses type safety. Define an interface for the metrics data structure.

+interface MetricsData {
+  daily_active_users?: DataPoint[];
+  recently_active?: UserListItem[];
+  daily_users?: DataPoint[];
+  recently_registered?: UserListItem[];
+  total_users?: number;
+}

 function DailyActiveUsersWidget({ 
   data, 
   projectId, 
   router, 
   timeRange 
 }: { 
-  data: any, 
+  data: MetricsData, 
   projectId: string, 
   router: ReturnType<typeof useRouter>, 
   timeRange: TimeRange 
 }) {

Also applies to: 220-230

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/vercel/page-client.tsx (1)

309-312: Unused itemId parameter in handleItemClick.

The itemId parameter is received but never used. Either remove the parameter or use it for more granular item-level completion tracking if intended.

-const handleItemClick = (stepId: StepId, itemId: string) => {
+const handleItemClick = (stepId: StepId, _itemId: string) => {
   // Toggle the step completion when clicking on an item
   toggleStepCompletion(stepId);
 };

Or if item-level tracking is intended:

 const handleItemClick = (stepId: StepId, itemId: string) => {
-  // Toggle the step completion when clicking on an item
-  toggleStepCompletion(stepId);
+  // TODO: Implement item-level completion tracking using itemId
+  toggleStepCompletion(stepId);
 };

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/project-settings/page-client.tsx (3)

21-45: Replace any type with proper interface for TeamMemberItem.

The member prop uses any type which loses type safety. Define a proper interface based on the expected shape.

-function TeamMemberItem({ member }: { member: any }) {
+interface TeamMember {
+  id: string;
+  teamProfile: {
+    displayName?: string | null;
+    profileImageUrl?: string | null;
+  };
+}
+
+function TeamMemberItem({ member }: { member: TeamMember }) {
   const displayName = member.teamProfile.displayName?.trim() || "Name not set";

---

139-141: Replace any type with proper team type.

The handleTeamSwitcherChange callback uses any for the team parameter. Use the proper team type from the SDK.

-const handleTeamSwitcherChange = useCallback(async (team: any) => {
+const handleTeamSwitcherChange = useCallback(async (team: { id: string }) => {
   setSelectedTeamId(team.id);
 }, []);

---

230-245: Inconsistent memoization for logo handlers.

handleLogoChange and handleFullLogoChange are memoized (lines 125-131), but the dark mode logo handlers (lines 230-241) are inline async functions. This inconsistency could cause unnecessary re-renders.

Consider memoizing all logo handlers for consistency:

+const handleLogoDarkModeChange = useCallback(async (logoDarkModeUrl: string | null) => {
+  await project.update({ logoDarkModeUrl });
+}, [project]);
+
+const handleLogoFullDarkModeChange = useCallback(async (logoFullDarkModeUrl: string | null) => {
+  await project.update({ logoFullDarkModeUrl });
+}, [project]);

 <LogoUpload
   label="Logo (Dark Mode)"
   value={project.logoDarkModeUrl}
-  onValueChange={async (logoDarkModeUrl) => {
-    await project.update({ logoDarkModeUrl });
-  }}
+  onValueChange={handleLogoDarkModeChange}
   ...
 />

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/(overview)/globe.tsx (2)

77-78: Remove unused displayName variable.

The displayName variable is defined but never used in the component. This appears to be leftover from the previous implementation.

 const user = useUser({ or: "redirect" });
-const displayName = user.displayName ?? user.primaryEmail;

---

39-40: Remove unused refs and size hooks.

sectionContainerRef and sectionContainerSize are defined but never used meaningfully. The ref is attached to an element (line 138) but the size is never consumed.

 const globeContainerRef = useRef<HTMLDivElement>(null);
 const globeContainerSize = useSize(globeContainerRef);
-const sectionContainerRef = useRef<HTMLDivElement>(null);
-const sectionContainerSize = useSize(sectionContainerRef);

And update the JSX:

 <div
-  ref={sectionContainerRef}
   className='relative flex items-center justify-center'
 >

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/(overview)/line-chart.tsx (2)

34-39: Import isWeekend from shared utilities instead of duplicating.

This isWeekend function duplicates the one in packages/stack-shared/src/utils/dates.tsx. Import from the shared package to avoid duplication.

+import { isWeekend as isWeekendDate } from '@stackframe/stack-shared/dist/utils/dates';

-const isWeekend = (dateString: string): boolean => {
-  const date = new Date(dateString);
-  if (isNaN(date.getTime())) return false;
-  const dayOfWeek = date.getDay();
-  return dayOfWeek === 0 || dayOfWeek === 6; // Sunday (0) or Saturday (6)
-}
+const isWeekend = (dateString: string): boolean => {
+  const date = new Date(dateString);
+  if (isNaN(date.getTime())) return false;
+  return isWeekendDate(date);
+};

---

548-550: Inconsistent access patterns for BRAND_CONFIG.

The code uses both direct object access (BRAND_CONFIG[key as keyof typeof BRAND_CONFIG]) and Map access (BRAND_CONFIG_MAP.get(item.method)). Use the Map consistently since it was created for efficient lookups.

-const brandConfig = key ? BRAND_CONFIG[key as keyof typeof BRAND_CONFIG] : undefined;
+const brandConfig = key ? BRAND_CONFIG_MAP.get(key) : undefined;

-style={{ backgroundColor: BRAND_CONFIG[item.method as keyof typeof BRAND_CONFIG]?.color ?? "var(--color-other)" }}
+style={{ backgroundColor: BRAND_CONFIG_MAP.get(item.method)?.color ?? "var(--color-other)" }}

Also applies to: 602-605

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T02:09:03.086Z
Learning: Applies to **/apps-{frontend,config}.{ts,tsx} : To update available apps, edit `apps-frontend.tsx` and `apps-config.ts`

Learnt from: N2D4
Repo: stack-auth/stack-auth PR: 943
File: examples/convex/app/action/page.tsx:23-28
Timestamp: 2025-10-11T04:13:19.308Z
Learning: In the stack-auth codebase, use `runAsynchronouslyWithAlert` from `stackframe/stack-shared/dist/utils/promises` for async button click handlers and form submissions instead of manual try/catch blocks. This utility automatically handles errors and shows alerts to users.

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T02:09:03.086Z
Learning: Applies to **/*.{ts,tsx} : Never use `toast` for blocking alerts and errors; use alerts instead as they are more visible to users

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T02:09:03.086Z
Learning: Applies to apps/**/*.{ts,tsx} : Prefer client components and dynamic functions like `usePathname` over Next.js dynamic functions to keep pages static; avoid using `await params` or similar dynamic patterns

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T02:09:03.086Z
Learning: Applies to apps/backend/src/app/api/latest/**/*.{ts,tsx} : In the Stack Auth monorepo backend API, organize routes by resource type (auth, user management, team management, OAuth providers) in `/apps/backend/src/app/api/latest/*`

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T02:09:03.086Z
Learning: When making dashboard changes, provide deep links to the dashboard page in the format `http://localhost:<$NEXT_PUBLIC_STACK_PORT_PREFIX>01/projects/-selector-/...` (or use a.localhost, b.localhost, c.localhost for port prefixes 91, 92, 93)

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T02:09:03.086Z
Learning: Applies to **/*.{ts,tsx} : Never use try-catch-all, never void a promise, never use .catch(console.error) or similar; use `runAsynchronously` or `runAsynchronouslyWithAlert` for error handling instead of try-catch blocks

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/(overview)/globe.tsx (2)

133-133: Consider throttling tooltip position updates for better performance.

Updating tooltipPos on every mousemove event (line 157) triggers a re-render for each movement, which can be expensive. Consider throttling or using a ref-based approach for smoother performance.

Example with throttling:

const throttledSetTooltipPos = useRef(
  throttle((x: number, y: number) => setTooltipPos({ x, y }), 16) // ~60fps
).current;

Then in the onMouseMove handler:

  onMouseMove={(e) => {
    resumeRender();
-   setTooltipPos({ x: e.clientX, y: e.clientY });
+   throttledSetTooltipPos(e.clientX, e.clientY);
  }}

---

185-185: Clarify the purpose of the 100ms delay.

The setTimeout delay before setting isGlobeReady appears arbitrary. Document why this delay is necessary or consider using the globe's built-in ready state if available.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.