Quali parti di funzionalità dovrebbero essere refactored in una direttiva?

Ci sono parecchi motivi per usare una direttiva:

• Il classico: ha bisogno di accedere al DOM / finestra / documento. Tuttavia, questo dovrebbe essere ridotto al minimo, poiché Angular può gestire molte cose tramite il metodo + associazione dati a 2 vie.
• Hai un componente riutilizzabile o uno che potrebbe essere riutilizzato in futuro. Questo dovrebbe essere considerato anche se non ha bisogno di accedere direttamente al DOM, poiché i modelli di direttive sono ancora $compile d nel solito modo e supportano tutti i bind di dati a 2 vie standard.

• Hai un controller o un modello che vorresti in qualche modo trasferire le opzioni a, o chiamare le funzioni o aggiornare i dati sull'ambito genitore, senza inquinare la catena dell'ambito. Puoi utilizzare l'opzione scope quando crei una direttiva per questo, che può gestire i 3 casi più usati

  1. Associazione di una variabile sull'ambito isolato della direttiva all'ambito principale (utilizzando = ). Ad esempio, sospetto che il solito uso di ngModel lo usi in modo che possa modificare l'oggetto del modello secondo necessità.

  2. Creazione di una funzione sull'ambito isolato della direttiva che valuta quindi un'espressione nell'ambito genitore (utilizzando & ). Ad esempio, sospetto che ngClick utilizzi questo per passare un callback alla direttiva.

  3. Associa una variabile sull'ambito isolato della direttiva a una stringa interpolata sull'ambito principale specificato da un attributo (utilizzando @ ). TBH, devo ancora usarlo.

  Se per qualche motivo hai ancora bisogno di accedere direttamente agli attributi dell'elemento, puoi usare l'argomento che è spesso chiamato tAttrs / iAttrs nelle funzioni di compilazione e collegamento. Consulta la documentazione per $ compilazione

• Vorresti applicare una separazione di preoccupazioni tra la logica aziendale e la logica di visualizzazione. Puoi creare un componente tabella generico per mostrare i dati da fonti completamente diverse in diverse parti della tua app. Forse poi aggiungi alcune funzionalità di ordinamento, ecc.
• Ti piacerebbe creare controller di componenti più piccoli e consentire loro di comunicare ancora tra loro, in modo non fragile (rispetto al DOM). L'opzione require durante la creazione di un controller consente ai controller di direttiva di comunicare tra loro. Ad esempio, ngModel deve require un genitore facoltativo ngForm , quindi quindi si registra con il modulo al momento del collegamento, quindi ngForm può elaborare il suo stato di convalida. Se vuoi personalizzare o creare i tuoi input di modulo, puoi require ngModel per comunicare con il suo controller. L'aggiunta di parser o convalida personalizzata sarebbe un tipico caso d'uso per questo.

• Uno che dovrebbe essere usato con parsimonia: se si desidera rendere una variabile o una funzione accessibile a tutti gli ambiti / modelli figlio. Ad esempio, di recente ho creato una direttiva responsive , senza un ambito isolato, che aggiunge una variabile all'ambito, e quindi a tutto l'ambito figlio, che contiene la dimensione corrente della finestra + "classe" (ad esempio, schermo mobile o grande). Questo cambia su un listener debounced + $apply all'evento di ridimensionamento della finestra, quindi gli altri template cambiano solo quando la finestra ha smesso di ridimensionare.

  Un altro caso d'uso per questo, è di aggiungere il routing $state a tutti gli ambiti figlio. L'esempio in link usa run e $rootScope , ma un approccio leggermente più flessibile sarebbe quello di aggiungere questo in una direttiva, quindi in teoria potresti avere una sezione nella tua app senza la variabile $state nel campo di applicazione / template.

Se una delle precedenti affermazioni valesse per il refactoring, allora consideralo definitivamente. Penso che il principale aspetto di quanto sopra sia che i componenti dovrebbero essere piccoli, e avere uno scopo ben definito, e quindi essere abbastanza facili da testare. Se le cose sono lunghe, prendi in considerazione il refactoring delle direttive. I punti sopra hanno a che fare con l'interfaccia. Se disponi di funzionalità aziendali comuni, in genere ciò si verifica nei servizi.

Se è riutilizzabile e manipola il DOM, probabilmente dovrebbe entrare in una direttiva. Ciò ti consente di testarlo una volta, scriverlo una volta e usarlo in più punti. Se ti trovi a fare riferimento a elementi direttamente nel controller, è un buon segno che dovresti andare a una direttiva perché i controllori non dovrebbero interagire direttamente con il DOM.

L'esempio di tabella suona bene - ad esempio nelle nostre app potremmo fare una direttiva di griglia e ridurre la quantità di sforzo necessaria per configurare le impostazioni per una griglia perché sono gestite tramite impostazioni predefinite in modo direzionale.