Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

strictBindingsCheck throw a error for a optional attribute #16303

Closed
1 of 3 tasks
Marlywoos opened this issue Oct 28, 2017 · 3 comments
Closed
1 of 3 tasks

strictBindingsCheck throw a error for a optional attribute #16303

Marlywoos opened this issue Oct 28, 2017 · 3 comments

Comments

@Marlywoos
Copy link

Marlywoos commented Oct 28, 2017

I'm submitting a ...

  • bug report
  • feature request
  • other (Please do not submit support requests here (see above))

Current behavior:

When update angular from v1.4.8 to v1.6.6, a error thrown:
"[$compile:nonassign] Expression 'undefined' in attribute 'elementId' used with directive 'tiActionMenu' is non-assignable!"
I check the html, there is no elementId attribute in '<ti-action-menu></ti-action-menu>, but the strictComponentBindings is not enabled.

Expected / new behavior:

No error thrown.
Minimal reproduction of the problem with instructions:

AngularJS version: 1.x.y

1.6.6

Browser: [all | Chrome XX | Firefox XX | Edge XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

chrome 62
Anything else:

@gkalpak
Copy link
Member

gkalpak commented Oct 29, 2017

As documented, "if the binding expression is non-assignable, or if the attribute isn't optional and doesn't exist, an exception ($compile:nonassign) will be thrown upon discovering changes to the local value, since it will be impossible to sync them back to the parent scope".

The same behavior applies to older versions, up to (and including) 1.3.x. Early on the 1.4.x release cycle, it was broken, which was reported as a regression in #13367 and fixed for 1.4.9 in #13373.

So, the behavior you see on 1.6.6 is the correct one and is the same you would see with the latest 1.4.x version as well. (I know that such long-standing regressions (remaining in the source code for 9 patch releases) can lead to confusing situations where people start relying on them, but it was clearly a bug, the correct behavior is documented and it should at least be straight forward to fix in your apps.)

@Narretz
Copy link
Contributor

Narretz commented Oct 30, 2017

To clarify, $compile:nonassign is not related to $compileProvider.strictComponentBindingsEnabled. It's a different error that is thrown under other circumstances.

@Marlywoos
Copy link
Author

Marlywoos commented Oct 30, 2017

My fault..., many thanks for your patient reply! ^_^ @gkalpak && @Narretz

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants