Expression parser inconsistency with bracket notation

[ashaffer]

http://plnkr.co/edit/a7BcmCT62CKrnA0o9OpX?p=preview

What is the desired behavior here? It seems like these two should at least be consistent with each other, and probably not throw exceptions in any case.

[btford]

As part of our effort to clean out old issues, this issue is being automatically closed since it has been inactivite for over two months.

Please try the newest versions of Angular (1.0.8 and 1.2.0-rc.1), and if the issue persists, comment below so we can discuss it.

Thanks!

[malcolmocean]

I'm still having this issue with Angular 1.3.0

[btford]

In the case of a.b.c = {}, Angular will create intermediate objects automatically. For a[b].c = {}, Angular will not.

Consider a[b].c – if a is an array of length 3 and b is 52, what should happen? I don't think it makes sense to support the array case at all.

You could support intermediate objects when dereferencing with square braces by adding a bunch of additional type checks, but that makes the semantics of Angular expressions more difficult to reason about. "Square brackets do not create intermediate objects" is in my opinion the more reasonable behavior.

[malcolmocean]

Oh. Perhaps my problem was somewhat different. I just experienced it as impossible to access something by square braces in ng-model for a directive that uses ng-model.

Unfortunately, the key was "2014-07-07"... which means that I can't just use dot notation. I solved it, but it took a fair bit of working around.

[ashaffer]

@btford Why wouldn't you just create [52] in that case, and turn it into a sparse array? Shouldn't that be the programmers responsibility, to ensure that the values that are inputted into the dereference chain are reasonable?

[btford]

For more complicated cases like this, I think it's better to expose methods on a $scope.

You can also now use getters/setters with ngModel which makes this super easy! https://docs.angularjs.org/api/ng/directive/ngModel#binding-to-a-getter-setter

[bvaughn]

Despite the arguments against, I still wish $parse handled this case. (I think it should.) The inconsistency of it is very frustrating. For instance...

// this works
$parse('names[0]').assign({names: ['']}, 'value');

// this also works
$parse('names[0]').assign({names: []}, 'value');

// this fails
$parse('names[0]').assign({}, 'value');

// this also fails
$parse('names[0].name').assign({names: []}, 'value');

// but this works
$parse('names[0].name').assign({names: [{}]}, 'value');

It should be left up to the framework users to determine whether or not to create Arrays in the manner mentioned above.

[bvaughn]

Surprisingly enough, this issue has been fixed in Angular 1.2.22. I was running 1.2.21 at work when I wrote my above comment. At home (running 1.2.22) I realized that my tests all pass.

[rodyhaddad]

It was fixed by #8113