Loose comparison when early-outing from setting attributes

[tivac]

This is a rough attempt at a fix for #1593, with zero consideration given to potential side-effects. Just something to get started discussing more than anything.

[dead-claudia]

IIRC a similar workaround had to be done in 0.2.

[pygy]

Indeed, there was (top and bottom of the selected range).

There are eslint disable comments around the code because the version of ESLint used in the v0.2 branch was automatically "fixing" them to strict equals. I suppose that doesn't apply here.

[dead-claudia]

@pygy That rule is currently disabled, so you don't have to disable it.

[tivac]

I'm convinced. When I have some time I'll add some tests and merge this.

[pygy]

@isiahmeadows We could enable it now, ESLint stopped "auto-correcting" loose equality when they released v2 (Mithril v0.2 is on ESLintv1.7, Mithril v1 is on ESLint v2).

[dead-claudia]

ESLint's latest is v3.16...I think we should upgrade at some point.

[lhorie]

ESLint is at latest now

[boblehest]

For the record, this breaks m("option", {value: 0}), because 0 == "" (thus the value is ignored.)

[pygy]

@boblehest Could you provide a jsbin that demonstrates the issue?

[boblehest]

@pygy Sure thing: http://jsbin.com/gekipedipa/edit?js,output

The HTML output looks like this:

<select>
    <option value="-1">Minus one</option>
    <option>Zero</option>
    <option value="1">One</option>
</select>

The fix is of course just to stringify your values, which makes sense to do since the value is stored as a string anyway. I'm just mentioning it because this change broke my old code, and because I think using loose comparison is wrong 99% of the time.

[pygy]

Wow, thanks. Loose comparison looked like the correct solution here, but it was assuming a slightly stricter ==.

[dead-claudia]

So, new PR?

It's odd that we have browser inconsistency here, though.

[pygy]

I'm working on it... What's inconsistent? I see the same result in Firefox, Chrome, Safari, Edge14 and IE11.

[dead-claudia]

@pygy I was referring to the original apparent browser bug being fixed by this PR.

[pygy]

Ok, yes, Firefox preserves the cursor position in that case, WebKit derivatives don't...

I'm currently adding tests for this PR before I start fixing the issue raised by @boblehest. The mocks had to be improved (more faithful attributes implementation, optional spies on setters, with a hatch on elements to retrieve them).

[dead-claudia]

@pygy Idea: maybe cast the value to a string before comparing? That might help alleviate this problem while still avoiding a sloppy check.

[pygy]

@isiahmeadows that was the idea, yes... There's a corner case with symbols too (using a symbol as attribute causes a TypeError: Cannot convert a Symbol value to a string, as if one was trying to do the conversion with "" + symbol... I guess we can use value = value === null ? "" : "" + value directly, since having a Symbol will cause the same error later on anyway...

[dead-claudia]

@pygy You can coerce Symbols as well via String(sym), but in general, it's likely erroneous. As for the coercion, I'd do == null rather than === null, to also capture undefined.

[pygy]

@isiahmeadows yes, I know about String(symbol), but do we want to do that? The DOM property setters and setAttribute() do '' + symbol. Strict equality is intentional, to mimic the DOM APIs where passing undefined sets "undefined", whereas null becomes "", which is IMO a wart, but changing that would break B/W compat (and we'd need to do it for every attribute for consistency, not just input/option/select.value... I don't know if there aren't properties with a different behavior. We'd have to special case custom elements, for sure).

[pygy]

Actually, the bin provided by @boblehest works fine since #1828 (on first render, I thought I was going crazy since I couldn't repro the issue in the test suite).

Updating the tree would still break when switching between "" and 0.

[dead-claudia]

@pygy

[...] but do we want to do that?

Sorry if it wasn't clear enough, but I tried to imply a weak "no", more like a -0.5.

[pygy]

#1862 should fix this