Summary
When a calculated field's formula references a macro for an optional number field that the user leaves empty, JetFormBuilder substitutes an empty string into the expression. The resulting JS is malformed and evaluates to NaN, which then propagates through any dependent calculated fields and renders the visible total as 0 (or NaN).
This is not a jfb-is-valid-inputs-field issue — it reproduces against JetFormBuilder alone.
Minimal reproduction
- Create a form with:
- Number field
a — required, default 4
- Number field
b — not required, no default
- Calculated field with
data-formula="%a%*%b%" and data-precision="0"
- Submit/render the form without filling
b.
Expected: the calculated field renders 0 (or a documented well-defined value), or the formula is short-circuited.
Actual: the substituted expression becomes 4* (empty after *), evaluates to NaN, and the field renders 0 due to precision rounding — silently hiding the failure.
Real-world example
Live page: https://www.bakingwiththeory.com/calculators/advanced/manual-calculator-round-pizza-ingredients-direct-dough/
The "Total weight of dough" field has:
data-formula="%is_valid% ? %pcs%*%weight%+%field_totale_scarto% : 0"
where field_totale_scarto has:
data-formula="%pcs%*%weight%*%waste%/100"
waste is an optional field (no required attribute, min=0). If the user fills only the required fields and leaves waste empty, field_totale_scarto evaluates to NaN, which propagates and renders the total as 0 g.
Design question for maintainers
What should an empty number-field macro expand to? Options I see:
0 — fixes additive formulas, breaks divisionnull (treated as 0 numerically) — same as above- The field's declared
default — most correct but bigger change
- A per-calculated-field "coerce empty operands to 0" toggle — opt-in, no compat risk
Happy to open a PR once there's direction on which behavior you'd accept.
Cross-reference
Originally reported here: https://github.com/Crocoblock/jfb-is-valid-inputs-field/issues/
Summary
When a calculated field's formula references a macro for an optional number field that the user leaves empty, JetFormBuilder substitutes an empty string into the expression. The resulting JS is malformed and evaluates to
NaN, which then propagates through any dependent calculated fields and renders the visible total as0(orNaN).This is not a
jfb-is-valid-inputs-fieldissue — it reproduces against JetFormBuilder alone.Minimal reproduction
a— required, default4b— not required, no defaultdata-formula="%a%*%b%"anddata-precision="0"b.Expected: the calculated field renders
0(or a documented well-defined value), or the formula is short-circuited.Actual: the substituted expression becomes
4*(empty after*), evaluates toNaN, and the field renders0due to precision rounding — silently hiding the failure.Real-world example
Live page: https://www.bakingwiththeory.com/calculators/advanced/manual-calculator-round-pizza-ingredients-direct-dough/
The "Total weight of dough" field has:
where
field_totale_scartohas:wasteis an optional field (norequiredattribute,min=0). If the user fills only the required fields and leaveswasteempty,field_totale_scartoevaluates toNaN, which propagates and renders the total as0 g.Design question for maintainers
What should an empty number-field macro expand to? Options I see:
0— fixes additive formulas, breaks divisionnull(treated as0numerically) — same as abovedefault— most correct but bigger changeHappy to open a PR once there's direction on which behavior you'd accept.
Cross-reference
Originally reported here: https://github.com/Crocoblock/jfb-is-valid-inputs-field/issues/