2013-02-27 16 views
9

Nel mio rootscope ho una proprietà visible che controlla la visibilità di un div

app.run(function ($rootScope) { 
    $rootScope.visible = false; 
}); 

Esempio HTML:

<section ng-controller='oneCtrl'> 
    <button ng-click='toggle()'>toggle</button> 
    <div ng-show='visible'> 
     <button ng-click='toggle()'>&times;</button> 
    </div> 
</section> 

Controller:

var oneCtrl = function($scope){ 
    $scope.toggle = function() { 
     $scope.visible = !$scope.visible; 
    }; 
} 

La sezione precedente funziona bene, l'elemento è mostrato o nascosto senza problemi. Ora nella stessa pagina in una sezione diversa provo a cambiare la variabile visible per mostrare il div ma non funziona.

<section ng-controller='otherCtrl'> 
    <button ng-click='showDiv()'>show</button> 
</section> 

Controller:

var otherCtrl = function($scope){ 
    $scope.showDiv = function() { 
     $scope.visible = true; 
    }; 
} 
+0

Avete un JSFiddle di questo che possiamo vedere? –

+1

Il mio codice attuale è più grande, qui è solo una versione rapida e breve. – olanod

risposta

22

In AngularJS, $scope s prototipicamente ereditano dal loro ambito padre, tutta la strada fino a $rootScope. In JavaScript, i tipi primitivi sono sovrascritti quando un bambino li modifica. Pertanto, quando si imposta $scope.visible in uno dei controller, la proprietà su $rootScope non è mai stata toccata, ma è stata aggiunta una nuova proprietà visible all'ambito corrente.

In AngularJS, i valori del modello sull'oscilloscopio devono sempre "avere un punto", ovvero oggetti anziché primitive.

Tuttavia, si può anche risolvere il caso iniettando $rootScope:

var otherCtrl = function($scope, $rootScope){ 
    $scope.showDiv = function() { 
    $rootScope.visible = true; 
    }; 
} 
+0

Non volevo iniettare $ rootscope nel controller ma funziona. – olanod

+0

Mantenere un valore in '$ rootScope' probabilmente non è la soluzione migliore. Funzionerà in questo caso, come ho detto, ma potrebbe non essere l'approccio migliore. Senza ulteriori informazioni, però, è difficile dire quale sarebbe la soluzione migliore. –

1

come familiare siete con il concetto di $ portata? A mio avviso, in base al codice, vengono mantenute due variabili $ scope separate denominate "visible" in due ambiti diversi. Ciascuno dei controller ha i propri scopi? Questo è spesso il caso, nel qual caso in realtà stai modificando diverse variabili entrambe denominate "visibili" quando esegui $ scope.visible = true in diversi controller.

Se il visibile è veramente nel rootscope, puoi fare $ rootScope.visible invece di $ scope.visible, ma questo è un po 'disordinato.

Un'opzione è quella di avere la sezione di codice "otherCtrl" in una direttiva (probabilmente lo si deve fare comunque), quindi collegare a due vie l'ambito della direttiva all'ambito padre, che è possibile read up on here. In questo modo sia la direttiva che il controller di pagina utilizzano lo stesso oggetto di ambito.

Per eseguire il debug migliore del $ scope, provare il plug-in Chrome per Angular, denominato Batarang. In questo modo, attraverserai TUTTI i tuoi obiettivi e vedrai il Modello predisposto per te, piuttosto che sperare che tu stia cercando nel posto giusto.

+0

Grazie, ho pensato perché $ rootScope.visible era già inizializzato $ scope.visible sarebbe un riferimento ad esso – olanod

+0

No! Ogni controller dovrebbe avere un ambito $ separato.$ rootScope è accessibile, ma non sono vincolati nel modo in cui si sta descrivendo. Tranne quando si entrano in direttive, è possibile associare le variabili dell'ambito genitore/figlio nel modo in cui si desidera utilizzarle. Vi consiglio comunque di non utilizzare $ rootScope direttamente. –

+1

In realtà, gli ambiti del controller ereditano proprio come gli ambiti direttive, fino a '$ rootScope'. Sono * vincolati al modo in cui @olanod si aspetta; il problema è che in JavaScript, i tipi primitivi vengono sovrascritti nei bambini quando si utilizza l'ereditarietà prototipale, che '$ scope's fa. Ma mi raccomando di non usare '$ rootScope' anche in questo caso - i servizi sono probabilmente una scelta migliore. –

Problemi correlati