Sto cercando alcune linee guida che è possibile utilizzare per determinare quale tipo di ambito utilizzare quando si scrive una nuova direttiva. Idealmente, mi piacerebbe qualcosa di simile a un diagramma di flusso che mi guidi attraverso una serie di domande e faccia apparire la risposta corretta - nessun nuovo nuovo ambito, nuovo ambito figlio o nuovo ambito isolato - ma ciò probabilmente richiede troppo. Ecco la mia attuale serie di linee guida irrisorie:

• Non usare un ambito isolato se l'elemento che utilizzerà la direttiva usa ng-model
  Vedi Posso usare ng-model con ambito isolato?e
  Perché i formattatori non funzionano con un ambito isolato?
• Se la direttiva non modifica alcuna proprietà dell'ambito / modello, non creare un nuovo ambito
• Gli ambiti di isolamento sembrano funzionare bene se la direttiva incapsula un insieme di elementi DOM ( la documentazione dice "una struttura DOM complessa") e la direttiva verrà utilizzata come elemento o senza altre direttive sullo stesso elemento.

Sono consapevole del fatto che l'uso di una direttiva con un ambito isolato su un elemento impone a tutte le altre direttive sullo stesso elemento di utilizzare lo stesso (un) ambito di isolamento, quindi ciò non limita gravemente quando è possibile utilizzare un ambito di isolamento?

Spero che alcuni membri del team Angular-UI (o altri che hanno scritto molte direttive) possano condividere le loro esperienze.

Non aggiungere una risposta che dice semplicemente "usa un ambito isolato per componenti riutilizzabili".

Che bella domanda! Mi piacerebbe piace sentire ciò che gli altri hanno da dire, ma qui ci sono le linee guida che uso.

La premessa per l'alta quota: l'ambito è usato come "colla" che usiamo per comunicare tra il controllore principale, la direttiva e il modello di direttiva.

Ambito genitore: scope: false quindi nessun nuovo scopo

Non lo uso molto spesso, ma come ha detto @MarkRajcok, se la direttiva non accede a nessuna variabile dell'ambito (e ovviamente non ne imposta alcuna!), Per quanto mi riguarda va bene. Questo è utile anche per le direttive sui minori che sono solo utilizzate nel contesto della direttiva padre (anche se ci sono sempre delle eccezioni) e che non hanno un modello. Fondamentalmente qualsiasi cosa con un modello non appartiene alla condivisione di un ambito, perché stai esponendo intrinsecamente tale ambito per l'accesso e la manipolazione (ma sono sicuro che ci sono eccezioni a questa regola).

Ad esempio, ho recentemente creato una direttiva che disegna un'immagine vettoriale (statica) usando una libreria SVG che sto scrivendo. Ha $observedue attributi ( widthe height) e li usa nei suoi calcoli, ma non imposta né legge alcuna variabile di ambito e non ha un modello. Questo è un buon caso d'uso per non creare un altro ambito; non ne abbiamo bisogno, quindi perché preoccuparsi?

Ma in un'altra direttiva SVG, tuttavia, avevo bisogno di un set di dati da utilizzare e dovevo anche memorizzare un po 'di stato. In questo caso, l'utilizzo dell'ambito padre sarebbe irresponsabile (di nuovo, in generale). Quindi invece...

Ambito del bambino: scope: true

Le direttive con ambito figlio sono sensibili al contesto e intendono interagire con l'ambito corrente.

Ovviamente, un vantaggio chiave di questo rispetto a un ambito isolato è che l'utente è libero di usare l'interpolazione su tutti gli attributi che desidera; ad es. l'uso di class="item-type-{{item.type}}"una direttiva con un ambito isolato non funzionerà di default, ma funziona bene su uno con un ambito figlio perché tutto ciò che è interpolato può ancora trovarsi di default nell'ambito genitore. Inoltre, la direttiva stessa può valutare in modo sicuro attributi ed espressioni nel contesto del proprio ambito di applicazione senza preoccuparsi dell'inquinamento o del danno al genitore.

Ad esempio, una descrizione comandi è qualcosa che viene appena aggiunto; un ambito isolato non funzionerebbe (per impostazione predefinita, vedi sotto) perché si prevede che qui utilizzeremo altre direttive o attributi interpolati. La descrizione comandi è solo un miglioramento. Ma il tooltip deve anche impostare alcune cose sull'ambito da usare con una sub-direttiva e / o modello e ovviamente per gestire il proprio stato, quindi sarebbe davvero un male usare l'ambito genitore. O lo stiamo inquinando o danneggiandolo, e nemmeno lo è bueno.

Mi ritrovo a utilizzare gli ambiti figlio più spesso di quelli isolati o parent.

Isolare l'ambito: scope: {}

Questo è per componenti riutilizzabili. :-)

Ma seriamente, penso ai "componenti riutilizzabili" come ai "componenti autonomi". L'intento è che devono essere usati per uno scopo specifico, quindi combinarli con altre direttive o aggiungere altri attributi interpolati al nodo DOM intrinsecamente non ha senso.

Per essere più specifici, tutto ciò che è necessario per questa funzionalità autonoma viene fornito attraverso attributi specifici valutati nel contesto dell'ambito padre; sono stringhe unidirezionali ('@'), espressioni unidirezionali ('&') o associazioni di variabili bidirezionali ('=').

Sui componenti autonomi, non ha senso applicare altre direttive o attributi perché esiste da solo. Il suo stile è regolato dal proprio modello (se necessario) e può essere escluso il contenuto appropriato (se necessario). È autonomo, quindi lo inseriamo in un ambito isolato anche per dire: "Non scherzare con questo. Ti sto dando un'API definita attraverso questi pochi attributi".

Una buona pratica è quella di escludere il maggior numero possibile di elementi basati su template dal collegamento direttiva e dalle funzioni del controller. Ciò fornisce un altro punto di configurazione "simile ad API": l'utente della direttiva può semplicemente sostituire il modello! Le funzionalità sono rimaste tutte uguali e la sua API interna non è mai stata toccata, ma possiamo fare confusione con lo stile e l'implementazione del DOM di cui abbiamo bisogno. ui / bootstrap è un ottimo esempio di come farlo bene perché Peter e Pawel sono fantastici.

Gli ambiti di isolamento sono ottimi anche per la trasclusione. Prendi schede; non sono solo l'intera funzionalità, ma tutto ciò che è al suo interno può essere valutato liberamente dall'ambito padre lasciando le schede (e i riquadri) a fare ciò che vogliono. Le schede hanno chiaramente il loro stato , che appartiene all'ambito (per interagire con il modello), ma quello stato non ha nulla a che fare con il contesto in cui è stato usato - è interamente interno a ciò che rende una direttiva tab una direttiva tab. Inoltre, non ha molto senso usare altre direttive con le schede. Sono schede - e abbiamo già questa funzionalità!

Circondalo con più funzionalità o escludi più funzionalità, ma la direttiva è quella che è già.

Detto questo, dovrei notare che ci sono modi per aggirare alcune delle limitazioni (ovvero le caratteristiche) di un ambito isolato, come ha suggerito @ProLoser nella sua risposta. Ad esempio, nella sezione ambito figlio, ho menzionato l'interpolazione sugli attributi non direttivi che si rompono quando si utilizza un ambito isolato (per impostazione predefinita). Ma l'utente potrebbe, ad esempio, semplicemente utilizzare class="item-type-{{$parent.item.type}}"e funzionerebbe ancora una volta. Quindi, se c'è una ragione convincente per usare un ambito isolato su un ambito figlio ma sei preoccupato per alcune di queste limitazioni, sappi che puoi aggirarle virtualmente tutte, se necessario.

Sommario

Le direttive senza un nuovo ambito sono di sola lettura; sono completamente fidati (cioè interni all'app) e non toccano jack. Le direttive con un ambito figlio aggiungono funzionalità, ma non sono le uniche funzionalità. Infine, gli scopi di isolamento sono per le direttive che rappresentano l'intero obiettivo; sono autonomi, quindi va bene (e la maggior parte "corretta") lasciarli andare canaglia.

Volevo far emergere i miei pensieri iniziali, ma mentre penso a più cose, aggiornerò questo. Ma santa merda - questo è lungo per una risposta SO ...

PS: Totalmente tangenziale, ma dal momento che stiamo parlando di scopi, preferisco dire "prototipico" mentre altri preferiscono "prototipo", che sembra essere più accurato ma non si adatta affatto alla lingua. :-)

La mia politica personale ed esperienza:

Isolato: un sandbox privato

Voglio creare molti metodi e variabili di ambito che vengono utilizzati SOLO dalla mia direttiva e che l'utente non può mai vedere o accedere direttamente. Voglio autorizzare quali dati dell'ambito sono disponibili per me. Posso utilizzare la inclusione per consentire all'utente di tornare indietro nell'ambito genitore (non interessato) . Faccio NON voglio che i miei variabili e metodi accessibili nei bambini transclusa.

Bambino: una sottosezione di contenuto

Voglio creare metodi e variabili di ambito che PU CAN essere accessibili da parte dell'utente, ma non sono rilevanti per la circonda Ambito di applicazione (fratelli e genitori) al di fuori del contesto della mia direttiva. Vorrei anche consentire a TUTTI i dati dell'ambito padre di scorrere in modo trasparente.

Nessuna: direttive semplici di sola lettura

Non ho davvero bisogno di pasticciare con metodi o variabili dell'ambito. Probabilmente sto facendo qualcosa che non ha a che fare con gli ambiti (come la visualizzazione di plugin jQuery semplici, la convalida, ecc.).

Appunti

• Non dovresti lasciare che ngModel o altre cose influenzino direttamente la tua decisione. Puoi eludere il comportamento strano facendo cose come ng-model=$parent.myVal(bambino) o ngModel: '='(isolato).
• Isolate + transclude ripristinerà tutti i comportamenti normali alle direttive dei fratelli e tornerà all'ambito genitore, quindi non lasciare che ciò influisca anche sul tuo giudizio.
• Non scherzare con l'ambito su nessuno perché è come mettere i dati sull'ambito per la metà inferiore del DOM ma non per la metà superiore che ha senso 0.
• Prestare attenzione alle priorità della direttiva (non avere esempi concreti di come ciò può influire sulle cose)
• Iniettare servizi o utilizzare i controller per comunicare attraverso le direttive con qualsiasi tipo di ambito. Puoi anche fare require: '^ngModel'una ricerca negli elementi principali.

Dopo aver scritto molte direttive, ho deciso di usarne meno isolated portata. Anche se è interessante e incapsuli i dati e assicurati di non perdere i dati nell'ambito padre, limita fortemente la quantità di direttive che puoi usare insieme. Così,

Se la direttiva avete intenzione di scrivere si comporterà tutto da solo e non si ha intenzione di condividerlo con altre direttive, andare per ambito isolato . (come un componente puoi semplicemente collegarlo, con poca personalizzazione per lo sviluppatore finale) (diventa molto più complicato quando provi a scrivere sotto-elementi che hanno direttive all'interno)

Se la direttiva che stai per scrivere eseguirà solo manipolazioni dom che non hanno bisogno di uno stato interno dell'ambito o alterazioni esplicite dell'ambito (per lo più cose molto semplici); andare per nessun nuovo ambito . (ad esempio ngShow, ngMouseHover, ngClick, ngRepeat)

Se la direttiva che stai per scrivere deve modificare alcuni elementi nell'ambito genitore, ma deve anche gestire un certo stato interno, scegli un nuovo ambito figlio . (come ngController)

Assicurati di controllare il codice sorgente delle direttive: https://github.com/angular/angular.js/tree/master/src/ng/directive
Aiuta molto su come pensarci

Ho pensato di aggiungere la mia attuale comprensione e come si collega ad altri concetti di JS.

Predefinito (ad es. Non dichiarato o ambito: falso)

Ciò è filosoficamente equivalente all'utilizzo di variabili globali. La tua direttiva può accedere a tutto nel controller principale, ma influisce anche su di essi e allo stesso tempo ne risente.

scopo:{}

Questo è come un modulo, tutto ciò che vuole usare deve essere passato esplicitamente. Se OGNI direttiva che usi è un ambito isolato, può essere l'equivalente di fare OGNI file JS per scrivere il proprio modulo con un sacco di sovraccarico nell'iniezione di tutte le dipendenze.

ambito: bambino

Questa è la via di mezzo tra variabili globali e passthrough esplicito. È simile alla catena di prototipi di JavaScript e ti estende solo una copia dell'ambito padre. Se si crea un ambito isolato e si passa in ogni attributo e funzione dell'ambito padre, è funzionalmente equivalente a questo.

La chiave è che QUALSIASI direttiva può essere scritta IN QUALSIASI modo. Le diverse dichiarazioni di ambito sono lì per aiutarti ad organizzare. Puoi trasformare tutto in un modulo, oppure puoi semplicemente usare tutte le variabili globali ed essere molto attento. Per facilitare la manutenzione è preferibile modulare la logica in parti logicamente coerenti. C'è un equilibrio tra un prato aperto e una prigione chiusa. La ragione per cui questo è complicato, credo, è che quando le persone apprendono ciò pensano che stanno imparando come funzionano le direttive, ma in realtà stanno imparando l'organizzazione del codice / logica.

Un'altra cosa che mi ha aiutato a capire come funzionano le direttive è imparare su ngInclude. ngInclude ti aiuta a includere i parziali html. Quando ho iniziato a usare le direttive ho scoperto che potresti usare l'opzione template per ridurre il tuo codice, ma non stavo davvero collegando alcuna logica.

Naturalmente tra le direttive di Angular e il lavoro del team angular-ui non ho ancora dovuto creare la mia direttiva che fa qualcosa di sostanziale, quindi la mia opinione su questo potrebbe essere completamente sbagliata.

Concordo con Umur. In teoria, gli ambiti isolati sembrano meravigliosi e "portatili", ma nella costruzione della mia app per coinvolgere funzionalità non banali mi sono imbattuto nella necessità di incorporare diverse direttive (alcune nidificate all'interno di altre o l'aggiunta di attributi ad esse) al fine di scrivere completamente nel mio proprio HTML, che è lo scopo di un linguaggio specifico di dominio.

Alla fine, è troppo strano dover passare tutti i valori globali o condivisi lungo la catena con più attributi su ogni invocazione DOM di una direttiva (come richiesto con l'ambito isolato). Sembra stupido scrivere ripetutamente tutto ciò nel DOM e sembra inefficiente, anche se si tratta di oggetti condivisi. Inoltre complica inutilmente le dichiarazioni della direttiva. La soluzione alternativa all'utilizzo di $ parent per "raggiungere" e acquisire valori dalla direttiva HTML sembra Very Bad Form.

Anch'io ho finito per cambiare la mia app per avere direttive per lo più figlio con pochissimi isolati - solo quelli che non hanno bisogno di accedere a NESSUNO dal genitore diverso da quello che possono essere passati attraverso attributi semplici e non ripetitivi.

Avendo sognato il sogno delle lingue specifiche del dominio per decenni prima che ci fosse una cosa del genere, sono euforico che AngularJS fornisca questa opzione e so che, mentre più sviluppatori lavorano in quest'area, vedremo alcune app molto interessanti che sono anche facili da scrivere, espandere e eseguire il debug per i loro architetti.

- D