refactor: use ID-based closing logic in CustomPortal for better reliabilit

[unsalgel]

What does this PR do?

• Improved the portal closing logic by using unique IDs instead of array indices. This prevents potential race conditions and incorrect element removals during asynchronous close operations in CustomPortal.tsx.

Did you test your code?

• Verified that portals still open and close correctly and handled race conditions locally.

Additional context

• Using indices to manage elements in a reactive store can lead to issues if elements are spliced/removed in asynchronous handlers. Moving to a unique ID-based system is much safer for state management.

Checklist

• Changes are clear, concise, and easy to review
• Code has been tested and works as intended

Summary by CodeRabbit

• Refactor
  • Improved portal management system with enhanced closing mechanism for more reliable operation.

[coderabbitai]

Warning

Rate limit exceeded

@unsalgel has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 55 minutes and 21 seconds before requesting another review.

To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 2b696218-1f3a-4673-89be-d3ce7daed65a

📥 Commits

Reviewing files that changed from the base of the PR and between e05f557 and b304b33.

📒 Files selected for processing (1)

• src/components/ui/custom-portal/CustomPortal.tsx

📝 Walkthrough

Walkthrough

The portal closing mechanism is refactored to use unique string identifiers instead of array indices. The closePortal method signature changes from accepting index: number to id: string. Portal creation ensures each portal receives a concrete ID, and closing logic consolidates into a single ID-based lookup function.

Changes

Cohort / File(s)	Summary
Portal API Refactoring src/components/ui/custom-portal/CustomPortal.tsx	Migrated from index-based to ID-based portal closing: closePortal now accepts id: string; createPortal assigns concrete IDs to all portals; provider logic consolidates closing operations into single ID-matched removal; PortalItem no longer uses index parameters.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 From numbers to strings, a cleaner way,
IDs guide portals through closing day,
No more index-hunting, the search is precise,
Each portal now named—oh, how very nice! ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ 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%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly summarizes the main change: refactoring portal closing logic from index-based to ID-based, which matches the core modifications in CustomPortal.tsx.
Description check	✅ Passed	The description covers all required sections from the template: it explains what the PR does, mentions testing verification, provides additional context about the rationale, and includes a completed checklist.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/components/ui/custom-portal/CustomPortal.tsx (1)

29-33: ⚠️ Potential issue | 🟠 Major

Update createPortal return type to string | undefined to match the new implementation.

The interface still declares createPortal: (...) => number | undefined, but the implementation now returns portalId (a string) on line 142. This is an inconsistent public API contract — TypeScript will likely flag this when the value object is provided to CustomPortalBaseContext.Provider, and any consumer that captures the return value will receive a misleading type.

🔧 Proposed fix

   createPortal: (
     element: (close: () => void) => JSX.Element,
     id?: string,
     toggle?: boolean
-  ) => number | undefined;
+  ) => string | undefined;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/ui/custom-portal/CustomPortal.tsx` around lines 29 - 33, The
declared return type for createPortal in the CustomPortal interface is incorrect
(number | undefined) while the implementation (returns portalId string) and the
value provided to CustomPortalBaseContext.Provider expect a string; update the
createPortal signature to return string | undefined to match the implementation
and ensure consumers get the correct type (refer to createPortal, portalId, and
CustomPortalBaseContext.Provider in CustomPortal.tsx).

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@src/components/ui/custom-portal/CustomPortal.tsx`:
- Around line 29-33: The declared return type for createPortal in the
CustomPortal interface is incorrect (number | undefined) while the
implementation (returns portalId string) and the value provided to
CustomPortalBaseContext.Provider expect a string; update the createPortal
signature to return string | undefined to match the implementation and ensure
consumers get the correct type (refer to createPortal, portalId, and
CustomPortalBaseContext.Provider in CustomPortal.tsx).

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 93b3fcde-4595-4f99-bc8d-470874ed5b90

📥 Commits

Reviewing files that changed from the base of the PR and between 7b3307a and e05f557.

📒 Files selected for processing (1)

• src/components/ui/custom-portal/CustomPortal.tsx

[SupertigerDev]

Has this caused any issues? And what happened?

[unsalgel]

I noticed a potential race condition in the portal management logic. Since portals can have asynchronous close handlers, using array indices for removal is risky. If multiple portals close or the array is modified while a handler is awaiting, the index can become stale, leading to the wrong portal being removed or state inconsistency.

I haven't encountered a specific breaking bug yet, but this refactor to unique IDs makes the system much more robust and prevents these kinds of logic errors from happening in the future, especially as the app handles more complex concurrent UI states

[SupertigerDev]

unfortunatly if theres currently no bugs with it, theres no point changing anything. if you can find any bugs,, then i could merge this