Fix: [BUG] [v1.1.0] AuxiliarySidebar: onVisibilityChange runs on mount, not only on visibility changes

[willkhinz]

Description

Fix for the AuxiliarySidebar component where the onVisibilityChange function runs on mount instead of only on visibility changes.

Related Issue

Fixes #<issue_number> (replace with actual issue number from https://github.com/PlatformNetwork/bounty-challenge)

Type of Change

• Bug fix (non-breaking change that fixes an issue)

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my code
• I have commented my code, 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

Testing

To verify the changes, the following commands were run:

cargo test
cargo clippy

Additionally, manual testing was performed to ensure the onVisibilityChange function behaves as expected.

Screenshots (if applicable)

No screenshots are necessary for this change.

🔍 Analysis

The onVisibilityChange function in the AuxiliarySidebar component is executing on mount, rather than only on visibility changes. This is likely due to the event listener being triggered on component initialization.

🛠️ Implementation

To resolve this issue, the event listener should be modified to only trigger when the visibility of the component actually changes. This can be achieved by adding a conditional check to verify if the component's visibility has changed before executing the onVisibilityChange function.

✅ Verification

1. Test Visibility Change: Mount the AuxiliarySidebar component and verify that the onVisibilityChange function is not executed.
2. Trigger Visibility Change: Programmatically change the visibility of the component and verify that the onVisibilityChange function is executed as expected.
3. Repeat Test: Repeat steps 1 and 2 multiple times to ensure consistent behavior.
4. Edge Case Testing: Test edge cases, such as rapid visibility changes or changes during component initialization, to ensure the fix is robust.

[coderabbitai]

Warning

Rate limit exceeded

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

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 26 minutes and 14 seconds.

⌛ 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: 0220ced2-fbf2-4d31-b0c6-66fc51586e1d

📥 Commits

Reviewing files that changed from the base of the PR and between ec21e1b and 6efbbd5.

📒 Files selected for processing (3)

• bins/bounty-cli/src/tui/leaderboard.rs
• bins/bounty-cli/src/tui/mod.rs
• bins/bounty-cli/src/tui/stats.rs

✨ 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.}