I can make changes to an object displayed in an *ngFor repeater with trackBy ... until I do something to trigger trackBy intervention.

NgForTrackBy indeed does prevent unnecessary DOM updates when the list is refreshed with "new" content that satisfies the trackBy selection criteria.

However, it is a little too rigorous. Once I trigger it, it no longer updates the view with changes to the data-bound object.

Here is a plunker repro.

• Change the name ... both repeater displays update
• Click Refresh Heroes a few times. Each click replaces the heroes list with a new array of hero clones.
• Note the message under the first (no trackBy) display that reports each time the DOM elements have changed.
• Note that no such message appears under the second (with trackBy) display because the DOM elements are untouched. Although the hero objects change, trackBy doesn't replace the DOM elements. That's exactly what we want from trackBy!
• Now change the name again. SAD FACE! The second (with trackBy) display is frozen. The changes do not appear.

This behavior makes ngForTrackBy essentially useless.

• the displayed list is semi-immutability, which fits few if any scenarios
• we can't update the displayed object in any way once frozen
• this is no good for mutable entity scenarios
• this is no good for redux or immutable scenarios either ... because we see only the last mutated state of the entities, not the refreshed entities (as they might be after re-query from a server).

Here is an animated gif showing the unexpected and unwanted behavior.

Notice the last few frames where I make changes _after_ freezing the second trackBy display .