Skip to content

Comments

refactor: Replace provider === 'google' with isGoogleProvider helper#1250

Merged
elie222 merged 1 commit intomainfrom
refactor/use-isGoogleProvider-helper
Jan 11, 2026
Merged

refactor: Replace provider === 'google' with isGoogleProvider helper#1250
elie222 merged 1 commit intomainfrom
refactor/use-isGoogleProvider-helper

Conversation

@elie222
Copy link
Owner

@elie222 elie222 commented Jan 11, 2026

User description

Replace all direct comparisons of provider === 'google' with the isGoogleProvider helper function for consistency and maintainability.

  • Updated 7 files to use isGoogleProvider(provider) instead of direct comparison
  • Added imports for isGoogleProvider where needed
  • Improves code consistency and makes provider checks easier to maintain

Generated description

Below is a concise technical summary of the changes proposed in this PR:

graph LR
AddAccount_("AddAccount"):::modified
handleAddAccount_("handleAddAccount"):::modified
getAccountLinkingUrl_("getAccountLinkingUrl"):::modified
PROVIDER_TYPES_("PROVIDER_TYPES"):::modified
getUnifiedCalendarAvailability_("getUnifiedCalendarAvailability"):::modified
createCalendarEventProviders_("createCalendarEventProviders"):::modified
SignatureSectionForm_("SignatureSectionForm"):::modified
SignatureDialog_("SignatureDialog"):::modified
AddAccount_ -- "Uses isGoogleProvider to choose correct loading setter." --> handleAddAccount_
handleAddAccount_ -- "Now reports provider via isGoogleProvider-based error titles." --> getAccountLinkingUrl_
handleAddAccount_ -- "Switches to centralized isGoogleProvider detection for decisions." --> PROVIDER_TYPES_
getAccountLinkingUrl_ -- "Error messages now use isGoogleProvider for provider identification." --> PROVIDER_TYPES_
getUnifiedCalendarAvailability_ -- "Groups Google connections using isGoogleProvider instead of string equality." --> PROVIDER_TYPES_
createCalendarEventProviders_ -- "Selects Google event provider via isGoogleProvider check." --> PROVIDER_TYPES_
SignatureSectionForm_ -- "Determines Gmail via isGoogleProvider for signature UI logic." --> PROVIDER_TYPES_
SignatureDialog_ -- "Uses isGoogleProvider to identify Gmail for signature dialog." --> PROVIDER_TYPES_
classDef added stroke:#15AA7A
classDef removed stroke:#CD5270
classDef modified stroke:#EDAC4C
linkStyle default stroke:#CBD5E1,font-size:13px
Loading

Standardizes provider identification by replacing direct string comparisons with the isGoogleProvider helper function, enhancing consistency and maintainability across email account management, signature settings, and calendar integration components. Improves code readability and future extensibility by centralizing how the system identifies Google-specific logic.

Latest Contributors(1)
UserCommitDate
elie222feat-add-getActionErro...January 08, 2026
This pull request is reviewed by Baz. Review like a pro on (Baz).

Summary by CodeRabbit

  • Refactor
    • Centralized provider type detection logic across multiple components and utilities to improve code consistency and maintainability throughout the email and calendar functionality.

✏️ Tip: You can customize this high-level summary in your review settings.

Replace all direct comparisons of provider === 'google' with the isGoogleProvider helper function for consistency and maintainability.

- Updated 8 files to use isGoogleProvider(provider) instead of direct comparison
- Added imports for isGoogleProvider where needed
- Improves code consistency and makes provider checks easier to maintain
@vercel
Copy link

vercel bot commented Jan 11, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Review Updated (UTC)
inbox-zero Building Building Preview Jan 11, 2026 5:59pm

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jan 11, 2026

📝 Walkthrough

Walkthrough

This PR replaces hardcoded provider string comparisons (provider === "google") with a centralized isGoogleProvider() helper function across multiple utility and component files to standardize provider type checking throughout the codebase.

Changes

Cohort / File(s) Change Summary
Test & Helper Functions
apps/web/__tests__/helpers.ts
Updated getCalendarConnection to use isGoogleProvider() instead of direct provider comparison for determining email domain.
UI Components (Signature Settings)
apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx, apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
Replaced direct Gmail provider checks with isGoogleProvider() helper for conditional UI text and behavior in signature-related components.
Account Management
apps/web/app/(app)/accounts/AddAccount.tsx, apps/web/utils/account-linking.ts
Updated provider type checks to use isGoogleProvider() in loading state logic and error message formatting.
Calendar Utilities
apps/web/utils/calendar/event-provider.ts, apps/web/utils/calendar/unified-availability.ts
Refactored provider instantiation and filtering logic to use isGoogleProvider() for centralized Google provider detection.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

  • Move folder action improvements #683 — Both PRs centralize provider string checks by introducing/using provider-type predicates to replace direct "google" comparisons across the codebase.
  • Add Outlook Cold Email support #603 — Both PRs work with the same provider abstraction surface by generalizing provider-specific logic through utilities and helper functions.

Suggested reviewers

  • baz-reviewer
  • anakarentorosserrano-star

Poem

🐰 A rabbit hops through provider checks with glee,
No more "google" strings scattered wild and free,
isGoogleProvider() now leads the way,
Centralized and clean—refactoring day! 🎉

🚥 Pre-merge checks | ✅ 2 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 42.86% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and concisely summarizes the main refactoring change: replacing direct provider comparisons with a centralized helper function across multiple files.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@cubic-dev-ai cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 7 files

@elie222 elie222 merged commit b4f2351 into main Jan 11, 2026
13 of 15 checks passed
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In @apps/web/app/(app)/accounts/AddAccount.tsx:
- Line 9: Remove the console.error calls in the AddAccount component
error-handling block (the lines referenced around 15-31) and rely on the
existing toast failure UI; delete any console.error(...) statements and do not
replace them with console logging — if persistent telemetry is required, use the
project logger or error-tracking utility instead (e.g., processLogger.error or
Sentry) rather than console.error.
🧹 Nitpick comments (1)
apps/web/utils/calendar/unified-availability.ts (1)

65-70: Consider centralizing Microsoft provider checks too (for symmetry) (Line 65-70).
Right now Google uses isGoogleProvider(...) but Microsoft is still === "microsoft". If you have (or plan to add) isMicrosoftProvider, using it here would keep the pattern consistent and avoid scattering literals.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f5a24e8 and 922b440.

📒 Files selected for processing (7)
  • apps/web/__tests__/helpers.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/utils/account-linking.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/utils/calendar/unified-availability.ts
🧰 Additional context used
📓 Path-based instructions (23)
**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/data-fetching.mdc)

**/*.{ts,tsx}: For API GET requests to server, use the swr package
Use result?.serverError with toastError from @/components/Toast for error handling in async operations

**/*.{ts,tsx}: Use wrapper functions for Gmail message operations (get, list, batch, etc.) from @/utils/gmail/message.ts instead of direct API calls
Use wrapper functions for Gmail thread operations from @/utils/gmail/thread.ts instead of direct API calls
Use wrapper functions for Gmail label operations from @/utils/gmail/label.ts instead of direct API calls

**/*.{ts,tsx}: Don't use primitive type aliases or misleading types
Don't use empty type parameters in type aliases and interfaces
Don't use this and super in static contexts
Don't use any or unknown as type constraints
Don't use the TypeScript directive @ts-ignore
Don't use TypeScript enums
Don't export imported variables
Don't add type annotations to variables, parameters, and class properties that are initialized with literal expressions
Don't use TypeScript namespaces
Don't use non-null assertions with the ! postfix operator
Don't use parameter properties in class constructors
Don't use user-defined types
Use as const instead of literal types and type annotations
Use either T[] or Array<T> consistently
Initialize each enum member value explicitly
Use export type for types
Use import type for types
Make sure all enum members are literal values
Don't use TypeScript const enum
Don't declare empty interfaces
Don't let variables evolve into any type through reassignments
Don't use the any type
Don't misuse the non-null assertion operator (!) in TypeScript files
Don't use implicit any type on variable declarations
Don't merge interfaces and classes unsafely
Don't use overload signatures that aren't next to each other
Use the namespace keyword instead of the module keyword to declare TypeScript namespaces
Use consistent accessibility modifiers on class properties and methods
Use function types instead of object types wit...

Files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (.cursor/rules/prisma-enum-imports.mdc)

Always import Prisma enums from @/generated/prisma/enums instead of @/generated/prisma/client to avoid Next.js bundling errors in client components

Import Prisma using the project's centralized utility: import prisma from '@/utils/prisma'

Files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
apps/web/**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/project-structure.mdc)

Import specific lodash functions rather than entire lodash library to minimize bundle size (e.g., import groupBy from 'lodash/groupBy')

apps/web/**/*.{ts,tsx}: Use TypeScript with strict null checks
Do not export types/interfaces that are only used within the same file. Export later if needed
Infer types from Zod schemas using z.infer<typeof schema> instead of duplicating as separate interfaces

Files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
**/*.ts

📄 CodeRabbit inference engine (.cursor/rules/security.mdc)

**/*.ts: ALL database queries MUST be scoped to the authenticated user/account by including user/account filtering in WHERE clauses to prevent unauthorized data access
Always validate that resources belong to the authenticated user before performing operations, using ownership checks in WHERE clauses or relationships
Always validate all input parameters for type, format, and length before using them in database queries
Use SafeError for error responses to prevent information disclosure. Generic error messages should not reveal internal IDs, logic, or resource ownership details
Only return necessary fields in API responses using Prisma's select option. Never expose sensitive data such as password hashes, private keys, or system flags
Prevent Insecure Direct Object References (IDOR) by validating resource ownership before operations. All findUnique/findFirst calls MUST include ownership filters
Prevent mass assignment vulnerabilities by explicitly whitelisting allowed fields in update operations instead of accepting all user-provided data
Prevent privilege escalation by never allowing users to modify system fields, ownership fields, or admin-only attributes through user input
All findMany queries MUST be scoped to the user's data by including appropriate WHERE filters to prevent returning data from other users
Use Prisma relationships for access control by leveraging nested where clauses (e.g., emailAccount: { id: emailAccountId }) to validate ownership

Files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
**/*.{tsx,ts}

📄 CodeRabbit inference engine (.cursor/rules/ui-components.mdc)

**/*.{tsx,ts}: Use Shadcn UI and Tailwind for components and styling
Use next/image package for images
For API GET requests to server, use the swr package with hooks like useSWR to fetch data
For text inputs, use the Input component with registerProps for form integration and error handling

Files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
**/*.{tsx,ts,css}

📄 CodeRabbit inference engine (.cursor/rules/ui-components.mdc)

Implement responsive design with Tailwind CSS using a mobile-first approach

Files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
**/*.{js,jsx,ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)

**/*.{js,jsx,ts,tsx}: Don't use accessKey attribute on any HTML element
Don't set aria-hidden="true" on focusable elements
Don't add ARIA roles, states, and properties to elements that don't support them
Don't use distracting elements like <marquee> or <blink>
Only use the scope prop on <th> elements
Don't assign non-interactive ARIA roles to interactive HTML elements
Make sure label elements have text content and are associated with an input
Don't assign interactive ARIA roles to non-interactive HTML elements
Don't assign tabIndex to non-interactive HTML elements
Don't use positive integers for tabIndex property
Don't include "image", "picture", or "photo" in img alt prop
Don't use explicit role property that's the same as the implicit/default role
Make static elements with click handlers use a valid role attribute
Always include a title element for SVG elements
Give all elements requiring alt text meaningful information for screen readers
Make sure anchors have content that's accessible to screen readers
Assign tabIndex to non-interactive HTML elements with aria-activedescendant
Include all required ARIA attributes for elements with ARIA roles
Make sure ARIA properties are valid for the element's supported roles
Always include a type attribute for button elements
Make elements with interactive roles and handlers focusable
Give heading elements content that's accessible to screen readers (not hidden with aria-hidden)
Always include a lang attribute on the html element
Always include a title attribute for iframe elements
Accompany onClick with at least one of: onKeyUp, onKeyDown, or onKeyPress
Accompany onMouseOver/onMouseOut with onFocus/onBlur
Include caption tracks for audio and video elements
Use semantic elements instead of role attributes in JSX
Make sure all anchors are valid and navigable
Ensure all ARIA properties (aria-*) are valid
Use valid, non-abstract ARIA roles for elements with ARIA roles
Use valid AR...

Files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
!(pages/_document).{jsx,tsx}

📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)

Don't use the next/head module in pages/_document.js on Next.js projects

Files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
**/*.{js,ts,jsx,tsx}

📄 CodeRabbit inference engine (.cursor/rules/utilities.mdc)

**/*.{js,ts,jsx,tsx}: Use lodash utilities for common operations (arrays, objects, strings)
Import specific lodash functions to minimize bundle size (e.g., import groupBy from 'lodash/groupBy')

**/*.{js,ts,jsx,tsx}: Add helper functions to the bottom of files, not the top!
All imports go at the top of files, no mid-file dynamic imports.

Files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
**/{utils,helpers,lib}/**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/logging.mdc)

Logger should be passed as a parameter to helper functions instead of creating their own logger instances

Files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/utils/account-linking.ts
apps/web/**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

apps/web/**/*.{ts,tsx,js,jsx}: Use @/ path aliases for imports from project root
Use proper error handling with try/catch blocks
Prefer self-documenting code over comments; use descriptive variable and function names instead of explaining intent with comments. Never add comments that just describe what the code does. Only add comments for 'why' not 'what'
Add helper functions to the bottom of files, not the top
All imports go at the top of files, no mid-file dynamic imports
Use getActionErrorMessage(error.error) from @/utils/error to extract user-friendly error messages

Files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
apps/web/**/*.{ts,tsx,css}

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

Follow tailwindcss patterns with prettier-plugin-tailwindcss

Files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
apps/web/**/*.{ts,tsx,js,jsx,json}

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

Client-side environment variables must be prefixed with NEXT_PUBLIC_

Files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
**/*.{js,ts,jsx,tsx,py,java,cs,rb,go,php,rs,kt,swift,m}

📄 CodeRabbit inference engine (.cursor/rules/notes.mdc)

Prefer self-documenting code over comments; use descriptive variable and function names instead of explaining intent with comments. Never add comments that just describe what the code does - code should explain itself. Only add comments for 'why' not 'what'.

Files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
apps/web/app/(app)/**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/page-structure.mdc)

apps/web/app/(app)/**/*.{ts,tsx}: Components for the page are either put in page.tsx, or in the apps/web/app/(app)/PAGE_NAME folder
If we're in a deeply nested component we will use swr to fetch via API
If you need to use onClick in a component, that component is a client component and file must start with use client

Files:

  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
**/*.tsx

📄 CodeRabbit inference engine (.cursor/rules/ui-components.mdc)

**/*.tsx: Use the LoadingContent component to handle loading states instead of manual loading state management
For text areas, use the Input component with type='text', autosizeTextarea prop set to true, and registerProps for form integration

Files:

  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
**/*.{jsx,tsx}

📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)

**/*.{jsx,tsx}: Don't use unnecessary fragments
Don't pass children as props
Don't use the return value of React.render
Make sure all dependencies are correctly specified in React hooks
Make sure all React hooks are called from the top level of component functions
Don't forget key props in iterators and collection literals
Don't define React components inside other components
Don't use event handlers on non-interactive elements
Don't assign to React component props
Don't use both children and dangerouslySetInnerHTML props on the same element
Don't use dangerous JSX props
Don't use Array index in keys
Don't insert comments as text nodes
Don't assign JSX properties multiple times
Don't add extra closing tags for components without children
Use <>...</> instead of <Fragment>...</Fragment>
Watch out for possible "wrong" semicolons inside JSX elements
Make sure void (self-closing) elements don't have children
Don't use target="_blank" without rel="noopener"
Don't use <img> elements in Next.js projects
Don't use <head> elements in Next.js projects

Files:

  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
apps/web/**/*.{tsx,jsx}

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

apps/web/**/*.{tsx,jsx}: Prefer functional components with hooks
Use shadcn/ui components when available
Follow consistent naming conventions (PascalCase for components)
Use LoadingContent component for async data with loading and error states
Use React Hook Form with Zod validation for form handling
Use useAction hook from next-safe-action/hooks with onSuccess and onError callbacks for form submission
Use LoadingContent component to handle loading and error states consistently
Call mutate() after successful mutations to refresh SWR data

Files:

  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
apps/web/**/*.{tsx,jsx,css}

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

Ensure responsive design with mobile-first approach

Files:

  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
**/*Form.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/form-handling.mdc)

**/*Form.{ts,tsx}: Use React Hook Form with Zod for validation in form components
Validate form inputs before submission
Show validation errors inline next to form fields

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
apps/web/{utils/ai,utils/llms,__tests__}/**/*.ts

📄 CodeRabbit inference engine (.cursor/rules/llm.mdc)

LLM-related code must be organized in specific directories: apps/web/utils/ai/ for main implementations, apps/web/utils/llms/ for core utilities and configurations, and apps/web/__tests__/ for LLM-specific tests

Files:

  • apps/web/__tests__/helpers.ts
**/{scripts,tests,__tests__}/**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/logging.mdc)

Use createScopedLogger only for code that doesn't run within a middleware chain, such as standalone scripts or tests

Files:

  • apps/web/__tests__/helpers.ts
**/__tests__/**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/testing.mdc)

Place AI tests in the __tests__ directory and do not run them by default as they use a real LLM

Files:

  • apps/web/__tests__/helpers.ts
🧠 Learnings (25)
📓 Common learnings
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to apps/web/utils/gmail/**/*.{ts,tsx} : Always use wrapper functions from @/utils/gmail/ for Gmail API operations instead of direct provider API calls
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to apps/web/utils/gmail/**/*.{ts,tsx} : Keep Gmail provider-specific implementation details isolated within the apps/web/utils/gmail/ directory
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Design Gmail wrapper functions to be provider-agnostic to support future email providers like Outlook and ProtonMail
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to apps/web/utils/gmail/**/*.{ts,tsx} : Keep Gmail provider-specific implementation details isolated within the apps/web/utils/gmail/ directory

Applied to files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to apps/web/utils/gmail/**/*.{ts,tsx} : Always use wrapper functions from @/utils/gmail/ for Gmail API operations instead of direct provider API calls

Applied to files:

  • apps/web/utils/calendar/unified-availability.ts
  • apps/web/utils/calendar/event-provider.ts
  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Design Gmail wrapper functions to be provider-agnostic to support future email providers like Outlook and ProtonMail

Applied to files:

  • apps/web/utils/calendar/event-provider.ts
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
📚 Learning: 2025-07-08T13:14:07.449Z
Learnt from: elie222
Repo: elie222/inbox-zero PR: 537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.

Applied to files:

  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
📚 Learning: 2025-11-25T14:37:56.430Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/llm-test.mdc:0-0
Timestamp: 2025-11-25T14:37:56.430Z
Learning: Applies to apps/web/__tests__/**/*.test.ts : Prefer using existing helpers from `@/__tests__/helpers.ts` (`getEmailAccount`, `getEmail`, `getRule`, `getMockMessage`, `getMockExecutedRule`) instead of creating custom test data helpers

Applied to files:

  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to **/*.{ts,tsx} : Use wrapper functions for Gmail label operations from @/utils/gmail/label.ts instead of direct API calls

Applied to files:

  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
📚 Learning: 2025-11-25T14:36:36.276Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-11-25T14:36:36.276Z
Learning: Applies to **/*.{ts,tsx} : Import error and success toast utilities from '@/components/Toast' for displaying notifications

Applied to files:

  • apps/web/app/(app)/accounts/AddAccount.tsx
📚 Learning: 2026-01-08T15:09:06.736Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/fullstack-workflow.mdc:0-0
Timestamp: 2026-01-08T15:09:06.736Z
Learning: Applies to apps/web/app/api/**/*.ts : Use `withAuth` middleware for user-level API operations and `withEmailAccount` middleware for email-account-level operations

Applied to files:

  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/__tests__/helpers.ts
📚 Learning: 2025-11-25T14:38:07.606Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/llm.mdc:0-0
Timestamp: 2025-11-25T14:38:07.606Z
Learning: Applies to apps/web/utils/ai/**/*.ts : LLM feature functions must import from `zod` for schema validation, use `createScopedLogger` from `@/utils/logger`, `chatCompletionObject` and `createGenerateObject` from `@/utils/llms`, and import `EmailAccountWithAI` type from `@/utils/llms/types`

Applied to files:

  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to **/*.{ts,tsx} : Use wrapper functions for Gmail thread operations from @/utils/gmail/thread.ts instead of direct API calls

Applied to files:

  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
📚 Learning: 2026-01-07T21:07:06.691Z
Learnt from: elie222
Repo: elie222/inbox-zero PR: 1230
File: apps/web/app/(app)/[emailAccountId]/drive/page.tsx:47-70
Timestamp: 2026-01-07T21:07:06.691Z
Learning: In TSX files across the codebase, prefer direct server action calls with manual error handling (e.g., check result?.serverError and handle errors explicitly). The useAction hook pattern is not required; you can call server actions directly and use try/finally to ensure cleanup (such as resetting loading states) regardless of the hook. Apply consistently for components that perform server interactions.

Applied to files:

  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
📚 Learning: 2026-01-09T17:27:19.225Z
Learnt from: elie222
Repo: elie222/inbox-zero PR: 1234
File: apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx:65-83
Timestamp: 2026-01-09T17:27:19.225Z
Learning: In the elie222/inbox-zero repo, for React components using next-safe-action, using optimistic updates with mutate on success/error is an accepted approach to address race conditions in toggle handlers. It is acceptable for components not to guard rapid toggles with isExecuting (disable) when the optimistic UI state is reconciled by mutate. Apply this guidance to similar TSX components in the web app where appropriate.

Applied to files:

  • apps/web/app/(app)/accounts/AddAccount.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to **/*.{ts,tsx} : Use wrapper functions for Gmail message operations (get, list, batch, etc.) from @/utils/gmail/message.ts instead of direct API calls

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
  • apps/web/utils/account-linking.ts
  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to **/{pages,routes,components}/**/*.{ts,tsx} : Never call Gmail API directly from routes or components - always use wrapper functions from the utils folder

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
📚 Learning: 2026-01-01T10:42:29.775Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2026-01-01T10:42:29.775Z
Learning: Applies to **/*.test.{ts,tsx} : Use test helper functions `getEmail`, `getEmailAccount`, and `getRule` from `@/__tests__/helpers` for creating mock data

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
📚 Learning: 2026-01-08T15:09:06.736Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/fullstack-workflow.mdc:0-0
Timestamp: 2026-01-08T15:09:06.736Z
Learning: Applies to apps/web/components/**/*.tsx : Use React Hook Form with `zodResolver` for form validation, combining it with `useAction` hook from `next-safe-action/hooks` for server action execution

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
📚 Learning: 2025-11-25T14:36:51.389Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/form-handling.mdc:0-0
Timestamp: 2025-11-25T14:36:51.389Z
Learning: Applies to **/*Form.{ts,tsx} : Validate form inputs before submission using React Hook Form and Zod resolver

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
📚 Learning: 2026-01-09T21:51:15.182Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2026-01-09T21:51:15.182Z
Learning: Applies to apps/web/**/*.{tsx,jsx} : Use React Hook Form with Zod validation for form handling

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
📚 Learning: 2025-11-25T14:36:51.389Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/form-handling.mdc:0-0
Timestamp: 2025-11-25T14:36:51.389Z
Learning: Applies to **/*Form.{ts,tsx} : Use React Hook Form with Zod for form validation

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
📚 Learning: 2025-11-25T14:36:53.147Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/form-handling.mdc:0-0
Timestamp: 2025-11-25T14:36:53.147Z
Learning: Applies to **/*Form.{ts,tsx} : Use React Hook Form with Zod for validation in form components

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
📚 Learning: 2025-11-25T14:39:49.448Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/server-actions.mdc:0-0
Timestamp: 2025-11-25T14:39:49.448Z
Learning: Applies to apps/web/utils/actions/*.ts : Use `actionClient` when both authenticated user context and a specific emailAccountId are needed, with emailAccountId bound when calling from the client

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx
  • apps/web/__tests__/helpers.ts
📚 Learning: 2025-11-25T14:39:23.326Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-11-25T14:39:23.326Z
Learning: Applies to app/api/**/*.ts : Use `withEmailAccount` middleware for operations scoped to a specific email account (reading/writing emails, rules, schedules, etc.) - provides `emailAccountId`, `userId`, and `email` in `request.auth`

Applied to files:

  • apps/web/__tests__/helpers.ts
📚 Learning: 2025-11-25T14:39:27.909Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-11-25T14:39:27.909Z
Learning: Applies to **/app/api/**/*.ts : Use `withEmailAccount` middleware for operations scoped to a specific email account, including reading/writing emails, rules, schedules, or any operation using `emailAccountId`

Applied to files:

  • apps/web/__tests__/helpers.ts
📚 Learning: 2025-11-25T14:40:13.649Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/ui-components.mdc:0-0
Timestamp: 2025-11-25T14:40:13.649Z
Learning: Applies to **/*.{tsx,ts,jsx,js} : For text inputs in forms, use the `Input` component with `type='email'`, `name`, `label`, `registerProps` from react-hook-form, and `error` props

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
  • GitHub Check: Baz Reviewer
  • GitHub Check: Analyze (javascript-typescript)
  • GitHub Check: test
🔇 Additional comments (6)
apps/web/utils/calendar/unified-availability.ts (1)

8-8: Good centralization of Google provider detection (Line 8).
This import aligns with the PR objective and improves maintainability.

apps/web/__tests__/helpers.ts (1)

5-5: Nice: tests now follow the same provider predicate as prod (Line 5, Line 287-288).
This should reduce “string literal drift” between helpers and app code.

Also applies to: 287-288

apps/web/app/(app)/[emailAccountId]/settings/SignatureSectionForm.tsx (1)

23-23: Provider check refactor looks good; verify null-safety of provider (Line 23, Line 39-41).
If provider can ever be missing during initial render/loading, make sure isGoogleProvider handles that safely (or guard before calling).

Also applies to: 39-41

apps/web/utils/calendar/event-provider.ts (1)

6-6: LGTM; verify isGoogleProvider matches stored provider values (Line 6, Line 40-55).
This is a clean swap; just ensure the helper’s accepted values align with calendarConnection.provider values in Prisma/DB.

Also applies to: 40-55

apps/web/utils/account-linking.ts (1)

3-3: Consistent provider naming in errors (Line 3, Line 20-24).
This keeps “Google vs Microsoft” rendering aligned with the central predicate.

Also applies to: 20-24

apps/web/app/(app)/[emailAccountId]/assistant/settings/PersonalSignatureSetting.tsx (1)

33-33: LGTM; same null-safety check for provider (Line 33, Line 69-76).
Centralizing the check is good—just confirm provider can’t be undefined here (or that isGoogleProvider handles it).

Also applies to: 69-76

import Image from "next/image";
import { TypographyP } from "@/components/Typography";
import { getAccountLinkingUrl } from "@/utils/account-linking";
import { isGoogleProvider } from "@/utils/email/provider-types";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Good refactor; remove console.error per repo guidelines (Line 9, Line 15-31).
You’re already toasting the failure; logging via console looks out-of-policy here.

Proposed diff
 } catch (error) {
-  console.error(`Error initiating ${provider} link:`, error);
   toastError({
     title: `Error initiating ${isGoogleProvider(provider) ? "Google" : "Microsoft"} link`,
     description: "Please try again or contact support",
   });
   setLoading(false);
 }

Also applies to: 15-31

🤖 Prompt for AI Agents
In @apps/web/app/(app)/accounts/AddAccount.tsx at line 9, Remove the
console.error calls in the AddAccount component error-handling block (the lines
referenced around 15-31) and rely on the existing toast failure UI; delete any
console.error(...) statements and do not replace them with console logging — if
persistent telemetry is required, use the project logger or error-tracking
utility instead (e.g., processLogger.error or Sentry) rather than console.error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant