Yocker
  1. Yocker
  3. Il mio ng-model ha davvero bisogno di avere un punto per evitare problemi con child $ scope?
Intereting Posts
Dove salvare un JWT in un’applicazione basata su browser e come usarlo Cosa si intende per “funzione pubblica non può essere ignorata se è necessaria una patch” nella descrizione di Addy del modello di modulo rivelatore? Cancella i cookie alla chiusura del browser Escape Special Character in Regex Come creare una barra di avanzamento per una connessione NSURLC quando si scarica un file? Come posso definire il mio controller usando TypeScript? Compilazione C # JIT e .NET L’accesso alla memoria dynamic funziona solo all’interno della funzione Seleziona il valore massimo di ciascun gruppo Calcola il tempo relativo in C # Avvio EC2 nei tempi previsti Come vengono inviati i parametri in una richiesta POST HTTP? Modo corretto per scrivere loop per promise. Espressioni regolari con caratteri ripetuti MySQL – SQL_BIG_SELECTS

Il mio ng-model ha davvero bisogno di avere un punto per evitare problemi con child $ scope?

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.

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 theText sui 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 il theText stesso, 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.