Do not set attribute/property value if it hasn't changed

[tjenkinson]

I was setting an <input /> .value back to the new value of the input after the user updated it, and it appears this causes lit-html to actually set the .value (given it changed from the cached one). This works fine in chrome, but on iOS setting the value back to itself appears to cause the cursor to jump to the end of the line.

I wonder if it would be possible to update the place that actually sets a property/value when a change is detected to first read the existing value, and skip setting it if it hasn't changed?

For context here is the current workaround I did to solve the problem, but it would be nice if this change wasn't needed: tjenkinson/redos-detector-demo#34

I think it might just be a change here

lit/packages/lit-html/src/lit-html.ts

Line 1912 in b8ceafb

(this.element as any)[this.name] = value === nothing ? undefined : value;

to go from that to something like

const resolved = value === nothing ? undefined : value;
if ((this.element as any)[this.name] !== resolved) {
  (this.element as any)[this.name] = resolved;
}

Thoughts?

Happy to open a PR/proper issue.

[justinfagnani]

Change detection is an important optimization for us because reading from the DOM is slower than reading from JS.

To disable the change detection and read the previous value from the DOM you can use the live() directive: https://lit.dev/docs/templates/directives/#live

[tjenkinson]

Ah thanks that works! Like you said this has a performance impact though given it's reading on every render.

My change above is a bit different because it still uses the cache by default, but if there's a cache miss, it then does a read. I'm not sure if doing the read then (maybe) write is more expensive than just doing the write?

So this wouldn't really be a performance fix, but it does solve this issue where setting the input .value to the same thing seems to cause iOS to reset the cursor to the end. Edit: I'm assuming it would fix the issue I haven't thoroughly tested it

[tjenkinson]

Although I'm also wondering if reads could still be a bit less expensive than writes in some cases