Work-around for major 1.3x ng-options issue?

[pisaacs]

ng-options has major issues in the 1.3x branch (see #9714 and Breaking Changes under '1.4.0-beta.0' in the CHANGELOG: https://github.com/angular/angular.js/blob/master/CHANGELOG.md ).

My Angular 1.3.3 production app just hit a wall with this issue: http://plnkr.co/edit/JCM2NOxxO4OFoWybmQhp?p=preview

angular.module('MyApp', [])

.controller('App', function App($scope, $timeout) {
  $scope.options = null;

  $scope.selected = {
    //try toggling the below IDs

    // works
    //id: 400 

    // DOES NOT work in 1.3x... works in 1.4.0-rc.1+
    id: 1001 // 1002 doesn't work either ... notice 1001 is also a value for 'name'
  };

  // let's pretend ajax call
  $timeout(function() {
    $scope.options = [{
      "id": 400,
      "name": "1001"
    }, {
      "id": 401,
      "name": "1002"
    }, {
      "id": 1001,
      "name": "1003"
    }, {
      "id": 1002,
      "name": "1004"
    }]
  }, 1000);

});

This issue is addressed in 1.4.0-rc.0+. However, while 1.4 continues to bake (and hopefully comes out soon), what would be a possible work around?

[SBero]

When I added track by option.id to the end of the ng-options, it was selecting the option. I forked and updated the plunker here: http://plnkr.co/edit/EGEL1yRIRDauKEOZAzdK?p=preview.

Hopefully this helps resolve your issue.

[pisaacs]

Thanks for trying. I just tested your plnkr.co. It doesn't work for other IDs such as 400 and 401. I don't think select as was made to work with track by.

https://docs.angularjs.org/api/ng/directive/ngOptions (although based on version 1.4)

Do not use select as and track by in the same expression. They are not designed to work together.

[pisaacs]

@petebacondarwin any thoughts on a work-around, since you're perhaps closest to ng-options, having reworked it in 1.4?

[petebacondarwin]

I believe the main problem here is that the select control does not realise that the options have changed.
You can try to force a render manually: http://plnkr.co/edit/qLRvPzJYmLKdCvTUbeoj?p=preview

[pisaacs]

Thanks Pete! The plnkr works as expected. I appreciate your prompt
response. Do you think we'll release a 1.3x patch for this issue?

On Fri, May 8, 2015 at 7:56 AM, Pete Bacon Darwin [email protected]
wrote:

I believe the main problem here is that the select control does not
realise that the options have changed.
You can try to force a render manually:
http://plnkr.co/edit/qLRvPzJYmLKdCvTUbeoj?p=preview

—
Reply to this email directly or view it on GitHub
#11835 (comment)
.

[Narretz]

I'll go out on a limb and say there'll be likely no patch for this. It's simply not worht the effort from my perspective. If someone can provide a patch, I'll be happy to merge it. But that's just my opinion.

[pisaacs]

I guess strictly speaking we already have a patch (7fda214). It's part of the 1.4 release, which hopefully should be released soon (wink wink). So, the key question is can we backport the patch into a 1.3.x patch release? Excluding time and effort, for me I think it comes down to whether the the bigger "risk" is leaving 1.3x ng-options in a faulty state, where apps could show invalid data, or add a patch version with a breaking feature (where the select's "option value" is no longer sequential integers). I say the former outweighs the latter. In addition, 1.4 has many major changes, so it wont be a one and done deal for projects moving to 1.4 solely to address the ng-options issues without encountering unrelated regression issues. Perhaps we can use 7fda214 as a starting point for 1.3.x patch?

[petebacondarwin]

@pisaacs would you like to offer a pull request against 1.3? We are working full steam ahead to get 1.4.0 out the door very soon.

[pisaacs]

@petebacondarwin - would love to give it a shot, but I'm running into issues with environmental dependencies.

I just posted a $30 bounty on Bountysource: https://www.bountysource.com/issues/13596035-work-around-for-major-1-3x-ng-options-issue

The bounty will go to the person whose pull request is a backport of ng-options from 1.4.0-rc.2+ and merged with 1.3.

[Narretz]

Since this is fixed in 1.4, we've decided to not fix this in 1.3, as it would require a huge effort / possibly a breaking change (see e.g. #11171 (comment)), and we think that we will help developers more by improving other areas of angular instead. That said, there are two possible workarounds for this issue:

• use a track by expression: http://plnkr.co/edit/YvAAV90kGSIkbrrG0xWO?p=preview
• force a select controller $render call after setting the collection: http://plnkr.co/edit/ES9aqH3zYMcJCXIUzlfC?p=preview