ng-repeat with <option> binding issues #12005
Comments
|
There are some comments here that may be relevant #6088. Is there a reason you are not using ng-options? |
|
I suppose ng-options would work. In general I don't use ng-options, if the data bound is simple. Using ng-options makes the above code (assuming I didn't have to do the $timeout() bit) more complex by requiring a handler to assign the value to the model as well as requiring the nasty, difficult to visually parse ng-options expression syntax. Verfied that ng-options works as expected, but does add a bit of overhead as you have to preassign the object, then add an extra handler to assign the value to the actual underlying model, so that solves my immediate problem. But I still find it curious that ng-repeat binding to options would fail when the data loaded is static. Thanks. |
|
I updated the plunk to show the ng-options version side-by-side with the ng-repeat version. Not that it's important for this example, but I also corrected the default options to have value="" instead of value=" ". |
|
It works when you use |
|
It also works when you use |
Previously, the option would only update if the fallback (the interpolated option text) was used. Now the value attribute will be observed if it contains an interpolation. Closes angular#12005
Previously, the option would only update if the fallback (the interpolated option text) was used. Now the value attribute will be observed if it contains an interpolation. Closes angular#12005
This is for options added without ngOptions. Previously, an option with an interpolated value attribute would not be updated if the binding changed, i.e. the select controller would not recognize the changed option. Now the value attribute will be observed if it contains an interpolation. Closes angular#12005
This is for options added without ngOptions. Previously, an option with an interpolated value attribute would not be updated if the binding changed, i.e. the select controller would not recognize the changed option. Now the value attribute will be observed if it contains an interpolation. Closes angular#12005
This is for options added without ngOptions. Previously, an option with an interpolated value attribute would not be updated if the binding changed, i.e. the select controller would not recognize the changed option. Now the value attribute will be observed if it contains an interpolation. Closes angular#12005
This is for options added without ngOptions. Previously, an option with an interpolated value attribute would not be updated if the binding changed, i.e. the select controller would not recognize the changed option. Now the value attribute will be observed if it contains an interpolation. Closes angular#12005 Closes angular#12582
This is for options added without ngOptions. Previously, an option with an interpolated value attribute would not be updated if the binding changed, i.e. the select controller would not recognize the changed option. Now the value attribute will be observed if it contains an interpolation. Closes angular#12005 Closes angular#12582
I have an odd problem where I cannot get an
ng-modelvalue bound to a<select ng-model>to work against a list bound withng-repeat. I can't duplicate the scenario in a simple plunkr.This plunkr works, but the same code in an app with more complex layout fails with the first list displaying the wrong item in the first list. In my actual application, I see the model values displayed correctly on the bottom but the actual select list always selects DOG. IOW, the model is correct, but the binding in the select list is not.
The only way I've been able to work around this is to use $timeout() to delay assigning the value which works but is ugly:
It appears that ng-model on the list is binding before the list is bound and depending on how quickly the page renders this causes a binding issue. The second list which uses static values bind correctly.
I have run into this a few times now, but it throws me off every single time until I remember that I need to delay binding. This really shouldn't be necessary - is there a better way to accomplish this or possibly a binding bug with a timing issue?
The text was updated successfully, but these errors were encountered: