Framework: repeat.for renders same item twice

[powerbuoy]

I have a strange issue where when I try to push an empty object to an array that is rendered in my view - the newly pushed element is rendered twice.

The duplicate element is in fact the exact same element as the previous one (if I change the first the second also changes).

I'm unable to reproduce this in a GistRun (perhaps version differences) - but I have managed to reproduce it in a completely new Aurelia CLI project with the following code:

app.js

export class App {
    constructor () {
        this.items = [];
        this.editing = false;
    }

    // Toggle the edit form
    toggleEditing () {
        this.editing = !this.editing;

        // Also add a new item
        if (this.editing) {
            this.items.push({}); // NOTE: This is where things go wrong
        }
    }
}

And this view:

app.html

<template>

    <template if.bind="!editing">
        <h2>${items.length} items!</h2>
        <ul>
            <li repeat.for="item of items">
                ${item.name}
            </li>
        </ul>
        <button click.delegate="toggleEditing()">Edit</button>
    </template>

    <template if.bind="editing">
        <ul>
            <li repeat.for="item of items">
                <input type="text" value.bind="item.name">
            </li>
        </ul>
        <button click.delegate="toggleEditing()">Save</button>
    </template>

</template>

My package.json looks like this (for version info):

package.json

{
  "name": "autest",
  "description": "An Aurelia client application.",
  "version": "0.1.0",
  "repository": {
    "type": "???",
    "url": "???"
  },
  "license": "MIT",
  "dependencies": {
    "aurelia-bootstrapper": "^2.1.1",
    "aurelia-animator-css": "^1.0.2",
    "bluebird": "^3.4.1",
    "requirejs": "^2.3.2",
    "text": "github:requirejs/text#latest"
  },
  "peerDependencies": {},
  "devDependencies": {
    "aurelia-cli": "^0.31.3",
    "aurelia-testing": "^1.0.0-beta.3.0.1",
    "aurelia-tools": "^1.0.0",
    "gulp": "github:gulpjs/gulp#4.0",
    "minimatch": "^3.0.2",
    "through2": "^2.0.1",
    "uglify-js": "^3.0.19",
    "vinyl-fs": "^2.4.3",
    "babel-eslint": "^6.0.4",
    "babel-plugin-syntax-flow": "^6.8.0",
    "babel-plugin-transform-decorators-legacy": "^1.3.4",
    "babel-plugin-transform-es2015-modules-amd": "^6.8.0",
    "babel-plugin-transform-es2015-modules-commonjs": "^6.10.3",
    "babel-plugin-transform-flow-strip-types": "^6.8.0",
    "babel-preset-es2015": "^6.13.2",
    "babel-preset-stage-1": "^6.5.0",
    "babel-polyfill": "^6.9.1",
    "babel-register": "^6.24.0",
    "gulp-babel": "^6.1.2",
    "gulp-eslint": "^2.0.0",
    "gulp-htmlmin": "^3.0.0",
    "html-minifier": "^3.2.3",
    "jasmine-core": "^2.4.1",
    "karma": "^0.13.22",
    "karma-chrome-launcher": "^2.2.0",
    "karma-jasmine": "^1.0.2",
    "karma-sourcemap-loader": "^0.3.7",
    "karma-babel-preprocessor": "^6.0.1",
    "browser-sync": "^2.13.0",
    "connect-history-api-fallback": "^1.2.0",
    "debounce": "^1.0.2",
    "gulp-changed-in-place": "^2.0.3",
    "gulp-plumber": "^1.1.0",
    "gulp-rename": "^1.2.2",
    "gulp-sourcemaps": "^2.0.0-alpha",
    "gulp-notify": "^2.2.0",
    "gulp-watch": "^4.3.11"
  }
}

Maybe it's something obvious I've missed? But it seems like a genuine bug to me.

I'm attaching my example app as well which exhibits the bug and can be run in Firefox directly. Just click "Edit" and two input fields will be shown instead of one - changing one actually changes both.

autest.zip

[bigopon]

If you are using [email protected], possibly it's related to aurelia/templating-resources#317

[powerbuoy]

@bigopon I am indeed using 1.5.1. I'm not sure they're related though?

I've simplified my example code slightly. And FYI I'm using Aurelia CLI 0.31.3 (which I believe is the latest version?)

[jwx]

Do you get the same issue if you remove the if-part from the example?

[powerbuoy]

@jwx I do not. Removing the if solves the issue. Also switching to show instead of if solves it - however, show does not appear to work with <template>.

Edit: I guess it might be the exact same issue then?

[jwx]

@powerbuoy Then the problem is probably with if, so yeah, at least related to it. There's a fix in that one that you could try and see if it helps.

[powerbuoy]

Ok, honestly I'm not sure how I would implement the fix? You mean the ifCore override right?

I went ahead and updated all Aurelia packages today (I basically deleted node_modules and just reinstalled everything with my package.json pointing to the latest versions of all packages). I've also got the latest version of node and npm.

However, I still get the same issue as above and now new issues are introduced that also seem related to if.bind. When toggling the visibility of a <template> things (bindings) simply stop working. My app is littered with this code so it isn't really feasible for me to change it all now.

I'm guessing this is the same issue as mentioned in https://github.com/aurelia/templating-resources/issues/317 and https://github.com/aurelia/templating-resources/issues/315

How does one go about rolling back to a previous version? Most of the Aurelia packages aren't in package.json so not sure how their version numbers are controlled?

[mreiche]

How does one go about rolling back to a previous version? Most of the Aurelia packages aren't in package.json so not sure how their version numbers are controlled?

I've spent hours trying to rollback to a previous version with JSPM. Without luck. Problem was, that I'm not able to LOCK a specific version of templating-resources and it's gonna overridden by the dependency tree: aurelia-materialize-bridge -> aurelia-framework -> aurelia-templating -> aurelia-templating-resources.

If you figured out how to rollback, tell me, I will really appreciate that!

[powerbuoy]

I've pretty much swapped out all my if.bind:s to show.bind:s instead and while it meant I had to re-code some stuff that will require rigorous testing it seems to be working at first glance for now at least.

Here's hoping for an official patch soon :)

[mreiche]

I've pretty much swapped out all my if.bind:s to show.bind:s instead and while it meant I had to re-code some stuff that will require rigorous testing it seems to be working at first glance for now at least.

Yes, but that doesn't help for repeat.

[powerbuoy]

I see there's a fix for both https://github.com/aurelia/templating-resources/issues/317 and https://github.com/aurelia/templating-resources/issues/315 out. However, my repeat.for issue, as well as the issues I have with if.bind are not solved by the new release.

I managed to reproduce my issue in gist.run now as well; https://gist.run/?id=af8b192abd4ce89a62fe1383dba79d93

Changing from if.bind to show.bind solves it there too. I'm not 100% sure that gist is using the latest version of everything, but this same thing happens locally with everything updated ([email protected])

[StrahilKazlachev]

@powerbuoy Not released yet.

[powerbuoy]

Ah ok, my bad :) I guess the fix is in templating-resources?

[StrahilKazlachev]

Yes.

[dkent600]

This is happening to me, but has nothing to do with if or show:

The result is that the content is rendered twice for each array item that is added using myArray.push(newItem) after the view has been bound.

What is really weird is that when I do a production build, the bug goes away.

<template>
<div repeat.for='item of myArray'>
    Item
</div> 
</template>

I am on aurelia-templating-resources v1.5.3

[dkent600]

OK, referring to my repro case just above ^^^, I figured out how to make the bug go away, even in my dev build. First, note that this applies to aurelia-typescript-webpack. The change is in webpack.config.js.

The original, that works, looks like this in the entry property:

entry: {
    app: ['aurelia-bootstrapper'],
    vendor: ['bluebird', 'jquery', 'bootstrap'],
  }

What doesn't work, and causes this bug to happen in the development build, is the following:

    entry: {
      app: ['aurelia-bootstrapper'],
      vendor: [
        'bluebird', 
        'aurelia-templating', 
        'aurelia-binding', 
        'aurelia-router', 
        'aurelia-templating-binding', 
        'aurelia-polyfills',
        'aurelia-event-aggregator',
        'bootstrap', 
        'jquery',
        ],
  }

[esmoore68]

I'm still seeing this issue in my app, using [email protected]. This bug is causing me to have to jump through all kinds of hoops to avoid.

[bigopon]

@esmoore68 does it occur with [email protected] ?

@jods4 If it's ok with 1.4.0, then i think repeat has some issue, not the if

[StrahilKazlachev]

I just tried a CLI build with no problems - [email protected].
@esmoore68 please provide a repro of the problem you are facing.

[dkent600]

@StrahilKazlachev You might be able to repro with a webpack.config such as I described above.

[esmoore68]

@StrahilKazlachev, the actual cases (there are many) in my app might be difficult to distill, but I can easily recreate using the test case created by @powerbuoy above.

@bigopon- It still happens with [email protected].

Aurelia entries from my packages.json:

    "aurelia-animator-css": "^1.0.1",
    "aurelia-binding": "^1.5.0",
    "aurelia-bootstrapper": "^2.1.1",
    "aurelia-dialog": "^1.0.0-rc.1.0.3",
    "aurelia-event-aggregator": "^1.0.1",
    "aurelia-fetch-client": "^1.1.1",
    "aurelia-http-client": "^1.0.4",
    "aurelia-templating": "^1.6.0",
    "aurelia-templating-resources": "^1.4.0",
    "aurelia-validation": "^1.0.0",

I am using Typescript and Webpack.

related settings from my webpack.config:

const {AureliaPlugin, ModuleDependenciesPlugin } = require("aurelia-webpack-plugin");

module.exports = {
  entry: "aurelia-bootstrapper",
  },

[BlueManiac]

I also have this problem using a simple

<tr repeat.for="op of operations">
  <td>${op.operationId}</td>
</tr>

The resulting html after pushing two items:

<tr>
    <td>1</td>
</tr>
<tr>
    <td>2</td>
</tr>
<tr>
    <td></td>
</tr>
<tr>
    <td></td>
</tr>

So the "duplicate" rows have no contents.

using:
"aurelia-bootstrapper": "^2.0.1",
"aurelia-fetch-client": "^1.1.3",
"aurelia-framework": "^1.1.5",
"aurelia-loader-webpack": "^2.0.0",
"aurelia-pal": "^1.4.0",
"aurelia-router": "^1.4.0",
"aurelia-templating-resources": "^1.5.4",

[bigopon]

I still cant reproduce it. @esmoore68 @BlueManiac can you confirm that your [email protected] is used ? Maybe check inside node_modules/aurelia-bootstrapper to see if there is any node_modules with templating-resources there.

[StrahilKazlachev]

You can do npm ls aurelia-templating-resources.

[BlueManiac]

Seems to be correct. I removed dist and rebuilt the application, same thing.

npm ls aurelia-templating-resources

+-- [email protected]
| `-- [email protected]  deduped
`-- [email protected]

An interesting note is that if I update the view using HMR the display problem goes away until I add more rows.

[esmoore68]

npm ls aurelia-templating-resources -- [email protected]`

I verified that the version of aurelia-templating-resources being built in to my webpack bundle includes the code changed in the fix that @jods4 made to this module that I _think_ was supposed to address this issue?

https://github.com/aurelia/templating-resources/commit/9548e16bc9ea574bd2e69b65cc5772c341de653a#diff-bbce44daacb259a7b129c4fa0d062406

To be clear, I am using @powerbuoy's test case, but am seeing this behavior all over my app.

[StrahilKazlachev]

Here is how I reproduced it:

1. Create a new webpack/requirejs project using aurelia-cli.
2. Copy&Paste the app.js/html from the first post.

What I saw:

1. Creating new array, lets say like this this.items = [...this.items, [{}]];, instead of mutating the current one makes it work as expected.
2. When using .push the ChangeRecords seem correct to me. Here is one for the 3rd addition:

[{"index":2,"removed":[],"addedCount":1}]

1. If the element with the repeat is not a descendant of an element with an if, all works as expected.
2. I see the same behavior with [email protected].

[jods4]

I see the same behavior with [email protected].

Quite important point to notice because the timing is unlucky. 1.5 contained changes in if with the introduction of else and a few important bugs that got fixed in 1.5.4.

If it reproduces with [email protected] it means the bug is not in the recent if changes but was there before.

[bigopon]

The issue is because instanceChanged and instanceMutated happen at the same time by this.items.push({}) causing repeat to add duplicated view. Temporary workaround is to make sure they don't happen in the same micro task flush via:

  // Toggle the edit form
  toggleEditing () {
    this.editing = !this.editing;

    // Also add a new item
    if (this.editing) {
      setTimeout(() => this.items.push({}));
    }
  }

I'm not sure how to fix this yet 😅

[jods4]

A little out of the blue because I haven't looked at the code in depth but maybe:
instanceMutated should look at what the current instance in the repeat viewmodel is. If it's not the one being mutated, there is a race condition in the notification microtasks and the mutation should be ignored.

EDIT: although that probably wouldn't handle ABA cases, but maybe that's a little far fetched.

[pkkummermo]

I've had the same issue, but not in 1.4.0 of templating-resources (see https://github.com/aurelia/templating/issues/580 for more details)

[cbrownie]

My team has also encountered the issue that @BlueManiac has outlined exactly. We were battling with it for awhile, and ending up reverting our package.json to an earlier working state from about a month ago to get around it. Would be very interested in a fix.

[StrahilKazlachev]

@cbrownie Could you post the versions of aurelia-templating and aurelia-templating-resources with which you don't get this issue?

[cbrownie]

@StrahilKazlachev
These are the aurelia package versions we were using that produced the issue with repeaters and other odd errors.

"aurelia-animator-css": "^1.0.4",
"aurelia-api": "^3.1.1",
"aurelia-bootstrapper": "^2.1.1",
"aurelia-dependency-injection": "^1.3.2",
"aurelia-dialog": "^1.0.0-rc.1.0.3",
"aurelia-event-aggregator": "^1.0.1",
"aurelia-fetch-client": "^1.1.3",
"aurelia-framework": "^1.1.5",
"aurelia-history-browser": "^1.1.0",
"aurelia-http-client": "^1.2.1",
"aurelia-i18n": "^1.6.2",
"aurelia-loader-default": "^1.0.3",
"aurelia-logging": "^1.3.1",
"aurelia-logging-console": "^1.0.0",
"aurelia-pal": "^1.4.0",
"aurelia-pal-browser": "^1.3.0",
"aurelia-path": "^1.1.1",
"aurelia-permission": "^0.5.3",
"aurelia-polyfills": "^1.2.2",
"aurelia-router": "^1.4.0",
"aurelia-templating-binding": "^1.4.0",
"aurelia-templating-resources": "1.5.3",
"aurelia-templating-router": "^1.2.0",
"aurelia-validation": "^1.1.2",

This is a seemingly stable excerpt of our package.json from a couple months ago.

"aurelia-animator-css": "^1.0.0",
"aurelia-api": "^3.1.1",
"aurelia-bootstrapper": "^2.1.1",
"aurelia-dependency-injection": "^1.0.0",
"aurelia-dialog": "^1.0.0-rc.1.0.3",
"aurelia-event-aggregator": "^1.0.0",
"aurelia-fetch-client": "^1.0.0",
"aurelia-framework": "^1.0.0",
"aurelia-history-browser": "^1.0.0",
"aurelia-http-client": "^1.0.0",
"aurelia-i18n": "^1.1.2",
"aurelia-loader-default": "^1.0.0",
"aurelia-logging": "^1.0.0",
"aurelia-logging-console": "^1.0.0",
"aurelia-pal": "^1.0.0",
"aurelia-pal-browser": "^1.0.0",
"aurelia-path": "^1.0.0",
"aurelia-permission": "^0.5.2",
"aurelia-polyfills": "^1.0.0",
"aurelia-router": "^1.0.0",
"aurelia-templating-binding": "^1.0.0",
"aurelia-templating-resources": "^1.0.0",
"aurelia-templating-router": "^1.0.0",

I can't figure out exactly why this revert is fixing the issue because our use of ^ in both instances should be grabbing the same version of aurelia-templating, and aurelia-templating-resources.

On a second look the only package that really changed a major version in our package.json was webpack: "webpack": "^3.8.1" --(back to)--> "webpack": "^2.6.1".

We also upgraded npm itself from a 3.x.x to a 5.x.x version on our Jenkins build server that handled running npm install.

[StrahilKazlachev]

@cbrownie Thanks, that is really strange. I really wanted to easily pinpoint when the problem was introduced 😅.
Also Webpack should not be an issue since I reproduced it with RequireJS.

[phanithinks]

Any update on this. I am trying to call a function in repeat.for. its been called twice, I cant able to replicate it in gist . One interesting thing i observed. when we set break-point on called function. it works fine.

I am using [email protected]

[pkkummermo]

I've had to temporary revert the version due to the numerous places it breaks within our application. Hopefully this issue will be fixed and I can update to the newest :+1:

Just to clarify what I'm reverting:

-        "aurelia-templating": "1.6.0",
-        "aurelia-templating-binding": "1.4.0",
-        "aurelia-templating-resources": "1.5.4",
+        "aurelia-templating": "1.4.2",
+        "aurelia-templating-binding": "1.3.0",
+        "aurelia-templating-resources": "1.4.0",

After this it works perfectly again.

[Alexander-Taran]

@pkkummermo can you check out if it is resolved with latest versions?

[pkkummermo]

Sure, I'll do an upgrade test today :)

[royston-c]

Hi. I am not sure if i am experiencing exactly the same issue detailed in this thread. However, I have an issue with the repeat.for attribute rendering twice in an Aurelia App/Widget (creating via the bootstrap((aurelia: Aurelia) => { //.... })) inside another Aurelia app.

It's almost as if Aurelia is proxying the array functions (push, splice etc) twice. Although it's worth noting that the unexpected HTML elements have no view model (aka they render no values to the DOM). Just like @BlueManiac mentioned in his post dated 13 Nov 2017.

If I create a new array instead of using push, splice, unshift everything works fine. Example that works as expected:

export class BugFixForRepeatingArrayValueConverter {
    public toView(array: any[]) {
        return [].concat(array);
    }
}

<div repeat.for="i of myArray | bugFixForRepeatingArray">
    ${ i }              
</div>

using:
aurelia-binding: 1.7.1 aurelia-templating: 1.7.0 aurelia-templating-binding: 1.4.1 aurelia-templating-resources: 1.6.0

Note: if this widget is not hosted in another Aurelia app everything works as expected.

[Alexander-Taran]

@roy46 could you describe a bit more your double aurelia setup?

[royston-c]

I have a widget class that exposes an init() to start up the component:

import { PLATFORM } from "aurelia-pal";
import { bootstrap } from "aurelia-bootstrapper";
import { Aurelia } from "aurelia-framework";

export default class MyWidget {
    constructor(private config: WidgetConfig) {
    }

    public init() {
        bootstrap((aurelia: Aurelia) => {
            aurelia.use
                .standardConfiguration()
                .developmentLogging();

            aurelia.start().then(() => {
                aurelia.setRoot(PLATFORM.moduleName("widget/app-widget"), this.config.element);
            });
        });
    }
}

Then I have created a test harness (another Aurelia app) that imports and uses that widget. In the test harness I created a wrapper component:

export class WidgetWrapper {

    @bindable public property1: string;
    @bindable public property2: string;
    private _widget: MyWidget ;

    constructor(private element: Element) { }

    public attached() {
        this._widget = new MyWidget({
            element: <HTMLElement>this.element,
            property1: this.property1,
            property2: this.property2
        });

        this._widget.init();
    }
}

[Alexander-Taran]

@roy46 can't explain why, but it looks like a way to disaster (-:

[pkkummermo]

@Alexander-Taran I tried updating to the newest versions, ie

    "aurelia-templating": "^1.7.0",
    "aurelia-templating-binding": "1.4.1",
    "aurelia-templating-resources": "1.6.0",

and I'm afraid the problem still persists. Is there any deps I should be updating alongside these which might cause interference?

[Alexander-Taran]

Ok then. Got nothing to add for the moment.

[pkkummermo]

Cool, let me know if you want me to test anything else.

PS:
Could aurelia-dialog interfere here?

I'm using:

"aurelia-dialog": "1.0.0-rc.1.0.3",

I see in the diff to master now they have explicit versions in their deps. I can try to bump versions and give feedback.

[pkkummermo]

OK. Went through several steps now.

1. Went to the CLI to see if I was missing any dependencies. Added several (which I guess was mostly implicit within the other existing deps).
2. Updated _all_ aurelia-related packages with the exception of the aurelia-webpack-plugin (haven't updated to WP4 yet).
3. Still no go.

Example of a simple dialog with two pushes over time:

(# is #${ $index })
Funny thing is that it correctly shows a normal array and then just doubles up with empty items.

I would have expected something like this:

<empty item>
ITEM2
<empty item>

But it shows as

ITEM 1
ITEM 2
<empty item>
<empty item>

Let me know if you want me to debug anything deeper @Alexander-Taran

[Alexander-Taran]

@pkkummermo will do.. maybe.. if.. and when (-:

[amartens181]

In some components, if I put the function to set the array in the bind method, it will duplicate the first half items. It works correctly in the attached method.

[mikeesouth]

Any updates here? I got the same issue. I have a repeater like so:

<div repeat.for="item of myArray">
  ${item.name}
</div>

I subscribe to the EventAggregator and when an updated array is sent in an event I update myArray like this:

this.myArray.splice(0, this.myArray.length);
updatedArray.forEach(c => this.myArray.push(c));

I specifically did this to not reassign the array but rather clear it and update it. This was to prevent the binding from "being lost" in earlier versions. This causes empty items in my repeater, just like @pkkummermo describes (ITEM1, ITEM2, EMPTY, EMPTY). I can fix this by replacing my splice + push logic to a reassign, like this:
this.myArray = [...updatedArray];

Then it works. But I have to this in several places in my code and it's quite difficult to find them.

Any news on this issue? Will it be fixed or should I just start to convert to reassigning my arrays that I use for repeaters?

[EisenbergEffect]

@bigopon I think this would be a great issue for you to look into :)

[bigopon]

I have fixed this issue by instructing Repeat to ignore mutation while processing instance change (main changes can be found at https://github.com/bigopon/templating-resources/blob/d4ff656a44fd2c2fc4d7b5770f6c036723325b60/src/repeat.js#L138-L142). Code:

    this.ignoreMutation = true;
    this.strategy.instanceChanged(this, items);
    this.observerLocator.taskQueue.queueMicroTask(() => {
      this.ignoreMutation = false;
    });

With the above changes, the issue in @powerbuoy 's demo is fixed, demo at https://gist.run/?id=56d85dc0c87214d1f79b5b284c76308a . Though I haven't been able to create a test for it, I built the code and created a branch at https://github.com/bigopon/templating-resources/tree/fix-repeat so folks who need it can use it to workaround if needed.

@EisenbergEffect @jdanyow @fkleuver / all Would love to have some help on the test here (it always got the number of elements right even without the changes)

---

Edit 1:

Work around the issue temporarily by pasting this in app entry:

import { Repeat } from 'aurelia-templating-resources';


Repeat.prototype.itemsChanged = function() {
  this._unsubscribeCollection();

  if (!this.scope) {
    return;
  }

  var items = this.items;
  this.strategy = this.strategyLocator.getStrategy(items);
  if (!this.strategy) {
    throw new Error('Value for \'' + this.sourceExpression + '\' is non-repeatable');
  }

  if (!this.isOneTime && !this._observeInnerCollection()) {
    this._observeCollection();
  }
  this.ignoreMutation = true;
  this.strategy.instanceChanged(this, items);
  this.observerLocator.taskQueue.queueMicroTask(() => {
    this.ignoreMutation = false;
  })
};

Repeat.prototype.handleCollectionMutated = function(collection, changes) {
  if (!this.collectionObserver) {
    return;
  }
  if (this.ignoreMutation) {
    return;
  }
  this.strategy.instanceMutated(this, collection, changes);
};

[EisenbergEffect]

@bigopon Thanks for looking into this. @jdanyow Can you do a review? This is a critical issue in repeat. If the fix looks good, I'd like to get it out ASAP. Please let me know!

[Alexander-Taran]

@bigopon could it also improve the rendering perf for patial updates?

[bigopon]

@Alexander-Taran That's a nice suggestion. Not sure if ignoring mutation while processing mutation will cause any issue. Will need to investigate a bit

[bigopon]

@Alexander-Taran To answer the main question: I don't think it would have any impact on that.

[Alexander-Taran]

@bigopon this thread: https://github.com/krausest/js-framework-benchmark/pull/376#issuecomment-388396221
last 4-5 comments.
Sometimes partial update benchmark produces way more than 1-2 paints.. and the resultant timing is off charts.

[fkleuver]

I just took a look at this, and the problem is not what it seems.

These two things happen within a single CallScope.evaluate call:

• if.bind set to true -> SetterObserver pushed on the task queue
• Item pushed to the array -> ModifyArrayObserver pushed on the task queue

The task queue is flushed, then:

• It starts with the task for the SetterObserver for the if.bind. This causes the whole lifecycle to be invoked and yields a fully rendered page that is done
• Then comes the task for the ModifyArrayObserver saying "hey we've got a change! add this one item", and it's added. Now we've got two rendered items for one array item.

Any changes that happen after setting an if.bind to true will be applied twice for this reason - the if renders its children with the latest scope values (that inherently include the changes), then the changes are applied in the next task.

Try switching them around

// two text boxes
this.editing = !this.editing;
if (this.editing) {
    this.items.push({});
}

// one text box
const editing = !this.editing;
if (editing) {
    this.items.push({});
}
this.editing = editing;

The same principle applies (although in different forms) when you're doing different operations on the array within the same evaluation cycle.

The changes are queued onto different tasks when instead they should be either on the same task or consolidated into a single changeset.

I would say this is neither a problem in repeat nor in if, but rather a problem in "abusing" the TaskQueue for preventing infinite loops between change handlers. It solves the problem over here and then causes the same problem later over there. Before long, there would be multiple nested calls to the TaskQueue and the problems get increasingly more difficult to solve.

I think the only proper solution is to find a way to eliminate usages of queueMicroTask in the Aurelia framework, rather than adding more of them. This could be simple, but will be tedious - it means an extra parameter needs to be passed around between every observer and change handler that keeps track of the sources and targets of changes. On the flip side, it would likely be a nice performance improvement..

[zefubachs]

I just started using Aurelia using aspnetcore, aurelia-cli and the todo tutorial:
Each time i add a todo to the array it renders another (empty) <li> element after the 'correct' elements of the array.

When i log the amount elements in the array, it shows the correct amount.

Initially i added aurrelia to an existing aspnetcore project but later i reproduced thesame with a simple emtpy aspnetcore project using Visual Studio and then used aurelia-cli using the following properties:

• typescript
• less
• aspnetcore
• webpack
• no minification etc, ...
• restore dependencies

I have no experience with webpack and only little experience with SPA's (used angular1 a while back and tried vuejs) so much of the files created by the cli is like a black box to me.
If any info is required, i'll be happy to supply it.

EDIT:
I've followed thesame steps on my work workstation and everything works fine, i'm gonna try to run the project of my laptop on my workstation and see if any file in the project is the culprit.

[zefubachs]

Managed to fix it by updating nodejs to the latest version.
After that removing the node_modules folder and manually executing npm install.

[shunty-gh]

The same repeat.for issue (duplicating empty elements) is happening in my project even with all the latest aurelia packages (as of 2018-07-10) including the 'ignoreMutation' change. Code had been working fine for many months before updating the binding/templating packages.
I'm guessing it is similar to the "Duplicate of aurelia-binding..." issue mentioned above because I'm using aurelia-breeeze and that has references in package.json to aurelia-binding "^1.0.0-rc.1.0.0" (and several other rc1 references). Thus giving me 2 differing copies of aurelia-binding in my webpack bundle.
Reassigning the array rather than using .push gets around the issue.

[mikeesouth]

@shunty-gh Have you tried a fresh npm install? Remove node_modules and package-lock.json and then a fresh npm install with the new package versions from your updated package.json. I had the same issue but a clean npm install solved the problem.

[shunty-gh]

...and I can confirm that using a local (non npm) copy of aurelia-breeze and, thus, ignoring the outdated dependencies allows the Array.push approach to work fine. And makes my bundle a little smaller too :-)

[shunty-gh]

@mikeesouth Thanks for that. I had tried deleting node_modules and re-running npm install but I hadn't tried removing package-lock.json too.
However, I have now tried and it gives the same erroneous results with repeat.for so I'll stick with the local copy of aurelia-breeze for now.

[ljtn]

This seems to remain unsolved _(EDIT: Issue is solved. Had an old version of aurelia-templating-resources.)_, so here is my workaround in case someone else is stuck here and need a quick fix.

View Model:

<your-element if.bind="!updatingArray" repeat.for="item of items"></your-element>

Data Model:

    this.updatingArray = true;
      setTimeout(() => {
        this.items.push(item);
        this.updatingArray = false;
      },1);

As stated above - it seems like it works as long as the array is re-rendered in its entirety, as it appears to be mutations of the array that triggers the issue.

[fkleuver]

@ljtn could you share your package-lock.json in a gist?

[ljtn]

Sorry, I was using an old version of aurelia-templating-resources (version _1.6.0_.) It works now that I updated to _1.7.1_.

[Mobe91]

What is the status on this? I am using [email protected] and the issue still persists for a simple view like:

<ul>
  <li repeat.for="element of elements">
    test
  </li>
</ul>
<button class="btn btn-ordami-green" click.delegate="add()">Add</button>

export class MyView {
  elements = [];
  add() {
    this.elements.push("test");
  }
}

When I click the "Add" button once, 2 list items are produced instead of just one. No if involved here.

EDIT:
Turns out that the combination of

• [email protected]
• [email protected]

is bad. Using [email protected] my issue is resolved.

[bigopon]

@Mobe91 you should also see the warning about duplicated attempt patching Array prototype if it was causing you issue. If you are using webpack, please see https://github.com/aurelia/cli/pull/906

[bigopon]

@EisenbergEffect I think this can be closed

[Alexander-Taran]

Definitely can be closed