Updating INPUT's "value" doesn't work if it has been edited

[mleibman]

Updating INPUT's "value" doesn't work if it has been edited by the user.
Using node.setAttribute('value', ...) updates the attribute, but doesn't actually change the textbox content.

[ewinslow]

I think this is WAI? You need to pass new String(value) to convince Incremental DOM to set the property.

[mleibman]

Not sure what scenario you have in mind.
I ran into this when patching an already-rendered Soy (Closure templates) template, so no direct interaction with iDOM here. The value got properly detected as "changed", and I can see the "value" attribute on the INPUT changing, but the actual content remains the same. This is WAI for the INPUT, but probably not what we want for the iDOM patch().

[ewinslow]

Ah, I was just thinking since idom always sets string primitives as attributes, you need to pass it a stringy thing that causes typeof value === 'string' to evaluate to false.

elementOpen('input', null, null, 'value', new String('anything')); will do what you want, but if you're just compiling soy to IDOM, then yea, seems like it's out of your hands. :(

[sparhami]

We can make the Soy -> Incremental DOM compilation configure the library to do this by default, but I'd have to look into it a bit. I don't think just setting the value as a property is sufficient, since I think that will change the cursor position on some browsers.

[mleibman]

The alternative (the current behavior) is worse than possible loss of cursor position since it doesn't update at all.

[chrisabrams]

I concur with @mleibman - I want the value updated, then worry about the cursor position :O

[treshugart]

We've had to do this for our usage, too: https://github.com/skatejs/kickflip/blob/49bc55244b70ca09b14e2ff92bc4c73a56866bc1/src/vdom.js#L31. Note that value isn't the only property you'd need to do this for.

[davidjamesstone]

This works for me:

IncrementalDOM.attributes.value = function (el, name, value) {
  el.value = value
}

I thought this was the recommended approach.

[davidjamesstone]

Just bumping this to find out what the current thinking is and to see if there's a plan to fix this in iDOM itself rather than in the libraries that compile to iDOM.

The solution I used (#239 (comment)) no longer seems to work. The new String method works but feels awkward to me.

Personally I think this is an issue that should be fixed at the iDOM layer FWIW.

[treshugart]

FWIW this is what we do: https://github.com/skatejs/skatejs/blob/caff8576081471a79f3cbadc2c10cf10f5d470cd/src/api/vdom.js#L67. We also do this for other attributes / properties that require property setting like checked / disabled.

It might be nice to consider providing common defaults like this, built into iDOM.

[anilanar]

treshugart's list of attributes that require applyProp should definitely be in the incremental-dom itself.

[jannesiera]

Are there any plans to push this fix to incremental-dom itself?

[davidjamesstone]

@sparhami - thanks for all your efforts to date - any comment on the future of this project? There's no roadmap, the website hasn't been updated for a long time and there's been no activity on the repo for the last few months. The npm package hasn't been updated for over a year either. @jridgewell

[blikblum]

Also interested to know the future of the project.

I would not see as a problem at all if the project is discontinued. The JavaScript frontend landscape is an open field where not all ideas fully realizes the initial expectation.

IMO what is important is to clearly communicate if there are still plans for it or if will be discontinued. If discontinued, would be nice to explain the technical reasons that led to this decision.

[jannesiera]

IMO what is important is to clearly communicate if there are still plans for it or if will be discontinued.

I think everyone would be better of if we just knew. The project doesn't seem to be going forward and I would love to have some closure on this.

[blikblum]

For the record, i expanded a bit what i said above in a medium post