x-model.number inconsistent within a x-text calculation

[MortimerCat]

I have 3 x-model inputs using the number modifier, plus an x-text calculation to display the sum.

I have discovered this only works if the input are entered in the correct sequence. Specifically, until the first item in the expression has a value, the properties are treated as strings and concatenated instead.

The following Codepen demonstrates: To highlight the quirk, I deliberately coded the x-text in reverse order "C+B+A"
https://codepen.io/mortimercat/pen/bGrojrJ

Demo 1:
Enter A=1, B=2 - note the total says "21"
Enter C=3 - The total corrects itself to "6"
Delete C, the total now correctly shows 3

Demo 2: (
Enter C=1, B=2 - the total shows 3 - every thing is working

[SimoTod]

It's more a js thing here. Your code is logically incorrect.
You are saying that the 3 values need to be cast to numbers but your default value is a string.
Note that the casting happens only when you set a new value so, at the very beginning, they won't be converted to 0 (Alpine won't "fix" your default values).

In Js, the + operator is both for sum and concatenation depending on the parameter types so when it's asked to add a number to a string it will switch to concatenation.

I assume you did that because you don't want to show 0 in the field and you prefer an empty input but, in that case, you need to cast the parameter to numbers when you build the operation (For example <span x-text="Number(zc) + Number(zb) + Number(za)"></span>).

[MortimerCat]

I agree that Number(zc) is a fix, but I thought that is what x-model.number="zc" is supposed to be doing?

My other point is the inconsistency- we get different results depending on the order of the operation. Boxes ZA and ZB are happy converting an empty box to 0, only box ZC thinks it is a string. This is what caught me out - My script was happy converting the empty boxes until someone filled in the form backwards!

[SimoTod]

No, x-model.number casts the input to a number when the user enters something in the field and Alpine writes the value back into x-data. The modifier is on the x-model directive, not on the x-data property itself.

You can theoretically write bad code and have multiple x-model directives referring to the same property, some with the number modifier and some without it: only the one with the modifier will cast to number.

What you called inconsistency is a side effect of the incorrect code and how javascript decides whether + is a sum or a concatenation so it was only working by chance.

Javascript evaluates your additions left to right but it only dows 2 operators at the time so A + B + C really means (A + B) + C
What was happening was:
The user enters 1 in field A. 1 + '' = '1' as a string, then '1' + '' = '1'
The user enters 2 in field B. 1 + 2 = 3 as a number, then 3 + '' = '3' as a string
The user enters 4 in field C. 1 + 2 = 3 as a number, then 3 + 4 = 7 as a number

Similarly if you enter B and C but not A, you get: '' + 2 = '2' as a string then '2' + 4 = 24 as a string.

To better understand, try to paste this examples in dev console:
console.log(1 + '' + '', typeof(1 + '' + '')) //1 string
console.log('' + 2 + '', typeof('' + 2 + '')) //2 string
console.log('' + '' + 4, typeof('' + '' + 4)) //4 string
console.log(1 + 2 + '', typeof(1 + 2 + '')) //3 string
console.log(1 + '' + 4, typeof(1 + '' + 4)) //14 string <-- !!!!
console.log('' + 2 + 4, typeof('' + 2 + 4)) //24 string <-- !!!!
console.log(1 + 2 + 4, typeof(1 + 2 + 4)) //7 number

[SimoTod]

Another option that you might like is x-data="{za:null,zb:null,zc:null}"
null is rendered as an empty string in your input box and treated as a 0 when used with + and other null values or numbers.
(But, funny fact, 'ops' + null = 'opsnull' because js is js, lol)