Fix conditions when dom-repeat needs to re-sort or re-filter.

[kaste]

• For efficiency do not process items.length changes
• Ensure observing foo is not triggered by a foobar etc.
• Ensure assignments like items.#2 etc. will trigger a resort/-filter

Fixes #3626.

[kaste]

Note: this goes for least breaking change, and wildcard observing is the only option here, t.i. there is no difference between observing foo or foo.*.

There is something super-confusing to me. Actually set('items.#2', obj)set('items.2', obj) should not reuse the key, it should splice the array, removing what was at index 2 and adding (at the same index) a new object (with a new key). I mean that's the intent of the whole collections vs. arrays thing here. The keys ought to be stable. But... set allows this, and hence we have this issue in the dom-repeater not updating the view.

[ryanwtyler]

@kaste if it didn't reuse the key I'd think you'd get some unexpected behavior with firebase-collection. If you make a change locally, this.set('item.1.prop', val), you'd expect item[1] to have same key before and after but it wouldn't because firebase would call this.set('item.1', obj) and splice in a new object with a new key.

[43081j]

FYI the new polymerfire elements fail badly with dom-repeat because of exactly this. They now iterate through the properties one by one and call set for each.

edit: polymerfire works fine i think

[devinivy]

The problem described here is very similar to an issue I logged a while back #3211

[TimvdLippe]

We would accept a change in 2.x that fixes this behavior, as dom-repeat significantly changed between 1.x and 2.x. The change must probably be made in _handleObservePaths which should cause a render if the path at that point is an empty string aka it's a set of an array element.