Merge branch 'main' of https://github.com/wled/WLED #5132
Conversation
WalkthroughThis change adds support for the ESP32-S3 DevKitC-1 board with 16MB flash memory. It introduces a new PlatformIO environment, board manifest, and VSCode workspace configuration. Additionally, the web UI is hardened with defensive error handling for color picker initialization and segment population, and JavaScript minification is disabled in the build pipeline. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Tip 📝 Customizable high-level summaries are now available in beta!You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.
Example instruction:
Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later. 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
wled00/data/index.js (1)
1475-1594: Good defensive error handling, but check nested property access.The try/catch wrapper and defensive null checks are well-implemented. The default value for
trat line 1491 is a good safeguard.However, at line 1487, you check
if (s.udpn)but then immediately accesss.udpn.sendwithout checking ifsendexists:1487 if (s.udpn) syncSend = s.udpn.send;Consider:
-if (s.udpn) syncSend = s.udpn.send; +if (s.udpn && s.udpn.send !== undefined) syncSend = s.udpn.send;This ensures
sendis actually present in theudpnobject. Same pattern should be applied to thes.nlchecks at lines 1481-1486.
🧹 Nitpick comments (3)
wled00/data/index.htm (1)
370-370: Consider automating the cache-busting version parameter.The manual version number (
?v=12) requires developers to remember to increment it with each change. Sincetools/cdata.jsalready generates aWEB_BUILD_TIMEtimestamp, you could leverage that for automatic cache busting.Consider:
- Using the build timestamp:
<script src="index.js?v=<%= WEB_BUILD_TIME %>"></script>- Or have the build script automatically inject the version
- This would ensure the cache is always busted on rebuild without manual intervention
The current approach works but is maintenance-heavy.
wled00/data/index.js (2)
2309-2310: Add user feedback when segment bounds validation fails.The bounds checking is good, but the silent return provides no feedback to the user about why their input was rejected.
-if (start<sX.min || start>sX.max) {sX.value=sX.min; return;} -if (stop<eX.min || stop-(cfg.comp.seglen?start:0)>eX.max) {eX.value=eX.max; return;} +if (start<sX.min || start>sX.max) { + sX.value=sX.min; + showToast('Start value out of range', true); + return; +} +if (stop<eX.min || stop-(cfg.comp.seglen?start:0)>eX.max) { + eX.value=eX.max; + showToast('Stop value out of range', true); + return; +}This helps users understand why their segment modification didn't apply.
922-924: Consider replacing magic number 32 with a defined constant.The hardcoded value
32appears to be a default maximum segment count. Based on learnings, magic numbers should be replaced with meaningful constants when they represent domain-specific limits.If there's a defined constant like
WLED_MAX_SEGMENTSor similar in the codebase, use it here:-if (maxSeg == 0) maxSeg = 32; // fallback if maxSeg is 0 +if (maxSeg == 0) maxSeg = DEFAULT_MAX_SEGMENTS; // fallback if maxSeg is 0Otherwise, define it at the top of the file with other constants:
const DEFAULT_MAX_SEGMENTS = 32; // default maximum number of segmentsThis improves maintainability if the limit changes in the future.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
.vscode/tasks.json(1 hunks)AMD_WLED_S3_V1.0.code-workspace(1 hunks)boards/esp32-s3-devkitc-1-n16r8v.json(1 hunks)platformio.ini(1 hunks)tools/cdata.js(1 hunks)wled00/data/index.htm(1 hunks)wled00/data/index.js(14 hunks)
🧰 Additional context used
📓 Path-based instructions (5)
wled00/data/**/*.{htm,html,css,js}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use tabs for indentation in web files (.htm/.html/.css/.js) under wled00/data
Files:
wled00/data/index.htmwled00/data/index.js
wled00/data/**
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
wled00/data/**: When modifying web UI files, runnpm run buildto regenerate embedded headers before any firmware build
For web UI changes, edit files only under wled00/data (not firmware or generated files)
Files:
wled00/data/index.htmwled00/data/index.js
wled00/data/index.htm
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Main web interface entry file is index.htm; ensure it remains present and functional
Files:
wled00/data/index.htm
tools/cdata.js
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use tools/cdata.js to convert web assets to embedded C++ headers; do not reimplement this logic elsewhere
Files:
tools/cdata.js
platformio.ini
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use platformio.ini as the single source of truth for hardware build targets and settings
Files:
platformio.ini
🧠 Learnings (18)
📓 Common learnings
Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-11-14T13:37:11.994Z
Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with appropriate defined constants when those constants are meaningful in the context of the PR. For example, the hardcoded value 32 should be replaced with WLED_MAX_SEGNAME_LEN when it represents a segment name length limit. This improves code maintainability and reduces the risk of inconsistencies.
Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-11-14T13:37:30.955Z
Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with defined constants when meaningful constants exist in the codebase. For example, suggest replacing hardcoded "32" with WLED_MAX_SEGNAME_LEN if the context relates to segment name length limits.
Learnt from: DedeHai
Repo: wled/WLED PR: 4798
File: wled00/FX.cpp:7531-7533
Timestamp: 2025-08-26T11:51:21.817Z
Learning: In WLED PR #4798, DedeHai confirmed that certain gamma-related calls in FX.cpp/FX_fcn.cpp/particle systems are intentional for effect-level shaping (e.g., brightness curves, TV sim, Pride 2015 pre-mix), distinct from final output gamma. Do not flag or remove these in future reviews; add comments when feasible to clarify intent.
Learnt from: blazoncek
Repo: wled/WLED PR: 4482
File: wled00/udp.cpp:147-149
Timestamp: 2025-02-19T12:43:34.199Z
Learning: ESP8266 and ESP32 platforms have different maximum segment name lengths in WLED, which can cause truncation when syncing segment names between devices. This platform difference affects the user experience when using the segment name sync feature.
Learnt from: willmmiles
Repo: wled/WLED PR: 4890
File: lib/NeoESP32RmtHI/src/NeoEsp32RmtHI.S:8-16
Timestamp: 2025-09-02T02:27:39.220Z
Learning: The ESP32 macro is defined when compiling code on all ESP32 variants (ESP32, ESP32-S2, ESP32-S3, ESP32-C3, etc.) in the Arduino framework, providing consistent library compatibility across the entire ESP32 family. For target-specific detection, CONFIG_IDF_TARGET_* macros should be used instead.
Learnt from: willmmiles
Repo: wled/WLED PR: 4890
File: lib/NeoESP32RmtHI/include/NeoEsp32RmtHIMethod.h:31-36
Timestamp: 2025-09-02T01:45:58.047Z
Learning: For the NeoEsp32RmtHI driver, RISC-V ESP32-C3 support is currently disabled via bus_wrapper.h rather than compile-time guards, as the maintainer willmmiles is working on resolving underlying nested interrupt issues and prefers to centralize the workaround in one location.
Learnt from: softhack007
Repo: wled/WLED PR: 5107
File: boards/adafruit_matrixportal_esp32s3.json:1-66
Timestamp: 2025-11-22T20:33:14.840Z
Learning: In WLED, board JSON files in the boards/ directory may reference partition files that don't exist or have slightly different names than actual files in tools/. This is intentional because platformio.ini or platformio_override.sample.ini explicitly override the partition file using the board_build.partitions setting, which takes precedence over the board JSON partition reference. This pattern exists in multiple local board definitions and should not be flagged as an issue.
📚 Learning: 2025-10-05T15:24:05.545Z
Learnt from: CR
Repo: wled/WLED PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-10-05T15:24:05.545Z
Learning: Applies to tools/cdata.js : Use tools/cdata.js to convert web assets to embedded C++ headers; do not reimplement this logic elsewhere
Applied to files:
tools/cdata.js
📚 Learning: 2025-09-12T17:29:43.826Z
Learnt from: DedeHai
Repo: wled/WLED PR: 4923
File: wled00/FX.cpp:4883-4901
Timestamp: 2025-09-12T17:29:43.826Z
Learning: In WLED’s web UI, only one slider value (e.g., SEGMENT.intensity or SEGMENT.custom1) changes at a time; code relying on this may use simplified change guards, though presets/JSON can still update multiple fields atomically.
Applied to files:
wled00/data/index.js
📚 Learning: 2025-04-24T09:31:06.879Z
Learnt from: blazoncek
Repo: wled/WLED PR: 4658
File: wled00/led.cpp:90-91
Timestamp: 2025-04-24T09:31:06.879Z
Learning: In the WLED codebase, the `getSegment()` function guards against out-of-bounds segment IDs by falling back to the main segment ID, and `getFirstSelectedSegId()` falls back to `getMainSegmentId()` if no segments are selected, ensuring no crashes when used through the `setValuesFromFirstSelectedSeg()` macro.
Applied to files:
wled00/data/index.js
📚 Learning: 2025-04-24T09:31:06.879Z
Learnt from: blazoncek
Repo: wled/WLED PR: 4658
File: wled00/led.cpp:90-91
Timestamp: 2025-04-24T09:31:06.879Z
Learning: In the WLED codebase, the `getSegment()` function guards against out-of-bounds segment IDs, and `getFirstSelectedSegId()` falls back to `getMainSegmentId()` if no segments are selected, ensuring no crashes when used through the `setValuesFromFirstSelectedSeg()` macro.
Applied to files:
wled00/data/index.js
📚 Learning: 2025-11-14T13:37:11.994Z
Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-11-14T13:37:11.994Z
Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with appropriate defined constants when those constants are meaningful in the context of the PR. For example, the hardcoded value 32 should be replaced with WLED_MAX_SEGNAME_LEN when it represents a segment name length limit. This improves code maintainability and reduces the risk of inconsistencies.
Applied to files:
wled00/data/index.js
📚 Learning: 2025-10-10T18:34:06.550Z
Learnt from: DedeHai
Repo: wled/WLED PR: 4997
File: wled00/e131.cpp:33-44
Timestamp: 2025-10-10T18:34:06.550Z
Learning: In WLED's DDP packet handling (ws.cpp and e131.cpp), only prevent out-of-bounds memory access rather than enforcing DDP spec compliance. Don't check the 1440-byte spec limit—accept out-of-spec packets assuming correct encoding. The bounds check `maxDataIndex = c + numLeds * ddpChannelsPerLed; if (maxDataIndex > dataLen) reject` is sufficient and already covers the timecode flag case (when c=4) without needing separate validation.
Applied to files:
wled00/data/index.js
📚 Learning: 2025-11-14T13:37:30.955Z
Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-11-14T13:37:30.955Z
Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with defined constants when meaningful constants exist in the codebase. For example, suggest replacing hardcoded "32" with WLED_MAX_SEGNAME_LEN if the context relates to segment name length limits.
Applied to files:
wled00/data/index.js
📚 Learning: 2025-11-14T05:48:44.673Z
Learnt from: DedeHai
Repo: wled/WLED PR: 5040
File: wled00/image_loader.cpp:84-96
Timestamp: 2025-11-14T05:48:44.673Z
Learning: In WLED (wled00/FX_2Dfcn.cpp), the Segment::setPixelColorXY() function performs internal bounds checking against vWidth() and vHeight(), returning early if coordinates are out of bounds. No additional guards are needed when calling this function, even in upscaling loops where coordinates might exceed segment dimensions.
Applied to files:
wled00/data/index.js
📚 Learning: 2025-08-26T11:51:21.817Z
Learnt from: DedeHai
Repo: wled/WLED PR: 4798
File: wled00/FX.cpp:7531-7533
Timestamp: 2025-08-26T11:51:21.817Z
Learning: In WLED PR #4798, DedeHai confirmed that certain gamma-related calls in FX.cpp/FX_fcn.cpp/particle systems are intentional for effect-level shaping (e.g., brightness curves, TV sim, Pride 2015 pre-mix), distinct from final output gamma. Do not flag or remove these in future reviews; add comments when feasible to clarify intent.
Applied to files:
wled00/data/index.js
📚 Learning: 2025-10-05T15:24:05.545Z
Learnt from: CR
Repo: wled/WLED PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-10-05T15:24:05.545Z
Learning: Applies to wled00/data/** : For web UI changes, edit files only under wled00/data (not firmware or generated files)
Applied to files:
wled00/data/index.js
📚 Learning: 2025-10-20T09:41:50.374Z
Learnt from: blazoncek
Repo: wled/WLED PR: 4995
File: wled00/FX.cpp:5209-5212
Timestamp: 2025-10-20T09:41:50.374Z
Learning: In WLED 2D effects, SEGMENT.length() returns the physical pixel count (upper bound), while SEG_W * SEG_H can be smaller depending on mapping (mirroring/grouping). For per-cell state buffers (e.g., mode_2Dgameoflife in wled00/FX.cpp), allocate using SEGMENT.length() to ensure sufficient capacity and avoid reallocations, while bounding indexing by cols*rows.
Applied to files:
wled00/data/index.js
📚 Learning: 2025-09-02T19:42:57.475Z
Learnt from: freakintoddles2
Repo: wled/WLED PR: 4904
File: wled00/FX.cpp:3915-3930
Timestamp: 2025-09-02T19:42:57.475Z
Learning: WLED wled00/FX.cpp::mode_percent — For time-based options (% of Minute/Hour/Day), behavior is clock-like: at rollover (elapsed==0) intentionally show SEGLEN lit for one tick to represent completion, then move to 1 LED at the next second. This is by design (not a progress bar) and should not be “fixed”.
Applied to files:
wled00/data/index.js
📚 Learning: 2025-10-05T15:24:05.545Z
Learnt from: CR
Repo: wled/WLED PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-10-05T15:24:05.545Z
Learning: Applies to platformio.ini : Use platformio.ini as the single source of truth for hardware build targets and settings
Applied to files:
platformio.ini.vscode/tasks.json
📚 Learning: 2025-09-02T02:27:39.220Z
Learnt from: willmmiles
Repo: wled/WLED PR: 4890
File: lib/NeoESP32RmtHI/src/NeoEsp32RmtHI.S:8-16
Timestamp: 2025-09-02T02:27:39.220Z
Learning: The ESP32 macro is defined when compiling code on all ESP32 variants (ESP32, ESP32-S2, ESP32-S3, ESP32-C3, etc.) in the Arduino framework, providing consistent library compatibility across the entire ESP32 family. For target-specific detection, CONFIG_IDF_TARGET_* macros should be used instead.
Applied to files:
platformio.iniboards/esp32-s3-devkitc-1-n16r8v.json
📚 Learning: 2025-11-22T20:33:14.840Z
Learnt from: softhack007
Repo: wled/WLED PR: 5107
File: boards/adafruit_matrixportal_esp32s3.json:1-66
Timestamp: 2025-11-22T20:33:14.840Z
Learning: In WLED, board JSON files in the boards/ directory may reference partition files that don't exist or have slightly different names than actual files in tools/. This is intentional because platformio.ini or platformio_override.sample.ini explicitly override the partition file using the board_build.partitions setting, which takes precedence over the board JSON partition reference. This pattern exists in multiple local board definitions and should not be flagged as an issue.
Applied to files:
platformio.iniboards/esp32-s3-devkitc-1-n16r8v.json
📚 Learning: 2025-02-19T12:43:34.199Z
Learnt from: blazoncek
Repo: wled/WLED PR: 4482
File: wled00/udp.cpp:147-149
Timestamp: 2025-02-19T12:43:34.199Z
Learning: ESP8266 and ESP32 platforms have different maximum segment name lengths in WLED, which can cause truncation when syncing segment names between devices. This platform difference affects the user experience when using the segment name sync feature.
Applied to files:
platformio.iniboards/esp32-s3-devkitc-1-n16r8v.json
📚 Learning: 2025-09-02T01:45:58.047Z
Learnt from: willmmiles
Repo: wled/WLED PR: 4890
File: lib/NeoESP32RmtHI/include/NeoEsp32RmtHIMethod.h:31-36
Timestamp: 2025-09-02T01:45:58.047Z
Learning: For the NeoEsp32RmtHI driver, RISC-V ESP32-C3 support is currently disabled via bus_wrapper.h rather than compile-time guards, as the maintainer willmmiles is working on resolving underlying nested interrupt issues and prefers to centralize the workaround in one location.
Applied to files:
platformio.ini
🔇 Additional comments (9)
AMD_WLED_S3_V1.0.code-workspace (1)
1-8: LGTM!Standard VSCode workspace configuration that correctly points to the repository root and enables the workspace to work with the new ESP32-S3 build environment.
platformio.ini (3)
703-704: Verify CONFIG_LITTLEFS_FOR_IDF_3_2 flag necessity.The flag
-D CONFIG_LITTLEFS_FOR_IDF_3_2is specific to LITTLEFS for ESP-IDF 3.2 compatibility. Confirm this is required for this board's ESP-IDF version and storage strategy, especially given that other ESP32-S3 environments (e.g., line 563) do not include it.
697-710: Verify inheritance of platform and related settings.The new environment correctly inherits
platformandplatform_packagesfrom${esp32s3}(lines 699–700), which is appropriate per coding guidelines that use platformio.ini as the source of truth. Confirm that${esp32s3.lib_deps}(line 706) and${esp32s3.build_flags}(line 703) are the correct base settings for this variant.
697-710: Configuration is internally consistent; no board JSON mismatch exists.The original concern assumed a local board JSON file with conflicting PSRAM description exists. However, no board JSON file for
esp32-s3-devkitc-1-n16r8vexists in theboards/directory. This is a platform-provided board, andplatformio.iniis the single source of truth. The configuration correctly matches the board designation:
- N16R8V naming: 16MB flash + 8MB PSRAM (R8 indicates PSRAM presence)
- Flags are consistent:
-DBOARD_HAS_PSRAMandqio_opimemory type work together (OPI mode requires PSRAM)- Follows established patterns: Identical settings appear in
esp32s3dev_16MB_opi(line 555–564)No action required.
boards/esp32-s3-devkitc-1-n16r8v.json (1)
1-51: Partition and memory_type configuration follows expected WLED patterns.The board JSON references
default_16MB.csvfor partitions andqio_qspifor memory_type, but platformio.ini explicitly overrides both (board_build.partitions = ${esp32.extreme_partitions}andboard_build.arduino.memory_type = qio_opi). This is the standard WLED pattern where platformio.ini is the source of truth. Based on learnings, no changes needed here..vscode/tasks.json (1)
41-55: LGTM!The new "Build: ESP32-S3 Custom" task is properly configured and correctly invokes the new platformio environment. The shell task type, PlatformIO problem matcher integration, and build group placement follow VSCode conventions and align with the new platformio.ini environment definition.
wled00/data/index.js (2)
769-955: Excellent defensive error handling in populateSegments.The try/catch wrapper with detailed error logging and user-facing toast notification is well-implemented. The defensive checks for array validity, NaN IDs, and DOM element existence are good practices.
Minor suggestion: At lines 879-880, the max values use
ledCount, but ifledCountis 0 (edge case during initialization), you might want a minimum fallback:-<td><input class="segn" id="seg${i}s" type="number" min="0" max="${(isMSeg?mw:(ledCount > 0 ? ledCount : 30))-1}" value="${staX}" oninput="updateLen(${i})" onkeydown="segEnter(${i})"></td> +<td><input class="segn" id="seg${i}s" type="number" min="0" max="${(isMSeg?mw:Math.max(ledCount, 30))-1}" value="${staX}" oninput="updateLen(${i})" onkeydown="segEnter(${i})"></td>Same for line 880. This ensures a reasonable maximum even if
ledCountis 0.
1518-1518: LGTM! More helpful error message.Changing the message from "No segments!" to "No segments! Check LED Config." provides better guidance to users on how to resolve the issue.
tools/cdata.js (1)
116-116: Based on my verification, I've found a critical discrepancy:The review comment is incorrect. The code at line 116 of
tools/cdata.jscurrently showsminifyJS: true, notminifyJS: falseas claimed in the review comment.Additionally:
- Both the PR branch (HEAD) and main branch are at the same commit (a897271)
- There are no uncommitted or staged changes to
cdata.js- The only occurrence of
minifyJSin the tools directory is this single line showingtrueThe review appears to reference a change that either:
- Was never actually applied to this PR
- Is from a different PR context
- Is hypothetical rather than reflecting actual code changes
Since the change described in the review (disabling minification) does not exist in the codebase, the concerns raised about flash memory impact and size increases are not applicable.
The review comment contains incorrect information about the current code state and should be dismissed or corrected to reflect that minifyJS remains enabled (true) in the codebase.
Likely an incorrect or invalid review comment.
| "arduino", | ||
| "espidf" | ||
| ], | ||
| "name": "Espressif ESP32-S3-DevKitC-1-N16 (16 MB QD, No PSRAM)", |
There was a problem hiding this comment.
Update board description to match configuration.
The board name field lists "(16 MB QD, No PSRAM)", but this contradicts the platformio.ini configuration which sets BOARD_HAS_PSRAM and uses qio_opi memory mode (see platformio.ini lines 703–708). Clarify and correct the description once the PSRAM presence is verified.
🤖 Prompt for AI Agents
In boards/esp32-s3-devkitc-1-n16r8v.json around line 41, the "name" claims "(16
MB QD, No PSRAM)" but platformio.ini (lines 703–708) enables BOARD_HAS_PSRAM and
sets qio_opi memory mode; verify which is correct and reconcile them: if PSRAM
is present, update the JSON name to reflect PSRAM and the actual memory mode
(e.g., mention PSRAM and QIO/OPI as appropriate); if PSRAM is not present,
remove BOARD_HAS_PSRAM and the qio_opi memory mode from platformio.ini instead
and adjust any related settings; ensure the board name and platformio.ini are
consistent and descriptive.
| try { | ||
| cpick = new iro.ColorPicker("#picker", { | ||
| width: 260, | ||
| wheelLightness: false, | ||
| wheelAngle: 270, | ||
| wheelDirection: "clockwise", | ||
| layout: [{ | ||
| component: iro.ui.Wheel, | ||
| options: {} | ||
| }] | ||
| }); | ||
| } catch (e) { | ||
| console.error("iro load error", e); | ||
| if (typeof showToast === "function") showToast("Color Picker Error: " + e, true); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Good defensive initialization, but ensure consistent null checks throughout.
The try/catch wrapper for color picker initialization is excellent, and the conditional event binding at lines 284-287 is correct. However, there are many other places in the code that access cpick without null checks:
- Line 2635:
if (cpick.color.value == 0)- no null check - Lines 2659-2689:
updatePSliders()usescpickextensively without checks - Lines 2713-2739:
setPicker(),fromH(),fromS(),fromV(),fromK()all usecpickwithout checks
Apply this pattern consistently throughout the file:
function updatePSliders() {
+ if (!cpick) return;
// update RGB sliders
var col = cpick.color.rgb; function setPicker(rgb) {
+ if (!cpick) return;
var c = new iro.Color(rgb);Do the same for fromH(), fromS(), fromV(), fromK(), and other functions that use cpick.
Also applies to: 284-287
🤖 Prompt for AI Agents
In wled00/data/index.js around lines 214 and across the file (notably lines
~2635, 2659-2689, 2713-2739 and 284-287), cpick is initialized inside a
try/catch so it may be null/undefined in failure paths; update every location
that reads cpick (e.g., cpick.color.value and all uses inside updatePSliders(),
setPicker(), fromH(), fromS(), fromV(), fromK(), and the event binding at
284-287) to first check that cpick is truthy and return early (or skip the
operation) if not; alternatively factor a small helper like ensureCpick() that
returns a boolean or throws, and call it at the top of those functions before
any cpick property access to avoid runtime errors.
1 participant
Summary by CodeRabbit
New Features
Bug Fixes
Chores
✏️ Tip: You can customize this high-level summary in your review settings.