Preact: Range Input: Order of Attributes Bug

[mikewesthad]

I stumbled upon a bug while working with Preact today. If you create an input range, the initial render of the slider position may be wrong, depending on the order of the attributes. The value attribute needs to be set after min/max/step. If value is applied before min/max/step are properly set, the value will be forced to match the default min=0/max=100/step=1 on a slider.

E.g. if you create two sliders:

// This one renders with the slider at 0
<input type="range" value={0.5} min="0" max="1" step="0.05" />

// This one renders with the slider at 0.5
<input type="range" min="0" max="1" step="0.05" value={0.5} />

See minimal code to reproduce here

When creating an dom element from a vnode, it looks like attributes are applied one at a time via a for...in loop. Since the ordering of keys in an object is arbitrary, it seems like diffAttributes needs to apply the attributes in a sorted way. I can't think of other potential ordering pitfalls with attributes (maybe the react source code would have insights), but at the very least, applying value last should fix this issue.

[developit]

Interesting! We might also be able to work around this by setting value as an attribute.

[mikewesthad]

@developit - isn't value already being passed as an attribute to diffAttributes? Or did you mean pulling value out into its own vnode property during h?

[developit]

I mean special-casing value like we do type and list:
https://github.com/developit/preact/blob/master/src/dom/index.js#L76

Basically, forcing a value prop from VDOM/JSX to be applied to the DOM using setAttribute() instead of as a property.

[mikewesthad]

Hm, but the problem is the order in which value is applied relative to other attributes, not whether it's applied via prop or attribute (vanilla js example). I might be missing something, but by the time we're in setAccessor, it's too late to adjust the order without doing something async.

[developit]

Interesting, I would have thought the step validation would only apply to the value property, not the attribute itself. You're right, this likely requires a bit of insane workaround magic in diffAttributes.

[mikewesthad]

Happy to contribute a PR to fix it if someone isn't already working on it.

[developit]

That would be awesome.

[gpoitch]

Here's the special input attr cases in react for reference: https://github.com/facebook/react/blob/8ab56e5c8b8f797a6b2bdd4188b4082c55a5190b/src/renderers/dom/stack/client/wrappers/ReactDOMInput.js#L58-L71

[bluemoehre]

I ran into this issue too. When will this be released?

[mbindseil]

plz fix :)

[mikewesthad]

@marvinhagemeister thanks! Closing my PR