How to distinguish between structural changes to array made in parent element vs property changes to an item of array made in child element observer?

[santanubasu]

Apologies in advance if this is not a bug. I believe it is possible this is a bug, but more likely a functionality gap from 1.x to 2.0, and even more likely a knowledge gap on my part, but i have not been able to get a response on any of the other Polymer2 forums, slack channels, stackoverflow, etc.

The summary of the issue with code sample can be seen here:

https://stackoverflow.com/questions/42565640/how-to-distinguish-between-structural-changes-to-array-made-in-parent-element-vs

The code sample itself is here:

https://plnkr.co/edit/iTZqM4GwpASEqQgtRGEk

Steps to repro:

Run the code sample, open the dev console, view the output.

Expected result:

4 observed changes

Actual result:

6 observed changes

Browsers affected:

Chrome at least, probably others

Polymer versions:

2.0, the console output matches the expected result in 1.x

Please let me know if I can clarify the issue further. I really like the direction Polymer is taking and want to use 2.0, but until I can resolve the behaviour in this fairly simple scenario, I'm at a standstill

thanks

[sorvell]

This is expected based on the current implementation of dom-repeat in 2.x. I recognize that the behavior is unexpected and we'll take a look at addressing it.

The 2.x version of dom-repeat has a simpler design than 1.x where this issue did not exist. In the 2.x version, we currently do not act on "splice" information and instead simply update rendered items. Thus, the unshift causes the existing first row to get the newly added item, the 2nd row gets the old first item, and a new 3rd row is added with the previous 2nd row (changes 4, 5, and 6).

[santanubasu]

Great thank you for confirming the current expected behaviour. Pending it being addressed, is there any workaround available that can achieve the underlying goal, which is to act on an object mutation but not on the array mutation?

Ultimately i just want to be able to handle something basic like editing todo list items inside a list, and also rearranging the list, and I have no problem using some temporary code, or even a hack, to do it if I know the functionality will be addressed eventually

[santanubasu]

Roughly speaking, is this issue something that will be addressed by the time 2.0 is released, or after that point? By "addressed" I mean either at the polymer level, or a workaround that can be used short term at the application level. I'm trying to figure out whether Polymer 2.0 will be usable for my projects in the next couple weeks, or if its more like a few months. Thanks, and my bug filing notwithstanding, I really do think the project is on top of things, and once a few issues like this one are addressed, it will mesh very nicely with how I think about app design.

[santanubasu]

Ok I have a workaround of sorts that does the trick for now, Polymer crew can comment on whether this is kosher or not. Basically, I replace an observer such as "observeDescriptionChanged(todo.description)" with "observePropertyChanged(todo.)". Then in the observer itself, I test if the change path is "todo". If it is, this is an indication that the observed change is the result of a mutation of the array containing the todo object, or the initial set of the todo object, or another legitimate change (referentially speaking) of the todo object, but is not* a change or set of a property of an existing todo object. This gets me to where I can act on mutations of the todo object that should result in a persistence action, and ignore mutations of the todo list itself, at least from within the element that encapsulates a single todo entry. I assume this incurs some extra cost if there are a lot of properties that I don't actually need to observe, but I can live with that for now.

[kevinpschaaf]

@santanubasu We have an implementation of a (long requested) restamp mode for <dom-repeat> in https://github.com/Polymer/polymer/pull/4363, which puts dom-repeat in a mode that strictly ties template instances to items (by item identity, or optionally a path to a unique key in the item), and will never reuse instances with a different item. It would be great if you could try that out and provide feedback on whether that addressed your issue or not.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed after being marked stale. If you're still facing this problem with the above solution, please comment and we'll reopen!