You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
FastHTML route handlers convert falsy values to empty strings when rendering responses. Specifically:
The integer 0 is converted to '' (empty string) instead of '0'
The boolean False is converted to '' instead of 'False'
This behavior is inconsistent with how other primitive values are handled, where integers like 1 correctly convert to '1' and True correctly converts to 'True'.
I have included the versions of fastlite, fastcore, and fasthtml
I understand that this is a volunteer open source project with no commercial support.
Additional context
The current behavior makes it impossible to distinguish between an empty response and a response containing 0 or False.
Similar but unrelated bug #567, this one caused by line 188...v not in (False, None, '')... in to_xml.
This happens because the initial check if not resp: resp=() in _resp() treats these valid values as falsy conditions, preventing them from reaching the string conversion at the end of the function.
I don't know if this is intended, but i can imagine cases where 0 can be a valid response. At least, it think it should be deocumented so we can intercept this cases and return strings.
The above examples are contrived, but consider this simple component with a readout that never shows the 0 (running in a notebook):
Describe the bug
FastHTML route handlers convert falsy values to empty strings when rendering responses. Specifically:
0
is converted to''
(empty string) instead of'0'
False
is converted to''
instead of'False'
This behavior is inconsistent with how other primitive values are handled, where integers like
1
correctly convert to'1'
andTrue
correctly converts to'True'
.Minimal Reproducible Example
Expected behavior
0
should render as'0'
in the responseFalse
should render as'False'
in the responseThis would be consistent with how other primitive values are handled, where:
1
renders as'1'
True
renders as'True'
Environment Information
Confirmation
Additional context
The current behavior makes it impossible to distinguish between an empty response and a response containing
0
orFalse
.Similar but unrelated bug #567, this one caused by line 188
...v not in (False, None, '')...
in to_xml.This happens because the initial check
if not resp: resp=()
in_resp()
treats these valid values as falsy conditions, preventing them from reaching the string conversion at the end of the function.I don't know if this is intended, but i can imagine cases where
0
can be a valid response. At least, it think it should be deocumented so we can intercept this cases and return strings.The above examples are contrived, but consider this simple component with a readout that never shows the
0
(running in a notebook):Screenshots
The text was updated successfully, but these errors were encountered: