Secondo https://github.com/angular/angular.js/wiki/Understanding-Scopes , è un problema provare a associare i dati alle primitive associate al proprio $scope :
L’ereditarietà dell’ambito è normalmente semplice, e spesso non è nemmeno necessario sapere che sta accadendo … fino a quando non si prova il binding dei dati a 2 vie (cioè elementi di forma, ng-model) in una primitiva (ad esempio, numero, stringa, booleano) definito sull’ambito principale dall’ambito secondario. Non funziona nel modo in cui la maggior parte della gente si aspetta che funzioni.
- Interrompe genuinamente un elemento dal ribind - dissipare un elemento - AngularJS
- AngularJS: l'elenco ng-repeat non viene aggiornato quando un elemento del modello è giuntato dall'array del modello
- Errore Angularjs Uncaught: durante la migrazione a V1.3
- Direttive di rendering all'interno di $ sce.trustAsHtml
- Quando si scrive una direttiva in AngularJS, come posso decidere se non ho bisogno di un nuovo ambito, un nuovo ambito figlio o un nuovo ambito isolato?
La raccomandazione è
Questo problema con i primitivi può essere facilmente evitato seguendo la “migliore pratica” di avere sempre un “.” nei tuoi modelli-ng
Ora ho questa configurazione molto semplice che viola queste regole:
HTML:
JS:
function MyController($scope) { $scope.theText = ""; $scope.shouldDisable = function () { return $scope.theText.length >= 2; }; }
E ‘davvero brutto? Questo mi farà fregare in un modo orribile quando comincio a provare a usare gli scope dei bambini, in qualche modo?
Devo cambiarlo in qualcosa di simile
function MyController($scope) { $scope.theText = { value: "" }; $scope.shouldDisable = function () { return $scope.theText.value.length >= 2; }; }
e
in modo che segua le migliori pratiche? Quale esempio concreto puoi darmi dove quest’ultimo mi salverà da qualche orribile conseguenza che sarebbe presente nel primo?
Molte cose introducono nuovi scopi. Diciamo che nei tuoi controller, in realtà vuoi aggiungere delle tabs: la prima scheda è il rendering attuale, la seconda scheda è il modulo (in modo da avere un’anteprima in tempo reale).
Decidi di usare una direttiva per questo:
{{theText|formatInSomeWay}}
Beh, sai cosa?
ha il suo ambito e ha rotto il controller! Quindi quando modifichi, angular farà qualcosa di simile in js:$scope.theText = element.val();che non attraverserà la catena del prototipo per cercare di impostare il
theTextsui genitori.EDIT: per essere chiari, sto solo usando “tabs” come esempio. Quando dico ” Molte cose introducono un nuovo ambito”, intendo: ng-include, ng-view, ng-switch, ng-controller (ovviamente), ecc.
Quindi: questo potrebbe non essere necessario sin da ora , perché non hai ancora scope figlio in quella vista, ma non sai se aggiungere o meno template
theText, che potrebbero eventualmente modificare iltheTextstesso, causando il problema. A prova di futuro il tuo design, segui sempre la regola, e non avrai nessuna sorpresa allora;).
Supponiamo che tu abbia gli ambiti M, A e B, dove M è il genitore di entrambi A e B.
Se uno di (A, B) tenta di scrivere sull’oscilloscopio di M, funzionerà solo su tipi non primitivi . La ragione di ciò è che i tipi non primitivi vengono passati per riferimento .
D’altro canto, i tipi primitivi non lo sono, quindi il tentativo di scrivere sul testo theText M creerà una nuova proprietà con lo stesso nome sull’ambito di A o B, invece di scrivere su M. Se entrambi A e B dipendono da questo proprietà, gli errori accadranno, perché nessuno dei due sarebbe a conoscenza di ciò che l’altro sta facendo.