Quando si definiscono le direttive in AngularJS, ci sono tre modi diversi per passare le variabili: nessun ambito, ambito ereditato o ambito isolato. Indipendentemente dal fatto che tu stia usando o meno la sintassi “controller as” (e spero che tu lo sia), devi ancora decidere quale usare. In questo post, ti spiego le differenze e suggerisco perché si potrebbe—o non potrebbe—voler utilizzare ciascuno di essi.

Nessun ambito

 scope: false 

L’utilizzo di questo tipo di ambito di direttiva è di solito una cattiva pratica che dovrebbe essere evitata. Quando si sceglie questa opzione, si specifica che la direttiva non ha un proprio ambito e condivide un ambito con il controller padre. Tutto ciò che il controller padre muta o aggiunge all’ambito sarà presente nella direttiva e viceversa.

Il mio precedente post sul blog ha dimostrato un esempio positivo di utilizzo discope: false nelle direttive. In questo esempio, l’ho usato per scambiare in modo pulito DOM nel modello della mia direttiva di primo livello, e tutte le direttive servivano allo stesso semplice scopo (cambiare supereroi) nella mia applicazione. Penso chescope: false possa essere un ottimo modo per introdurre organizzazione e leggibilità in un modello, ma oltre a ciò, usarlo può essere un pendio scivoloso per il codice spaghetti che è difficile da capire.

Ambito ereditato

scope: true

L’ambito ereditato è molto più sicuro per i dati del controller genitore rispetto a nessun ambito. Come con l’opzionescope: false, tutto ciò che esiste nell’ambito del controller padre è presente nella direttiva. Tuttavia, tutto ciò che la direttiva aggiunge all’ambito non è condiviso con l’ambito padre. Ciò protegge i dati del controller principale consentendo al contempo di condividerli con la direttiva.

scope: true è utile in situazioni in cui la direttiva figlio ha lo scopo di mutare i dati sull’ambito padre. Mentre è più sicuro di scope:false, l’uso dell’ambito ereditato, in particolare ripetutamente, è un odore architettonico.

Ambito isolato

scope: { myProperty: '='}

L’ambito isolato è la migliore pratica di tutti. Con questa opzione, il programmatore definisce quali attributi vengono passati alla direttiva. Nient’altro è condiviso tra controller padre e direttiva.

L’ambito isolato incoraggia (e impone) una buona architettura SPA e lo sviluppo di componenti piccoli e focalizzati. L’utilizzo di un ambito isolato (in particolare con la sintassi “controller as”) è un segno di buona architettura e si traduce in una direttiva che sarà facile da convertire in un componente angolare 2.0.

So Quindi, quale uso?

Tutto dipende! In un’applicazione angolare perfetta, si utilizzerebbe un ambito isolato in tutte le direttive. Tuttavia, non tutte le applicazioni sono perfette e non tutte le regole sono assolute.

  • L’utilizzo di nessun ambito può essere utile per organizzare i modelli.
  • L’utilizzo dell’ambito ereditato può aiutarti a non riformulare le direttive dell’ambito. È anche utile per gestire architetture che si concentrano sulla mutazione dei dati lungo l’albero delle direttive piuttosto che restituire piccoli pezzi di dati aggiornati sull’albero al controller padre.
  • Per la migrazione angolare 2.0, è necessario iniziare a lavorare solo utilizzando l’ambito isolato nell’applicazione.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.