refactor(DisplayTab): DisplayTab refactored into focused Settings sections#1126
refactor(DisplayTab): DisplayTab refactored into focused Settings sections#1126reachrazamair wants to merge 5 commits into
Conversation
📝 WalkthroughWalkthroughDisplayTab is rebuilt into reusable sections, hooks, helpers, and tests. The tab shell now composes the new sections and conditionally shows the Bionify info modal. A separate quota refresh hook change now stops after unmount. ChangesDisplay settings tab rebuild
Quota refresh unmount guard
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
Greptile SummaryThis PR splits the Display settings tab into smaller local modules. The main changes are:
Confidence Score: 5/5This looks safe to merge after checking the Display settings refactor.
Important Files Changed
Reviews (1): Last reviewed commit: "Refactor DisplayTab into focused section..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| @@ -0,0 +1,2 @@ | |||
| export { DisplayTab } from './DisplayTab'; | |||
There was a problem hiding this comment.
When a dev session already has ./tabs/DisplayTab loaded from the old DisplayTab.tsx file, replacing that path with a same-named directory can leave Vite's module graph pointing at the deleted file until a full page reload. The Display settings tab can fail to hot-reload during local development even though a fresh build resolves the new index.ts entry.
Context Used: CLAUDE.md (source)
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (3)
src/__tests__/renderer/components/Settings/tabs/DisplayTab/sections.test.tsx (1)
252-263: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueBrittle DOM/class-based selectors in TabOptions assertions.
These two assertions traverse via
.closest('.flex.items-center.justify-between')+querySelector('[role="switch"]'), coupling the test to Tailwind layout classes. The other rows in this file usegetByRole('switch', { name }). IfTabOptionsSectionexposesariaLabels for these toggles, prefer the role+name query for resilience.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/__tests__/renderer/components/Settings/tabs/DisplayTab/sections.test.tsx` around lines 252 - 263, The switch assertions in TabOptionsSection tests are using brittle Tailwind class traversal to find the toggles; update these two clicks to use role-based queries like the other rows in this test file. Locate the assertions around getByText for “Show starred tabs when filtering by unread” and “Show file preview tabs when filtering by unread” and, if TabOptionsSection provides accessible names/aria labels for those switches, replace the closest/querySelector path with getByRole('switch', { name: ... }) so the test no longer depends on layout classes.src/renderer/components/Settings/tabs/DisplayTab/components/TabOptionsSection.tsx (1)
3-31: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse the shared platform detection helper here.
This new section imports
isMacOSPlatform()fromutils/platformUtils, but the repo guideline for TS/TSX files requiresisMacOS()fromsrc/shared/platformDetection.tsso platform-specific UI copy stays on the shared path.As per coding guidelines,
**/*.{ts,tsx,js,jsx}: UseisWindows(),isMacOS(), orisLinux()fromsrc/shared/platformDetection.tsfor platform detection. Do not create duplicate implementations.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/renderer/components/Settings/tabs/DisplayTab/components/TabOptionsSection.tsx` around lines 3 - 31, The platform check in TabOptionsSection uses a non-shared helper, which violates the TS/TSX platform detection guideline. Update the import and usage in TabOptionsSection to use isMacOS() from src/shared/platformDetection.ts instead of isMacOSPlatform() from utils/platformUtils, keeping the shortcutPrefix logic the same.Source: Coding guidelines
src/renderer/components/Settings/tabs/DisplayTab/components/MaxLogBufferSection.tsx (1)
20-25: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winFormat the preset labels with
formatNumber().These values are user-visible labels, so rendering them as raw numbers leaves
1000/25000unformatted here. Please map them to{ value, label }options usingformatNumber()so this stays consistent with the rest of the app’s number formatting.As per coding guidelines, "Use
formatSize(),formatNumber(),formatTokens(),formatTokensCompact(),estimateTokenCount(),formatElapsedTime(),formatElapsedTimeColon(),formatRelativeTime(), orformatCost()fromsrc/shared/formatters.tsfor formatting operations. Do not create duplicate implementations."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/renderer/components/Settings/tabs/DisplayTab/components/MaxLogBufferSection.tsx` around lines 20 - 25, The preset values passed to ToggleButtonGroup in MaxLogBufferSection are being rendered as raw user-facing numbers, so update this to use { value, label } options instead of a plain numeric array. Map each preset through formatNumber() so the labels match the app’s standard number formatting, and keep the existing onChange behavior tied to setMaxLogBuffer.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@src/renderer/components/Settings/tabs/DisplayTab/components/AccessibilitySection.tsx`:
- Around line 98-167: The Bionify settings block is only visually/mouse-disabled
via `pointerEvents` and opacity, but the `ToggleButtonGroup` and
`bionify-algorithm-input` still remain keyboard-focusable. Update
`AccessibilitySection` so the controls are truly disabled when
`bionifyReadingMode` is false, using `disabled`, `tabIndex={-1}`, or `inert` as
appropriate. Apply this consistently to the intensity options and the algorithm
input, and keep the enabled state tied to the existing `bionifyReadingMode`
condition.
In
`@src/renderer/components/Settings/tabs/DisplayTab/components/ContextWarningsSection.tsx`:
- Around line 38-44: The threshold range inputs in ContextWarningsSection remain
keyboard-operable when contextWarningsEnabled is false because the wrapper only
uses opacity and pointerEvents. Update the two slider inputs in
ContextWarningsSection to also respect contextWarningsEnabled via the native
disabled attribute so they are removed from the tab order and cannot be adjusted
while the feature is off.
In
`@src/renderer/components/Settings/tabs/DisplayTab/components/DocumentGraphSection.tsx`:
- Around line 35-49: The range input in DocumentGraphSection lacks a
programmatic accessible name, so update the control rendered in the
DocumentGraphSection component to be labeled by the “Maximum nodes to display”
text. Add a proper label association using label/htmlFor with a matching id on
the input, or use aria-label/aria-labelledby directly on the input, keeping the
existing slider behavior unchanged.
In
`@src/renderer/components/Settings/tabs/DisplayTab/components/TabOptionsSection.tsx`:
- Around line 54-64: The switch’s aria-label is hardcoded to Command+0 while the
rendered shortcut text in TabOptionsSection depends on shortcutPrefix, so screen
readers can announce the wrong key combo on non-Mac platforms. Update the
ariaLabel on the same control to use the same shortcutPrefix-derived value used
in the title/description, so the accessible label always matches the displayed
shortcut.
In
`@src/renderer/components/Settings/tabs/DisplayTab/hooks/useBionifyAlgorithmState.ts`:
- Around line 15-17: The `algorithmDraft` state in `useBionifyAlgorithmState` is
only initialized once, so it can get out of sync when `bionifyAlgorithm` updates
after mount. Update the hook to keep `algorithmDraft` synchronized with the
incoming `bionifyAlgorithm` prop/state changes, using the existing
`setAlgorithmDraft` in a side effect keyed on `bionifyAlgorithm`, while
preserving the `DEFAULT_BIONIFY_ALGORITHM` fallback when the value is absent.
---
Nitpick comments:
In
`@src/__tests__/renderer/components/Settings/tabs/DisplayTab/sections.test.tsx`:
- Around line 252-263: The switch assertions in TabOptionsSection tests are
using brittle Tailwind class traversal to find the toggles; update these two
clicks to use role-based queries like the other rows in this test file. Locate
the assertions around getByText for “Show starred tabs when filtering by unread”
and “Show file preview tabs when filtering by unread” and, if TabOptionsSection
provides accessible names/aria labels for those switches, replace the
closest/querySelector path with getByRole('switch', { name: ... }) so the test
no longer depends on layout classes.
In
`@src/renderer/components/Settings/tabs/DisplayTab/components/MaxLogBufferSection.tsx`:
- Around line 20-25: The preset values passed to ToggleButtonGroup in
MaxLogBufferSection are being rendered as raw user-facing numbers, so update
this to use { value, label } options instead of a plain numeric array. Map each
preset through formatNumber() so the labels match the app’s standard number
formatting, and keep the existing onChange behavior tied to setMaxLogBuffer.
In
`@src/renderer/components/Settings/tabs/DisplayTab/components/TabOptionsSection.tsx`:
- Around line 3-31: The platform check in TabOptionsSection uses a non-shared
helper, which violates the TS/TSX platform detection guideline. Update the
import and usage in TabOptionsSection to use isMacOS() from
src/shared/platformDetection.ts instead of isMacOSPlatform() from
utils/platformUtils, keeping the shortcutPrefix logic the same.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 5098d151-1e7f-43c4-a073-ab84e3c4f191
📒 Files selected for processing (33)
src/__tests__/renderer/components/Settings/tabs/DisplayTab/hooks.test.tsxsrc/__tests__/renderer/components/Settings/tabs/DisplayTab/sections.test.tsxsrc/__tests__/renderer/components/Settings/tabs/DisplayTab/utils.test.tssrc/renderer/components/Settings/tabs/DisplayTab.tsxsrc/renderer/components/Settings/tabs/DisplayTab/DisplayTab.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/AccessibilitySection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/BionifyInfoModal.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/ContextWarningsSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/DocumentGraphSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/FileEditPreviewSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/FileIndexingSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/FontFamilySection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/FontSizeSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/IconThemeSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/LeftSidePanelSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/MainHeaderPanelSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/MaxLogBufferSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/MaxOutputLinesSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/MessageAlignmentSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/SectionCard.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/TabOptionsSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/ToggleSettingRow.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/WindowChromeSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/index.tssrc/renderer/components/Settings/tabs/DisplayTab/hooks/index.tssrc/renderer/components/Settings/tabs/DisplayTab/hooks/useBionifyAlgorithmState.tssrc/renderer/components/Settings/tabs/DisplayTab/hooks/useFontConfigurationState.tssrc/renderer/components/Settings/tabs/DisplayTab/index.tssrc/renderer/components/Settings/tabs/DisplayTab/types.tssrc/renderer/components/Settings/tabs/DisplayTab/utils/bionifyAlgorithm.tssrc/renderer/components/Settings/tabs/DisplayTab/utils/contextWarnings.tssrc/renderer/components/Settings/tabs/DisplayTab/utils/filePreviewToolbar.tssrc/renderer/components/Settings/tabs/DisplayTab/utils/index.ts
💤 Files with no reviewable changes (1)
- src/renderer/components/Settings/tabs/DisplayTab.tsx
There was a problem hiding this comment.
🧹 Nitpick comments (2)
src/__tests__/renderer/components/Settings/tabs/DisplayTab.test.tsx (1)
728-761: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDerive the preset labels with
formatNumber().These hardcoded
1.0K/5.0K/10.0K/25.0Kstrings duplicate the formatter output fromMaxLogBufferSection, so a formatter-only change will break this test without a behavior regression. As per coding guidelines, "UseformatSize(),formatNumber(),formatTokens(),formatTokensCompact(),estimateTokenCount(),formatElapsedTime(),formatElapsedTimeColon(),formatRelativeTime(), orformatCost()fromsrc/shared/formatters.tsfor formatting operations. Do not create duplicate implementations."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/__tests__/renderer/components/Settings/tabs/DisplayTab.test.tsx` around lines 728 - 761, The DisplayTab tests are hardcoding preset button labels that duplicate the formatting used by MaxLogBufferSection. Update these assertions to derive the expected labels with formatNumber() from src/shared/formatters.ts instead of literal strings, so the test tracks formatter changes without behavior changes. Use the existing DisplayTab test helpers and the MaxLogBufferSection preset expectations to locate the affected click assertions.Source: Coding guidelines
src/__tests__/renderer/components/SettingsModal.test.tsx (1)
937-946: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse
formatNumber()for the queried button names here too.This test now hardcodes presentation strings that are generated in the UI via
formatNumber(), so it will drift for formatting-only changes. As per coding guidelines, "UseformatSize(),formatNumber(),formatTokens(),formatTokensCompact(),estimateTokenCount(),formatElapsedTime(),formatElapsedTimeColon(),formatRelativeTime(), orformatCost()fromsrc/shared/formatters.tsfor formatting operations. Do not create duplicate implementations."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/__tests__/renderer/components/SettingsModal.test.tsx` around lines 937 - 946, The SettingsModal test is hardcoding button labels that should come from the same formatter used by the UI. Update the queries in SettingsModal.test.tsx to use formatNumber() for the expected button names instead of literal strings, so the test tracks the formatting logic used by the component and stays stable across presentation-only changes.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/__tests__/renderer/components/Settings/tabs/DisplayTab.test.tsx`:
- Around line 728-761: The DisplayTab tests are hardcoding preset button labels
that duplicate the formatting used by MaxLogBufferSection. Update these
assertions to derive the expected labels with formatNumber() from
src/shared/formatters.ts instead of literal strings, so the test tracks
formatter changes without behavior changes. Use the existing DisplayTab test
helpers and the MaxLogBufferSection preset expectations to locate the affected
click assertions.
In `@src/__tests__/renderer/components/SettingsModal.test.tsx`:
- Around line 937-946: The SettingsModal test is hardcoding button labels that
should come from the same formatter used by the UI. Update the queries in
SettingsModal.test.tsx to use formatNumber() for the expected button names
instead of literal strings, so the test tracks the formatting logic used by the
component and stays stable across presentation-only changes.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: c5c57173-e520-437d-807e-e64a51bfd3f8
📒 Files selected for processing (11)
src/__tests__/renderer/components/Settings/tabs/DisplayTab.test.tsxsrc/__tests__/renderer/components/Settings/tabs/DisplayTab/hooks.test.tsxsrc/__tests__/renderer/components/Settings/tabs/DisplayTab/sections.test.tsxsrc/__tests__/renderer/components/SettingsModal.test.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/AccessibilitySection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/ContextWarningsSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/DocumentGraphSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/MaxLogBufferSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/components/TabOptionsSection.tsxsrc/renderer/components/Settings/tabs/DisplayTab/hooks/useBionifyAlgorithmState.tssrc/renderer/components/ToggleButtonGroup.tsx
🚧 Files skipped from review as they are similar to previous changes (7)
- src/renderer/components/Settings/tabs/DisplayTab/components/DocumentGraphSection.tsx
- src/renderer/components/Settings/tabs/DisplayTab/components/MaxLogBufferSection.tsx
- src/renderer/components/Settings/tabs/DisplayTab/components/ContextWarningsSection.tsx
- src/renderer/components/Settings/tabs/DisplayTab/components/TabOptionsSection.tsx
- src/renderer/components/Settings/tabs/DisplayTab/hooks/useBionifyAlgorithmState.ts
- src/tests/renderer/components/Settings/tabs/DisplayTab/hooks.test.tsx
- src/renderer/components/Settings/tabs/DisplayTab/components/AccessibilitySection.tsx
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/renderer/components/UsageDashboard/quota/useQuotaRefresh.ts`:
- Around line 57-63: The mountedRef logic in useQuotaRefresh is only cleared on
cleanup, so it can stay false after React 18 StrictMode remounts and block
handleRefresh from running. Set mountedRef.current back to true at the start of
the useEffect body that defines the cleanup, while keeping the cleanup that
flips it to false, so the live instance is initialized correctly and visualBusy
can recover.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 40f8d6b0-9242-44cf-9a5d-982eda571183
📒 Files selected for processing (2)
src/__tests__/renderer/components/UsageDashboard/useQuotaRefresh.test.tsxsrc/renderer/components/UsageDashboard/quota/useQuotaRefresh.ts
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/__tests__/renderer/components/UsageDashboard/useQuotaRefresh.test.tsx`:
- Around line 42-74: The test in useQuotaRefresh should trigger the refresh
during the StrictMode mount cycle instead of calling handleRefresh after
renderHook returns. Update the useQuotaRefresh test to start the refresh from a
mount effect in the wrapper or keep the in-flight promise/timer across an
explicit unmount/remount so the StrictMode dev remount path is actually
exercised. Keep the assertions around result.current.isBusy and doRefresh, but
make sure the refresh begins before the initial mount cycle completes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: a426fcbe-bfbe-44a5-9692-cfe05d874070
📒 Files selected for processing (2)
src/__tests__/renderer/components/UsageDashboard/useQuotaRefresh.test.tsxsrc/renderer/components/UsageDashboard/quota/useQuotaRefresh.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- src/renderer/components/UsageDashboard/quota/useQuotaRefresh.ts
| it('recovers visual busy state after a StrictMode effect remount', async () => { | ||
| vi.useFakeTimers(); | ||
| const doRefresh = vi.fn().mockResolvedValue(undefined); | ||
| const wrapper = ({ children }: { children: ReactNode }) => <StrictMode>{children}</StrictMode>; | ||
|
|
||
| const { result } = renderHook( | ||
| () => | ||
| useQuotaRefresh({ | ||
| providerId: 'claude-code', | ||
| refreshing: false, | ||
| autoRefresh: false, | ||
| accountCount: 0, | ||
| snapshotCount: 0, | ||
| doRefresh, | ||
| }), | ||
| { wrapper } | ||
| ); | ||
|
|
||
| let refreshPromise!: Promise<void>; | ||
| act(() => { | ||
| refreshPromise = result.current.handleRefresh(); | ||
| }); | ||
| expect(result.current.isBusy).toBe(true); | ||
|
|
||
| await Promise.resolve(); | ||
| await act(async () => { | ||
| await vi.advanceTimersByTimeAsync(900); | ||
| await refreshPromise; | ||
| }); | ||
|
|
||
| expect(result.current.isBusy).toBe(false); | ||
| expect(doRefresh).toHaveBeenCalledTimes(1); | ||
| }); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major
🧩 Analysis chain
🌐 Web query:
In React 18 StrictMode, does the development-only mount → unmount → remount check happen during the initial render before test code can invoke callbacks returned from a hook rendered with @testing-library/react's renderHook?
💡 Result:
In React 18, when StrictMode is enabled, the development-only mount → unmount → remount sequence occurs synchronously during the initial render process [1][2][3]. When you use renderHook from @testing-library/react, this double-invocation behavior is triggered before your test code can interact with the results [4][5]. Specifically, React 18's StrictMode performs the following steps during the initial mount in development [1][2][3]: 1. React mounts the component/hook. 2. React simulates an unmount (destroying effects). 3. React simulates a remount (restoring the previous state and running effects again). Because this entire sequence happens as part of the initial render lifecycle triggered by renderHook, by the time the renderHook function returns the result object to your test, the hook has already been mounted, unmounted, and remounted [1][2][3]. This means that any side effects or callbacks initiated by your hook will have been executed twice (setup → cleanup → setup) [6][7]. If your test logic asserts on the number of times an effect has run, it will observe the effect running twice on the initial mount [4]. Consequently, you should write your tests to account for this double-execution, typically by resetting mocks or verifying state after the mount cycle is complete [4].
Citations:
- 1: https://react.dev/blog/2022/03/08/react-18-upgrade-guide
- 2: https://legacy.reactjs.org/docs/strict-mode.html
- 3: https://legacy.reactjs.org/blog/2022/03/29/react-v18.html
- 4: Testing with Reusable State with StrictMode reactwg/react-18#17
- 5: https://deepwiki.com/testing-library/react-testing-library/2.2-renderhook-api
- 6: https://react.dev/reference/react/StrictMode
- 7: https://uk.react.dev/reference/react/StrictMode
Move the refresh trigger into the StrictMode mount cycle. This test calls handleRefresh() after renderHook() returns, so React’s dev-only mount → unmount → remount pass has already completed. It only covers a normal refresh on the remounted instance, not the regression this PR targets. Start the refresh from a mount effect or keep the promise/timer in flight across an explicit unmount/remount.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/__tests__/renderer/components/UsageDashboard/useQuotaRefresh.test.tsx`
around lines 42 - 74, The test in useQuotaRefresh should trigger the refresh
during the StrictMode mount cycle instead of calling handleRefresh after
renderHook returns. Update the useQuotaRefresh test to start the refresh from a
mount effect in the wrapper or keep the in-flight promise/timer across an
explicit unmount/remount so the StrictMode dev remount path is actually
exercised. Keep the assertions around result.current.isBusy and doRefresh, but
make sure the refresh begins before the initial mount cycle completes.
1 participant
Summary
DisplayTabfrom one 1,686-line component into a directory module with a 173-line shell../DisplayTabpublic import path.data-setting-idwrappers aligned withsearchableSettings.ts.Details
ToggleSwitchToggleButtonGroupSettingsSectionHeadingFontConfigurationPanelIgnorePatternsSectionFilePanelSettingsSectionSettingsModal, settings store, IPC/preload APIs, other Settings tabs,searchableSettings.ts, anddocs/releases.mdunchanged.Tests
hooks.test.tsxsections.test.tsxutils.test.tsVerification
npm run test -- src/__tests__/renderer/components/Settings/tabs/DisplayTab.test.tsx src/__tests__/renderer/components/Settings/tabs/DisplayTab src/__tests__/renderer/components/Settings/searchableSettings.test.tsnpm run test -- src/__tests__/renderer/components/Settings/tabs/GeneralTab.test.tsx src/__tests__/renderer/components/Settings/tabs/GeneralTab src/__tests__/renderer/components/Settings/tabs/EncoreTab.test.tsxnpm run format:checknpm run lintnpm run lint:eslintnpx tsc --noEmit --prettynpm run testManual QA
Summary by CodeRabbit