CheckedObserver truthy values and matcher coercion

[aurelia]

CheckedObserver truthy values and matcher coercion

[EisenbergEffect]

The looser comparison seems like it might be the way to go, rather than coercing values.

[fkleuver]

Can you elaborate?

You mean a == b instead of (a+'') === b or?

[EisenbergEffect]

I meant this value === true || value === 'true'. Or is this two separate issues?

[fkleuver]

Yeah it's two separate ones. (a, b) => a === b is the default matcher function for radio input collections and checked arrays. value === true is for single primitive values

The primitive only responds to boolean at the moment. But since checked only responds to boolean, coercion numbers wouldn't make sense anyway, hence the || value === 'true'

The array is a bit broader because it simply looks for equality with the .value attribute, hence the a+''

[EisenbergEffect]

We should get @jdanyow to provide feedback on this. I thought the model properties we set up handled keeping the original types. It was a long time ago that we addressed this issue though.

[fkleuver]

Yep just ran into this with the unit tests. The model property doesn't have this problem so I would only apply the coercion logic for the value attribute. I've always seen the model as a way to support objects, not necessarily for the coercion.
It's possible to solve the coercion with model, but letting that be the only way seems counter-intuitive.

For example:

input.value = 42;
input.value === 42; // false - would become true

input.value = '42';
input.value === 42; // false - would become true

input.value = 42;
input.value === '42'; // true - stays true

input.value = 'true';
input.value === true; // false - would become true

etc..

[bigopon]

Just walked through the comments, I'm not sure how to look at this. Though altering behavior of input.value could be nice, I don't think it's a good idea as it's no longer predictable. That's for our core implementation. In the future, we can allow observer locator to be override-able / extendable and can experiment with all these maybe intuitive behaviors.

[fkleuver]

It's the other way around. Currently it's not predictable because the DOM will coerce values but the observer won't. I'm simply suggesting we should make the observer do the same coercions that the DOM does, so that it becomes predictable :)

[davismj]

Is there any reason we have to use the input.value property for these comparisons? Couldn't we handle all cases the same way we handle model.bind?

[bigopon]

Implicitly converting the value types could be double edged, we better wait until the first request comes to have some concrete case based ideas.