Related: in Mike's implementation, the cache is invalidated when the value is set. But what if the value has been set to the same value? Should we test for value equality in the setter?

I think this rule will badly interact with granular mutability, so let's see if there is an opinion on that topic emerging. (https://github.com/observablehq/inputs/issues/73#issuecomment-781579922)

So I think pushing granular mutability is too opinionated. Yeah its clear sequential reads should preserve references, but it's not clear when a new object should be created. Its a bit risky delegating this task to the caller/event raiser, so the next appropriate place is the "setter". I can imagine some high performance components might want to reuse the cache object even between sets, but I don't think that should be common practice.

I'd take that test with a pack of salt. It might be safer to test: 1. For objects of type Element, if their interface supports a value property, 2. For any other object, if there is an explicit property definition with a setter. If it isn't, it's probably fair to assume that writes have no effect on the component.

yeah that one was weak sauce. Thanks for the pointers. I think I have a stronger test here now

Careful, HTMLTextAreaElement does not inherit from HTMLInputElement, and neither does HTMLSelectElement. And if we're getting really pedantic, then checkboxes need to fail this test. (As an aside, "for any other object" is of course bull, because we'll either deal with Element or EventTarget).

Ooops I mean HTMLElement, good catch. I also added a test for existence of "addEventListener" on the viewof

Hate to bug you, but that won't suffice either. That condition also applies to html`<div>`.value = "foo"

Native elements may have to be handled explicitely. Haven't found a way to test for interface-defined properties yet.

Correction, this works perfectly well: Object.getPrototypeOf(html`<input>`).hasOwnProperty('value')

Should probably specify that this is only applicable to actions that change a state. Counter examples: "add", "clear", "restart"

I am thrown "Error: expect(received).toBe(expected) // Object.is equality Expected: [] Received: [] Compared values have no visual difference. Note that you are testing for equality with the stricter `toBe` matcher using `Object.is`. For deep equality only, use `toEqual` instead." for the 'select' I repurposed from the standard library (https://observablehq.com/@dleeftink/components). Should expected/received values be the same in this test or should they differ?