Repository navigation
wework新增应用tab - #1388
wework新增应用tab#1388
Conversation
📝 WalkthroughWalkthroughAdds a native ChangesApps Tab Feature
Executor Build Version and Dev Server Config
AGENTS.md Module Docs
Sequence Diagram(s)sequenceDiagram
participant User
participant ChromeTitlebar
participant useChromeTabs
participant AppRoutes
participant AppsPage
participant deviceApi
participant userApi
User->>ChromeTitlebar: clicks apps tab
ChromeTitlebar->>useChromeTabs: navigateToApp('apps')
useChromeTabs->>useChromeTabs: find tab by key, tab.mode === 'native'
useChromeTabs->>AppRoutes: navigate to tab.path ('/apps')
AppRoutes->>AppsPage: render path === '/apps'
AppsPage->>deviceApi: getAllDevices()
AppsPage->>userApi: getRuntimeConfig('codex')
AppsPage->>userApi: getProxyConfig()
deviceApi-->>AppsPage: DeviceInfo[]
userApi-->>AppsPage: codexConfig, proxyConfig
AppsPage->>AppsPage: derive metrics, buildRecommendedApps
AppsPage-->>User: render dashboard with HeroSection, ExecutorStatusCard, AppCard[], QuickAction[]
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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 |
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
wework/src/pages/AppsPage.tsx (1)
338-499: 🏗️ Heavy liftSplit
AppsPageinto smaller units to keep page orchestration maintainable.
AppsPagecurrently carries data loading, derivation, and large render composition in one function well above the preferred function-length threshold. Extracting a data hook (useAppsPageData) plus section components will reduce coupling and future change risk.As per coding guidelines,
**/*.{ts,tsx,py}functions should stay within 50 lines (preferred). Based on learnings, “Manage complexity through extraction” and “High cohesion, low coupling” should guide this page structure.🤖 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 `@wework/src/pages/AppsPage.tsx` around lines 338 - 499, The AppsPage function exceeds the preferred 50-line threshold and mixes data loading, derivation, and large render composition. Extract the entire useEffect block (that calls deviceApi.getAllDevices, userApi.getRuntimeConfig, and userApi.getProxyConfig, along with the state updates and cancellation logic) into a custom hook named useAppsPageData that returns the state object. Then extract each major section of the render output (the header with search, the recommended apps section, the run overview section with SummaryCard items, the quick actions section with QuickAction items, and the recent activity section with ActivityRow items) into separate presentational components. Update the main AppsPage function to use the useAppsPageData hook and compose these extracted section components, reducing the function body to primarily orchestration logic.Sources: Coding guidelines, Learnings
🤖 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 `@wework/src/App.apps.test.tsx`:
- Around line 45-96: The test file App.apps.test.tsx is mocking the global fetch
function with synthetic payloads for API endpoints like /devices,
/users/me/runtime-configs/codex, and /users/me/proxy-config. Remove the entire
vi.stubGlobal('fetch', vi.fn(...)) block that creates these artificial
responses. Instead, configure the test to make real HTTP requests to the actual
backend API endpoints, ensuring the test validates genuine integration behavior
rather than relying on mocked responses. This aligns with the frontend E2E
coverage guidelines that require real HTTP communication with backend APIs.
In `@wework/src/pages/AppsPage.tsx`:
- Line 339: Replace the 'common' namespace in the useTranslation call at line
339 with a feature-owned namespace appropriate for the AppsPage (such as
'apps'). Then locate the translation call with a fallback literal at line 414
and remove the fallback string, keeping only the translation key to rely on
keyed translations without any fallback literals. Ensure all new translation
strings follow this pattern of using the feature namespace with keyed-only
access.
- Line 215: The primary action button styling in AppsPage.tsx is using the wrong
color tokens for the design system. Locate the button element with className
containing bg-text-primary and text-background (around line 215), and update the
className to replace bg-text-primary with bg-primary and text-background with
text-white to align with the primary button design token guidelines.
---
Nitpick comments:
In `@wework/src/pages/AppsPage.tsx`:
- Around line 338-499: The AppsPage function exceeds the preferred 50-line
threshold and mixes data loading, derivation, and large render composition.
Extract the entire useEffect block (that calls deviceApi.getAllDevices,
userApi.getRuntimeConfig, and userApi.getProxyConfig, along with the state
updates and cancellation logic) into a custom hook named useAppsPageData that
returns the state object. Then extract each major section of the render output
(the header with search, the recommended apps section, the run overview section
with SummaryCard items, the quick actions section with QuickAction items, and
the recent activity section with ActivityRow items) into separate presentational
components. Update the main AppsPage function to use the useAppsPageData hook
and compose these extracted section components, reducing the function body to
primarily orchestration logic.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 57370c8d-de97-4d80-813d-28bcaaafc70d
📒 Files selected for processing (14)
AGENTS.mdexecutor/local.shwework/src/App.apps.test.tsxwework/src/App.tsxwework/src/components/chat/MessageList.tsxwework/src/components/layout/DesktopWorkbenchMain.tsxwework/src/components/topnav/ChromeTitlebar.tsxwework/src/components/topnav/useChromeTabs.test.tswework/src/components/topnav/useChromeTabs.tswework/src/config/apps.tswework/src/pages/AppsPage.tsxwework/src/pages/PluginManagementPage.tsxwework/src/pages/PluginsPage.tsxwework/src/styles/globals.css
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 `@start.sh`:
- Around line 2380-2385: The current implementation force-kills all processes
listening on WEWORK_PORT using get_port_listener_pids and kill -9, which is
overly broad and can terminate unrelated processes. Modify the logic to first
attempt to kill only the tracked wework.pid process (and optionally its process
group) using a gentler signal, then only escalate to kill -9 if that tracked
process fails to exit cleanly. This ensures only the intended wework process is
terminated rather than any process that happens to be listening on that port.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 70dbb40b-3b17-442b-9f17-2a14aa7fd621
📒 Files selected for processing (4)
start.shwework/package.jsonwework/src/App.apps.test.tsxwework/src/pages/AppsPage.tsx
✅ Files skipped from review due to trivial changes (1)
- wework/package.json
🚧 Files skipped from review as they are similar to previous changes (2)
- wework/src/App.apps.test.tsx
- wework/src/pages/AppsPage.tsx
There was a problem hiding this comment.
🧹 Nitpick comments (1)
wework/src/components/layout/DesktopWorkbenchLayout.test.tsx (1)
55-2884: 🏗️ Heavy liftSplit this oversized test suite into sub-modules to meet the file-size rule.
This file is 2884 lines and exceeds the 1000-line limit, which is making the suite hard to evolve safely. Please split by feature areas (e.g., sidebar/search/settings/workspace panels) into focused test files.
As per coding guidelines, “File size limit: if a file exceeds 1000 lines, split it into multiple sub-modules”.
🤖 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 `@wework/src/components/layout/DesktopWorkbenchLayout.test.tsx` around lines 55 - 2884, Split the DesktopWorkbenchLayout.test.tsx file (currently 2884 lines) into multiple focused test files organized by feature areas to meet the 1000-line file-size limit. Create separate test files for: (1) sidebar functionality (collapse/expand, width management, section toggling), (2) search and task discovery, (3) settings menu and account management, (4) project creation and management, (5) device status and availability, (6) offline conversations and device locking, (7) environment info and git branch operations, and (8) workspace panels (right and bottom). Move the shared setup code (beforeEach, baseProps, helper functions like createCloudWorkspacePanelState) to a separate test utilities file that all test modules can import, and ensure each new test file focuses on a cohesive set of related functionality while maintaining proper test isolation.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 `@wework/src/components/layout/DesktopWorkbenchLayout.test.tsx`:
- Around line 55-2884: Split the DesktopWorkbenchLayout.test.tsx file (currently
2884 lines) into multiple focused test files organized by feature areas to meet
the 1000-line file-size limit. Create separate test files for: (1) sidebar
functionality (collapse/expand, width management, section toggling), (2) search
and task discovery, (3) settings menu and account management, (4) project
creation and management, (5) device status and availability, (6) offline
conversations and device locking, (7) environment info and git branch
operations, and (8) workspace panels (right and bottom). Move the shared setup
code (beforeEach, baseProps, helper functions like
createCloudWorkspacePanelState) to a separate test utilities file that all test
modules can import, and ensure each new test file focuses on a cohesive set of
related functionality while maintaining proper test isolation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 2b9bebbd-032d-40dd-961a-0080f7a154a5
📒 Files selected for processing (1)
wework/src/components/layout/DesktopWorkbenchLayout.test.tsx
Summary by CodeRabbit
Release Notes
New Features
/appspage and corresponding apps navigation tab.Improvements
Tests
/appsrouting and header/tab behavior.Documentation
Chores