Skip to content

Conversation

@aronsuarez
Copy link

@aronsuarez aronsuarez commented Nov 18, 2025

Summary by CodeRabbit

  • New Features
    • Firestore database accessor now supports flexible configuration modes. Users can provide either a database string directly or pass an options object with optional application name and database parameters, enabling more granular control over database connections.

…tring

Allow useFirestore to accept a database string directly as a simpler alternative to the options object. The function now supports both calling patterns:
- useFirestore(databaseName)
- useFirestore({ name?, database? })

When passed a string, it uses the default Firebase app with the specified database. This provides a more convenient API for the common use case of specifying only a database name.
@coderabbitai
Copy link

coderabbitai bot commented Nov 18, 2025

Walkthrough

The changes add IDE metadata to version control exclusions and refactor the Firestore accessor function to support dual invocation modes: accepting either a database string directly or an options object with optional name and database parameters, with type-aware implementation routing.

Changes

Cohort / File(s) Summary
Configuration
.gitignore
Added .idea directory to ignore patterns for IDE-specific metadata
Firestore API Refactoring
src/firestore/index.ts
Reworked useFirestore with function overloads to support two invocation modes: useFirestore(database: string) and useFirestore(options: { name?: string; database?: string }). Implementation detects input type and routes to appropriate Firebase initialization path. Added Firestore type import for public API annotation.

Sequence Diagram(s)

sequenceDiagram
    autonumber
    
    participant Caller
    participant useFirestore
    participant TypeCheck as Type Detection
    participant Firebase as Firebase Init
    
    rect rgb(240, 248, 255)
    Note over Caller,Firebase: Invocation Mode 1: String
    Caller->>useFirestore: useFirestore("mydb")
    useFirestore->>TypeCheck: typeof string?
    TypeCheck-->>useFirestore: yes
    useFirestore->>Firebase: getFirestore(useFirebaseApp(), "mydb")
    Firebase-->>useFirestore: Firestore instance
    useFirestore-->>Caller: return Firestore
    end
    
    rect rgb(245, 245, 220)
    Note over Caller,Firebase: Invocation Mode 2: Options Object
    Caller->>useFirestore: useFirestore({ name: "app", database: "mydb" })
    useFirestore->>TypeCheck: typeof object?
    TypeCheck-->>useFirestore: yes, has database
    useFirestore->>Firebase: getFirestore(useFirebaseApp("app"), "mydb")
    Firebase-->>useFirestore: Firestore instance
    useFirestore-->>Caller: return Firestore
    end
    
    rect rgb(255, 250, 240)
    Note over Caller,Firebase: Invocation Mode 3: Name-only Options
    Caller->>useFirestore: useFirestore({ name: "app" })
    useFirestore->>TypeCheck: typeof object, no database?
    TypeCheck-->>useFirestore: yes
    useFirestore->>Firebase: getFirestore(useFirebaseApp("app"))
    Firebase-->>useFirestore: Firestore instance
    useFirestore-->>Caller: return Firestore
    end
Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

  • The .gitignore change is purely cosmetic with no logic impact.
  • The useFirestore refactoring is contained to a single function but involves careful validation of overload signatures and type-guarding logic to ensure all three invocation paths resolve correctly.
  • Pay special attention to: the overload order and resolution priority, the type-guarding conditions in the implementation, and backward compatibility with existing single-parameter calls.

Poem

🐰 With overloads stacked like carrots in a row,
useFirestore now has a dual-mode flow,
String or object, both paths align,
Firebase futures now more divine,
And .idea hides where IDEs dine! 🎉

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ 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 accurately describes the main change: adding the ability to select/specify the Firestore database through new function overloads and parameters.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 822a10c and 8be2d6c.

📒 Files selected for processing (2)
  • .gitignore (1 hunks)
  • src/firestore/index.ts (2 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
src/firestore/index.ts (2)
src/index.ts (2)
  • useFirestore (35-35)
  • useFirebaseApp (82-82)
src/app/index.ts (1)
  • useFirebaseApp (14-24)
🔇 Additional comments (2)
.gitignore (1)

15-15: Ignore of .idea directory is appropriate

Adding .idea to .gitignore is standard and avoids committing IDE metadata. No issues here.

src/firestore/index.ts (1)

1-7: Type‑only Firestore import looks good

Using type Firestore from firebase/firestore keeps this import erased at runtime and aligns with TS best practices. No issues from what’s visible here.

If you recently upgraded Firebase, please double‑check that the Firestore type is still exported from firebase/firestore in the specific version you target, as typings can move between major versions.(firebase.google.com)

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

  • Provide your own instructions using the high_level_summary_instructions setting.
  • Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
  • Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

  1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
  2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
  3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
  4. 📊 Contributor Summary — Include a Markdown table showing contributions:
    | Contributor | Lines Added | Lines Removed | Files Changed |
  5. ✔️ Additional Notes — Add any extra reviewer context.
    Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.


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.

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