fix(coercion): tolerate string/percentage input on numeric fields; widen visible falsy set#30
Open
balloob wants to merge 1 commit into
Open
fix(coercion): tolerate string/percentage input on numeric fields; widen visible falsy set#30balloob wants to merge 1 commit into
balloob wants to merge 1 commit into
Conversation
…den visible
Home Assistant templates render every value to a string, so numeric element
fields raised TypeError deep inside the handlers. This routes dimension-like
fields through CoordinateParser (which already coerces numeric strings and
percentages) and str()-coerces text, and hardens the `visible` coercion.
- A8: add coordinates.coerce_number() for plain numeric fields, and route
dimension fields through parse_x/parse_y/parse_size:
* progress_bar.progress ("50"), progress_bar/line/rect/circle/ellipse width
* multiline.value (non-str), multiline.size/offset_y/y_padding/stroke_width
* text.y_padding/stroke_width/max_width
* icon.size / icon_sequence.size ("50%"), stroke_width, spacing
* rectangle_pattern geometry (x_start "10%", sizes, offsets, repeats)
* circle.radius (now parses "%" like arc.radius)
* plot.x_start/x_end/y_start/y_end
* dlimg.xsize/ysize, qrcode.boxsize/border
- A9: extend the falsy `visible` strings with "0"/"no"/"off"/"none" so a
template rendering {{ 0 }} ("0") hides the element instead of showing it.
Adds unit tests for coerce_number and _coerce_visible, and integration tests
covering the verified A8 crash cases.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UVpLN4Rzdv7y3ud7QzutVJ
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Home Assistant templates render every value to a string, so numeric element fields (
progress,size,width,radius,offset_y, pattern geometry, …) raisedTypeErrordeep inside the handlers when a dashboard fed them templated values. This is the single highest-leverage robustness change for HA use (finding A8), plus a small fix tovisiblecoercion (A9).Approach
coordinates.coerce_number()— coerces ints/floats/numeric strings to a number, falling back to a default for non-numeric input. Used for plain scalar fields (widths, counts, progress) that don't take percentages.CoordinateParser.parse_x/parse_y/parse_size, which already coerces numeric strings and supports"50%".str()-coerced text value fields.Findings addressed
A8 — numeric fields crash on template-string input; percentage support made consistent. Fields now coerced:
progress_barprogress(verified"50"crash),widthmultilinevalue(verified non-str crash),size,offset_y,y_padding,stroke_widthtexty_padding,stroke_width,max_widthicon/icon_sequencesize(verified"50%"crash),stroke_width,spacingrectangle_patternx_start/y_start(verified"10%"crash), sizes, offsets, repeatsline/rectangle/circle/ellipsewidth,radiuscircleradiusnow parses"%"— parity witharc.radiusplotx_start/x_end/y_start/y_enddlimg/qrcodexsize/ysize,boxsize/borderA9 —
visiblestring coercion._FALSY_VISIBLE_STRINGSgains"0","no","off","none", so a template rendering{{ 0 }}(→"0") hides the element rather than showing it. The existingtest_visible.pycases that pinned the old behavior are updated to the corrected expectation.Tests
test_coordinates.py: unit tests forcoerce_number.test_visible.py: updated to expect"0"/"no"/"off"/"none"→ hidden.test_string_coercion.py(new): integration tests for each verified A8 crash plus a few of the same-shape fields (circle radius %, line width, text dimensions, dlimg size).No new failures (pre-existing
tests/visual/*byte-snapshot failures under Pillow 12 are unrelated).🤖 Generated with Claude Code