fix: Enhance overlay reducer state management

[ho991217]

Description

Related Issue: Fixes N/A

Changes

• Add checks to prevent unnecessary state updates for non-existent or already open/closed overlays
• Handle edge cases like closing all overlays when no overlays exist
• Defence logic moved into reducer, thus I removed isOpen === false clause from ContentOverlayController

Motivation and Context

How Has This Been Tested?

• Tested manually to ensure it works the same as before

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have performed a self-review of my own code.
• My code is commented, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• Any dependent changes have been merged and published in downstream modules.

Further Comments

[changeset-bot]

🦋 Changeset detected

Latest commit: 5073ef2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
overlay-kit	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
overlay-kit	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 18, 2025 3:38am

[codecov-commenter]

Codecov Report

❌ Patch coverage is 76.47059% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.86%. Comparing base (913d288) to head (5073ef2).
⚠️ Report is 56 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #120      +/-   ##
==========================================
- Coverage   96.72%   95.86%   -0.87%     
==========================================
  Files          12       12              
  Lines         275      290      +15     
  Branches       67       73       +6     
==========================================
+ Hits          266      278      +12     
- Misses          7       10       +3     
  Partials        2        2              

Components	Coverage Δ
overlay-kit	95.86% <76.47%> (-0.87%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jungpaeng]

When the following code is executed:

overlay.open(() => ..., { overlayId: 'A' });
overlay.open(() => ..., { overlayId: 'B' });
overlay.open(() => ..., { overlayId: 'C' });

The dispatch sequence proceeds as follows:

{ type: 'ADD', overlayId: 'A' }
{ type: 'ADD', overlayId: 'B' }
{ type: 'ADD', overlayId: 'C' }

{ type: 'OPEN', overlayId: 'A' }
{ type: 'OPEN', overlayId: 'B' }
{ type: 'OPEN', overlayId: 'C' }

During this process, the current value changes in the order of A -> B -> C -> A -> B -> C, which feels unnatural.

Was there a specific reason for updating the current value in the OPEN action?
If this approach is applied, it seems better to remove the current value update from the ADD action.

[ho991217]

Didn't realize dispatch of current overlay happens outside reducer. Removed at: f472720

[jungpaeng]

Could you add the changeset, please?