🤖 refactor: move settings from modal to route page (/settings/:section)#2361
🤖 refactor: move settings from modal to route page (/settings/:section)#2361
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3292741c4d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
3ccf052 to
661f40f
Compare
661f40f to
25852cc
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 25852cc39c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
RouterContext used to snapshot only pathname+search before entering /settings and would
navigate back by URL string alone. That dropped the prior location.state, breaking
/project flows that depend on { projectPath } navigation state (including the legacy
?path= deep link rewrite).
This change snapshots both the URL and location.state, and restores state when leaving
settings. Added a unit test to prevent regressions.
---
_Generated with `mux` • Model: `openai:gpt-5.2` • Thinking: `xhigh` • Cost: `$16.46`_
<!-- mux-attribution: model=openai:gpt-5.2 thinking=xhigh costs=16.46 -->
Settings/index.ts re-exported SettingsPage, SettingsProvider, and useSettings but had zero consumers — all call-sites already import directly from the source modules (SettingsPage.tsx, SettingsContext.tsx). Removing dead code left over from the SettingsModal → SettingsPage rename in #2361.
Settings/index.ts re-exported SettingsPage, SettingsProvider, and useSettings but had zero consumers — all call-sites already import directly from the source modules (SettingsPage.tsx, SettingsContext.tsx). Removing dead code left over from the SettingsModal → SettingsPage rename in #2361.
Settings/index.ts re-exported SettingsPage, SettingsProvider, and useSettings but had zero consumers — all call-sites already import directly from the source modules (SettingsPage.tsx, SettingsContext.tsx). Removing dead code left over from the SettingsModal → SettingsPage rename in #2361.
Settings/index.ts re-exported SettingsPage, SettingsProvider, and useSettings but had zero consumers — all call-sites already import directly from the source modules (SettingsPage.tsx, SettingsContext.tsx). Removing dead code left over from the SettingsModal → SettingsPage rename in #2361.
Settings/index.ts re-exported SettingsPage, SettingsProvider, and useSettings but had zero consumers — all call-sites already import directly from the source modules (SettingsPage.tsx, SettingsContext.tsx). Removing dead code left over from the SettingsModal → SettingsPage rename in #2361.
Settings/index.ts re-exported SettingsPage, SettingsProvider, and useSettings but had zero consumers — all call-sites already import directly from the source modules (SettingsPage.tsx, SettingsContext.tsx). Removing dead code left over from the SettingsModal → SettingsPage rename in #2361.
Settings/index.ts re-exported SettingsPage, SettingsProvider, and useSettings but had zero consumers — all call-sites already import directly from the source modules (SettingsPage.tsx, SettingsContext.tsx). Removing dead code left over from the SettingsModal → SettingsPage rename in #2361.
Settings/index.ts re-exported SettingsPage, SettingsProvider, and useSettings but had zero consumers — all call-sites already import directly from the source modules (SettingsPage.tsx, SettingsContext.tsx). Removing dead code left over from the SettingsModal → SettingsPage rename in #2361.
Summary
Replaces the Settings modal dialog with a full-page Settings experience at
/settings/:section, keeping the app left sidebar visible and hiding the workspace right sidebar.Background
The modal overlay constrained settings layout, fought with focus traps and right-sidebar layering, and couldn't be deep-linked. A route-based page aligns with the existing route-driven architecture (
/workspace/:id,/project) and enables deep-linking from the command palette, keyboard shortcuts, and contextual "open settings" actions.Implementation
5 files changed, +96/−63 lines (net +33)
RouterContext (
src/browser/contexts/RouterContext.tsx)currentSettingsSectionfrom/settings/:sectionURL patternnavigateToSettings(section?)andnavigateFromSettings()helpersSettingsContext (
src/browser/contexts/SettingsContext.tsx)isOpenandactiveSectionare now derived from the route instead of localuseStateopen()/close()/setActiveSection()delegate to router navigationuseSettings().open("providers"), command palette, keyboard shortcut, MCP/Providers prompts) work without modificationprovidersExpandedProviderone-shot hint preserved as local UI stateSettingsPage (
src/browser/components/Settings/SettingsPage.tsx)SettingsModalApp wiring (
src/browser/App.tsx)AppInner's main content area<SettingsModal />mount removedExports (
src/browser/components/Settings/index.ts)SettingsModal→SettingsPageRisks
SettingsContextAPI shape is preserved identically, so all callers continue working. The risk is limited to visual/layout differences vs. the old modal.navigateFromSettings()falls back to/if no prior non-settings route was observed (e.g., app launched directly to a settings URL). This is reasonable behavior but differs from the modal's simple close-overlay behavior.Generated with
mux• Model:anthropic:claude-opus-4-6• Thinking:xhigh• Cost:$7.91