Skip to content

fix(hotkeys): prevent infinite loop in HotkeyHelpModal componentDidUpdate#4472

Merged
greg-in-a-box merged 1 commit intobox:masterfrom
patrickpaul:fix/hotkey-help-modal-infinite-loop
Mar 9, 2026
Merged

fix(hotkeys): prevent infinite loop in HotkeyHelpModal componentDidUpdate#4472
greg-in-a-box merged 1 commit intobox:masterfrom
patrickpaul:fix/hotkey-help-modal-infinite-loop

Conversation

@patrickpaul
Copy link
Collaborator

@patrickpaul patrickpaul commented Mar 9, 2026

Summary

  • Fixes an infinite componentDidUpdate loop in HotkeyHelpModal when the modal opens with no typed hotkeys registered
  • The guard condition !prevType was always true when prevType was already null, causing repeated setState({ currentType: null }) calls and triggering React's maximum update depth error
  • Adds a && this.types.length guard so setState is only called when there are types to select from

Root Cause

When HotkeyHelpModal is opened by a HotkeyLayer that has no hotkeys registered (e.g., in a Module Federation setup where the host and remote have separate box-ui-elements copies), getActiveTypes() returns an empty array. The existing code path:

if (!prevType) {
    this.setState({
        currentType: this.types.length ? this.types[0] : null,
    });
}

Sets currentType to null (since this.types is empty), which triggers another componentDidUpdate where prevType is still null, creating an infinite loop.

Fix

if (!prevType && this.types.length) {
    this.setState({
        currentType: this.types[0],
    });
}

Only call setState when there are actually types available. The render() method already returns null when currentType is falsy, so the modal correctly won't display.

Test Plan

  • Added unit test verifying setState is not called when no types are available
  • All existing tests pass (186 tests across 7 suites)

Summary by CodeRabbit

  • Bug Fixes

    • Fixed a potential issue in the hotkey help modal that could occur when no hotkey types are available.
  • Tests

    • Added test coverage for edge cases in the hotkey help modal to ensure stable behavior.

…date

When HotkeyHelpModal opens with no typed hotkeys registered,
componentDidUpdate repeatedly calls setState({ currentType: null })
because the guard condition `!prevType` is always true when prevType
is already null. This triggers React's maximum update depth error.

Skip the setState call entirely when there are no types available.
The render method already returns null when currentType is falsy,
so the modal correctly won't display.
@patrickpaul patrickpaul requested a review from a team as a code owner March 9, 2026 21:07
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Mar 9, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 025c0b0c-18ca-45c4-bdac-c55d5cbace92

📥 Commits

Reviewing files that changed from the base of the PR and between 161fde5 and 62037e5.

📒 Files selected for processing (2)
  • src/components/hotkeys/HotkeyHelpModal.js
  • src/components/hotkeys/__tests__/HotkeyHelpModal.test.js

Walkthrough

Refines the componentDidUpdate logic in HotkeyHelpModal to properly set currentType when hotkey types are available, and adds a test case verifying that opening the modal with no available types doesn't trigger unwanted state updates.

Changes

Cohort / File(s) Summary
HotkeyHelpModal Component & Tests
src/components/hotkeys/HotkeyHelpModal.js, src/components/hotkeys/__tests__/HotkeyHelpModal.test.js
Fixed componentDidUpdate logic to ensure currentType is set to the first type only when types exist and prevType is falsy, preventing null assignment. Added test case validating that setState is not called when opening the modal with no available hotkey types.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

  • PR #4382: Modifies HotkeyHelpModal's componentDidUpdate behavior for handling hotkey types and currentType assignment, directly related to this fix.

Suggested labels

ready-to-merge

Suggested reviewers

  • tjuanitas
  • jpan-box

Poem

🐰 A modal that clicked with care,
No more null types floating there,
When types are gone, we skip the dance,
A test ensures no second chance,
Logic refined, a rabbit's repair! ✨

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and specifically summarizes the main change: preventing an infinite loop in HotkeyHelpModal's componentDidUpdate method.
Description check ✅ Passed The description is comprehensive and well-structured, covering summary, root cause, fix, and test plan with code examples and verification of test results.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

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

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.


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.

@greg-in-a-box greg-in-a-box merged commit c471350 into box:master Mar 9, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants