Add mock web build for Cloudflare Pages previews#22
Conversation
Deploying switchbotcontroller with
|
| Latest commit: |
61fa122
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://f7444aec.switchbotcontroller.pages.dev |
| Branch Preview URL: | https://codex-add-cloudflare-pages-b-nnzv.switchbotcontroller.pages.dev |
Summary of ChangesHello @0suu, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly improves the development and preview workflow by introducing a dedicated web build for static hosting platforms like Cloudflare Pages. It integrates a robust mock mode that simulates all SwitchBot API interactions and local storage, allowing developers to test and preview the application's UI and functionality without requiring live API credentials or an Electron environment. This ensures a more streamlined and isolated development experience for the renderer component. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces a valuable mock build for Cloudflare Pages, which will significantly improve the development and preview experience by allowing the renderer to run standalone with mock data. The implementation is well-structured, introducing a mock mode that cleanly separates concerns and stubs out both the Electron store and the SwitchBot API bridge. The changes to the build process and Redux state management to accommodate this new mode are also well-handled.
I've provided a few suggestions to enhance type safety and improve the mock implementation's correctness. Specifically, I recommend centralizing the type definitions for the API bridge to avoid unsafe type casting and ensuring the mock sendCommand function correctly handles non-existent devices. These changes will improve the long-term maintainability and robustness of the new mock system. Overall, this is a great addition to the project.
| if (typeof window !== "undefined" && window.switchBotBridge) { | ||
| return window.switchBotBridge as unknown as SwitchBotBridgeLike; | ||
| } |
There was a problem hiding this comment.
The type assertion as unknown as SwitchBotBridgeLike is used to cast window.switchBotBridge. This bypasses TypeScript's type safety and can hide potential type mismatches between the actual bridge API and the one expected here. To improve type safety and maintainability, consider defining the SwitchBotBridgeLike and SwitchBotBridgeResponse<T> types in a shared location (e.g., src/api/types.ts or a new src/api/bridge-types.ts) and using it consistently across apiClient.ts, mockSwitchBotBridge.ts, and src/renderer/src/global.d.ts. This would provide a single source of truth for the bridge interface and eliminate the need for unsafe casting.
| async sendCommand(deviceId: string, command: string, parameter?: any) { | ||
| const status = mockStatuses[deviceId]; | ||
| if (status) { | ||
| if (command === "turnOn") { | ||
| status.power = "on"; | ||
| status.moving = false; | ||
| } else if (command === "turnOff") { | ||
| status.power = "off"; | ||
| status.moving = false; | ||
| } else if (command === "setPosition") { | ||
| const parsed = typeof parameter === "string" ? Number(String(parameter).split(",").pop()) : Number(parameter); | ||
| if (!Number.isNaN(parsed)) { | ||
| status.slidePosition = Math.max(0, Math.min(100, Math.round(parsed))); | ||
| } | ||
| status.moving = false; | ||
| } else if (command === "press") { | ||
| status.lastAction = "pressed"; | ||
| } | ||
| } | ||
| return { success: true, data: successResponse({}) }; | ||
| }, |
There was a problem hiding this comment.
The sendCommand function in the mock bridge currently returns a success response even if the deviceId is not found in mockStatuses. This differs from the behavior of getDeviceStatus, which correctly returns an error for a non-existent device. To make the mock more realistic and help catch potential bugs during development, sendCommand should also return an error if the device is not found.
async sendCommand(deviceId: string, command: string, parameter?: any) {
const status = mockStatuses[deviceId];
if (!status) {
return { success: false, error: "Device not found" };
}
if (command === "turnOn") {
status.power = "on";
status.moving = false;
} else if (command === "turnOff") {
status.power = "off";
status.moving = false;
} else if (command === "setPosition") {
const parsed = typeof parameter === "string" ? Number(String(parameter).split(",").pop()) : Number(parameter);
if (!Number.isNaN(parsed)) {
status.slidePosition = Math.max(0, Math.min(100, Math.round(parsed)));
}
status.moving = false;
} else if (command === "press") {
status.lastAction = "pressed";
}
return { success: true, data: successResponse({}) };
},| if (typeof window === "undefined") return; | ||
| if (!window.switchBotBridge) { | ||
| // eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
| window.switchBotBridge = mockSwitchBotBridge as any; |
There was a problem hiding this comment.
The use of as any to cast mockSwitchBotBridge bypasses TypeScript's type checking. This is often a sign of inconsistent type definitions. As mentioned in the review for src/api/apiClient.ts, creating a shared, single-source-of-truth type definition for the SwitchBot bridge API and using it across all relevant files (apiClient.ts, mockSwitchBotBridge.ts, global.d.ts, and here) would resolve this and improve overall type safety and maintainability.
| window.switchBotBridge = mockSwitchBotBridge as any; | |
| window.switchBotBridge = mockSwitchBotBridge; |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
switchbotcintroller | 9f802df | Dec 28 2025, 09:57 AM |
9f802df to
61fa122
Compare
Summary
Testing
Codex Task