Direttiva AngularJS vs Service vs Controller


15

Sto per iniziare a implementare una richiesta di modifica sul sito Web interno delle mie aziende, che controllerà un gruppo di campi e li evidenzierà se corrispondono a determinate linee guida. Ad esempio, se la data di nascita è oggi, quel campo verrà delineato e il suggerimento dirà "Auguragli un felice compleanno!".

Le specifiche richiedono che questo venga caricato dopo che il resto della pagina ha terminato il rendering, quindi non aumenterà il tempo di caricamento. Dato che sono nuovo di angularJS, non sono sicuro dei modi "corretti" per farlo.

Problemi:

Poiché ciò include l'aggiunta di bordi, immagini e attributi del titolo (manipolazione DOM), sembra che dovrei usare una direttiva.

Tuttavia, questo non sarà riutilizzabile o "breve" come sembra la maggior parte delle direttive.

La metà dei dati che devo controllare verranno restituiti nella chiamata originale al caricamento della pagina, quindi vorrei salvarlo e non sprecare un'altra chiamata per ottenerlo di nuovo, il che mi fa pensare che un servizio sarebbe utile per archiviare tutti quei dati.

So come fare tutto questo nel controller, ma questo è un brutto codice negativo: P

Qualche idea sul modo migliore per farlo? Fondamentalmente, avrò bisogno di una chiamata http per controllare tutti i dati, che restituiranno un oggetto con valori booleari per ogni tipo di "Call Out" che devo fare. Quindi eseguirò questo elenco e, se il valore è vero, aggiungerò un bordo, un'immagine e il testo della descrizione comandi.

Non sono sicuro che questa domanda sia abbastanza chiara, quindi se vuoi che aggiunga alcuni dettagli, chiedi. Grazie!


1
Perché devi usare solo 1 dei 3? Mi sembra che una combinazione di almeno direttive e servizio / controller sarebbe meglio qui.
Pete,

Anche una combinazione va bene, sono solo confuso su come dovrebbe funzionare.
Bobo,

Mi dispiace questo è nei commenti, non c'è tempo per una risposta corretta. La tua chiamata per effettuare i dati probabilmente andrebbe in un servizio. Tale servizio deve essere iniettato nel controller. Se è necessario fornire una logica alla vista per quei dati, questi vanno nel controller. Infine, la tua vista dovrebbe usare le tue direttive che possono usare qualsiasi logica che potresti aver esposto nel controller.
Pete,

Risposte:


27

Hai ragione, ci sono molte opzioni in gioco.

Un controller è un buon posto per iniziare a scrivere qualcosa di nuovo in angolare. Legare un controller a un markup consente di utilizzare la libreria di direttive già esistente di Angular con i servizi esistenti di Angular.

Dopo un breve periodo di vita, ti renderai conto che il tuo controller è diventato troppo grande. Bene, ora è il momento di refactoring. Ecco le linee guida generali che tendo a seguire.

  • Controller: i controller collegano e gestiscono valori / funzionalità legati al $ scope. In definitiva $ scope tende ad essere fortemente guidato dalla presentazione . IE è un modello di visualizzazione.
  • Servizi: i servizi tendono a legare infrastrutture, back-end o altre funzionalità del browser
  • Direttive: le direttive consentono di integrarsi con eventi / funzionalità DOM non gestiti da gestori esistenti.

Quindi ti consigliamo di inserire il codice in una delle tre direzioni:

  1. Il codice del mio controller è logicamente un altro dato / logica di presentazione e dovrebbe essere diviso in un altro controller . Nota quando si lavora con elementi su $ scope, è meglio separare le parti di cui ciascun controller è responsabile nei propri oggetti su $ scope. Ad esempio $ scope.creditCard. [Blah] per un controller contro $ scope.billingAddress. [Blah] per un altro controller. Questo aiuta a prevenire problemi con l'uso angolare dell'ereditarietà del prototipo su $ scope.

  2. Il codice del mio controller è un pezzo di infrastruttura dell'applicazione o codice di utilità, che potrebbe dover essere condiviso tramite l'app e deve essere suddiviso in un servizio

  3. Il codice del mio responsabile del trattamento si occupa fortemente della presentazione / organizzazione DOM, e pertanto dovrebbe essere suddiviso nella propria direttiva

Un esempio di 1. potrebbe essere quello di gestire l'immissione / convalida della carta di credito separatamente dal resto del modulo di pagamento. Avresti un sacco di logica della carta di credito in un controller separato dalla logica per consentire agli utenti di inserire gli indirizzi, quindi sarebbero controllori logicamente separati.

Un esempio di 2 potrebbe essere quello di spostare la parte che comunica con il servizio di backend della carta di credito per accettare / rifiutare il pagamento. Oppure un altro esempio potrebbe essere un modulo che parla con il back-end per gestire l'API di creazione dell'utente.

Un esempio di 3 potrebbe essere quello di creare una sorta di funzionalità di tabulazione automatica che sposta il cursore tra le 4 caselle di modifica dopo aver inserito i 4 numeri per una carta di credito.

Dividi l'app di conseguenza.


Questo mi ha davvero aiutato a capire di più sull'angolare. Grazie mille :)
Bobo,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.