[dom-parts] Remove .value and .commit(), add replaceChildren

[tbondwilkinson]

@justinfagnani @mfreed7 @sorvell @kevinpschaaf and a few folks from Angular have been thinking about the DOM parts API fresh.

For DOM parts to be minimally viable, the .value write-property and .commit() API are not strictly necessary to get the benefit of having a native API that wraps nodes and node ranges.

As a simplification, these two methods could be removed and frameworks could update DOM nodes directly using the properties available on DOM parts.

For ChildNodePart however, some method of updating all children would be useful, so some replaceChildren() method could be preserved that would update all the children in the node range.

For more information of how this fits into the wider picture, see a new DOM parts proposal that does not include these APIs.

[rniwa]

I don't think we should do this. While I understand you may not need them for your use cases, there are other scenarios where these methods are useful. In particular, being able to commit multiple parts at once is pretty essential in many use cases.

[tbondwilkinson]

I think it's definitely a nice, and new, functionality that doesn't exist yet in the web platform space, but I'm not sure it makes sense to introduce with the first version.

I guess I'd pose the question to you - what use cases (in userland, etc.) in particular is this essential for, where the rest of the proposal would not be as useful without it?

[rniwa]

If we're getting rid of this feature, we might as well as not do this feature at all.

[tbondwilkinson]

Oh I think not doing this feature at all would be a shame! if it's essential to you that "updating multiple parts of the DOM" be in the v1 of this API, I think it's something that warrants discussion, but could very well end up happening. In my discussions with frameworks at Google, that has not been the feedback I've gotten about the direction of a DOM parts API, and most people seem more excited about more performantly locating nodes than updating them.

I think having a feature to more optimally locate nodes for updating is great new feature. I think that being able to make DOM updates more performant is also a great new feature. I just think if I had to plan this out, locating nodes is the logical first feature to land, and updating nodes would be an addition.

[keithamus]

WCCG had their spring F2F in which this was discussed. Present members of WCCG identified an action item to take the topic of DOM Parts and break it out into extended discussions. You can read the full notes of the discussion (#978 (comment)) in which this was discussed, heading entitled "DOM Parts API".

As this issue pertains to DOM parts, I'd like to call out that #999 has been raised for extended discussions and this topic may be discussed during those sessions.