javascript div "Pensare in AngularJS" se ho uno sfondo jQuery?




getelementbyid angularjs (12)

Per descrivere il "cambio di paradigma", penso che una risposta breve possa essere sufficiente.

AngularJS cambia il modo in cui trovi gli elementi

In jQuery , di solito usi i selettori per trovare gli elementi e quindi li leghi:
$('#id .class').click(doStuff);

In AngularJS , usi le direttive per contrassegnare gli elementi direttamente, per collegarli:
<a ng-click="doStuff()">

AngularJS non ha bisogno (o vuole) di trovare elementi usando selettori: la differenza principale tra jqLite di AngularJS e jQuery in piena esecuzione è che jqLite non supporta i selettori .

Quindi, quando la gente dice "non includere affatto jQuery", è principalmente perché non vogliono che tu usi i selettori; vogliono che tu impari ad usare le direttive invece. Diretto, non selezionare!

Supponiamo che io abbia familiarità con lo sviluppo di applicazioni lato client in jQuery , ma ora mi piacerebbe iniziare ad usare AngularJS . Puoi descrivere il cambio di paradigma che è necessario? Ecco alcune domande che potrebbero aiutarti a formulare una risposta:

  • Come faccio a progettare e progettare applicazioni Web lato client in modo diverso? Qual è la più grande differenza?
  • Cosa dovrei smettere di fare / usare; Cosa dovrei iniziare a fare / usare invece?
  • Esistono considerazioni / restrizioni sul lato server?

Non sto cercando un confronto dettagliato tra jQuery e AngularJS .


Ascolta il podcast JavaScript Jabber: Episodio # 32 che presenta i creatori originali di AngularJS: Misko Hevery e Igor Minar. Parlano molto di cosa vuol dire venire ad AngularJS da altri sfondi JavaScript, in particolare jQuery.

Uno dei punti fatti nel podcast ha fatto fare un sacco di cose per me, rispettando la tua domanda:

MISKO : [...] una delle cose che abbiamo pensato molto difficilmente in Angular è, come possiamo fornire un sacco di portelli di fuga in modo da poter uscire e fondamentalmente trovare un modo per uscire da questo. Quindi per noi, la risposta è questa cosa chiamata "Direttive". E con le direttive, diventi essenzialmente un jQuery JavaScript regolare, puoi fare tutto ciò che vuoi.

IGOR : Quindi considera direttiva come l'istruzione al compilatore che la dice ogni volta che ti imbatti in questo determinato elemento o questo CSS nel modello, e mantieni questo tipo di codice e quel codice è responsabile dell'elemento e tutto ciò che si trova sotto quell'elemento nell'albero DOM.

Una trascrizione dell'intero episodio è disponibile al link sopra riportato.

Quindi, per rispondere direttamente alla tua domanda: AngularJS è -molto- supponente ed è un vero framework MV *. Tuttavia, puoi ancora fare tutte le cose veramente interessanti che conosci e che ami con jQuery all'interno delle direttive. Non si tratta di "Come faccio a fare ciò che facevo in jQuery?" tanto quanto è una questione di "Come integrare AngularJS con tutte le cose che facevo in jQuery?"

Sono davvero due stati d'animo molto diversi.


Imperativo → dichiarativo

In jQuery, i selettori vengono utilizzati per trovare gli elementi DOM e quindi associare / registrare gestori di eventi su di essi. Quando un evento si innesca, quel codice (imperativo) viene eseguito per aggiornare / modificare il DOM.

In AngularJS, vuoi pensare alle viste piuttosto che agli elementi DOM. Le viste sono HTML (dichiarativi) che contengono direttive AngularJS. Le direttive impostano i gestori di eventi dietro le quinte per noi e ci forniscono dati dinamici. I selettori vengono usati raramente, quindi la necessità di ID (e alcuni tipi di classi) è notevolmente ridotta. Le viste sono legate ai modelli (tramite gli ambiti). Le viste sono una proiezione del modello. Gli eventi modificano i modelli (ovvero i dati, le proprietà degli ambiti) e le viste che proiettano tali modelli "automaticamente".

In AngularJS, pensa ai modelli, piuttosto che agli elementi DOM selezionati da jQuery che contengono i tuoi dati. Pensa alle viste come a proiezioni di questi modelli, piuttosto che registrare i callback per manipolare ciò che l'utente vede.

Separazione degli interessi

jQuery utilizza JavaScript non invadente : il comportamento (JavaScript) è separato dalla struttura (HTML).

AngularJS utilizza controller e direttive (ognuno dei quali può avere il proprio controller e / o funzioni di compilazione e collegamento) per rimuovere il comportamento dalla vista / struttura (HTML). Angular ha anche servizi e filtri per aiutare a separare / organizzare la tua applicazione.

Vedi anche https://.com/a/14346528/215945

Design dell'applicazione

Un approccio alla progettazione di un'applicazione AngularJS:

  1. Pensa ai tuoi modelli. Crea servizi o i tuoi oggetti JavaScript per quei modelli.
  2. Pensa a come vuoi presentare i tuoi modelli: i tuoi punti di vista. Crea modelli HTML per ogni vista, utilizzando le direttive necessarie per ottenere l'associazione dinamica dei dati.
  3. Collegare un controller a ciascuna vista (utilizzando ng-view e routing o ng-controller). Chiedere al controller di trovare / ottenere solo i dati del modello necessari alla vista per svolgere il proprio lavoro. Riduci al minimo i controller.

Eredità prototipale

Puoi fare molto con jQuery senza sapere come funziona l'ereditarietà prototipale di JavaScript. Quando si sviluppano applicazioni AngularJS, si eviteranno alcune insidie ​​comuni se si ha una buona conoscenza dell'ereditarietà di JavaScript. Letture consigliate: quali sono le sfumature dell'eredità prototipo / prototipo dell'oscilloscopio in AngularJS?


jQuery

jQuery rende comandi JavaScript incredibilmente lunghi come getElementByHerpDerpshort e cross-browser.

AngularJS

AngularJS ti consente di creare tag / attributi HTML che fanno cose che funzionano bene con le applicazioni web dinamiche (poiché HTML è stato progettato per pagine statiche).

Modificare:

Dicendo "Ho uno sfondo jQuery come posso pensare in AngularJS?" è come dire "Ho uno sfondo HTML come faccio a pensare in JavaScript?" Il fatto che tu stia ponendo la domanda mostra che molto probabilmente non capisci gli scopi fondamentali di queste due risorse. Questo è il motivo per cui ho scelto di rispondere alla domanda semplicemente sottolineando la differenza fondamentale piuttosto che passare attraverso la lista dicendo "AngularJS fa uso di direttive considerando che jQuery usa i selettori CSS per creare un oggetto jQuery che fa questo e quello ecc ...." . Questa domanda non richiede una lunga risposta.

jQuery è un modo per semplificare la programmazione di JavaScript nel browser. Brevi comandi cross-browser, ecc.

AngularJS estende l'HTML, quindi non devi metterlo <div>dappertutto solo per creare un'applicazione. Rende l'HTML effettivamente funzionante per le applicazioni piuttosto che per quello per cui è stato progettato, che è statico, pagine web educative. Compie questo in modo indiretto usando JavaScript, ma fondamentalmente si tratta di un'estensione di HTML, non di JavaScript.


1. Non progettare la pagina e quindi modificarla con le manipolazioni del DOM

In jQuery, si progetta una pagina e quindi la si rende dinamica. Questo perché jQuery è stato progettato per l'ampliamento ed è cresciuto incredibilmente da questa semplice premessa.

Ma in AngularJS, devi partire da zero con la tua architettura in mente. Invece di iniziare pensando "Ho questo pezzo del DOM e voglio farlo fare X", devi iniziare con quello che vuoi realizzare, quindi andare a progettare la tua applicazione, e infine andare a progettare la tua vista.

2. Non aumentare jQuery con AngularJS

Allo stesso modo, non iniziare con l'idea che jQuery fa X, Y e Z, quindi aggiungerò semplicemente AngularJS per modelli e controller. Questo è davvero allettante quando sei appena agli inizi, motivo per cui consiglio sempre ai nuovi sviluppatori di AngularJS di non utilizzare jQuery, almeno fino a quando non si abituano a fare cose come "Angular Way".

Ho visto molti sviluppatori qui e sulla mailing list creare queste soluzioni elaborate con plugin jQuery di 150 o 200 righe di codice che poi incollano in AngularJS con una raccolta di callback e $apply che sono confusi e contorti; ma alla fine lo fanno funzionare! Il problema è che nella maggior parte dei casi il plugin jQuery potrebbe essere riscritto in AngularJS in una frazione del codice, dove improvvisamente tutto diventa comprensibile e diretto.

La linea di fondo è questa: quando si risolve, prima "pensa in AngularJS"; se non riesci a pensare a una soluzione, chiedi alla comunità; se dopotutto non c'è una soluzione facile, allora sentiti libero di raggiungere il jQuery. Ma non lasciare jQuery diventare una stampella o non sarai mai padrone di AngularJS.

3. Pensa sempre in termini di architettura

Innanzitutto, sappi che le applicazioni a pagina singola sono applicazioni . Non sono pagine web. Quindi dobbiamo pensare come uno sviluppatore lato server oltre a pensare come uno sviluppatore lato client. Dobbiamo pensare a come dividere la nostra applicazione in componenti singoli, estendibili e testabili.

Allora, come lo fai? Come si "pensa in AngularJS"? Ecco alcuni principi generali, in contrasto con jQuery.

La vista è il "record ufficiale"

In jQuery, cambiamo la vista a livello di programmazione. Potremmo avere un menu a tendina definito come un ul come questo:

<ul class="main-menu">
    <li class="active">
        <a href="#/home">Home</a>
    </li>
    <li>
        <a href="#/menu1">Menu 1</a>
        <ul>
            <li><a href="#/sm1">Submenu 1</a></li>
            <li><a href="#/sm2">Submenu 2</a></li>
            <li><a href="#/sm3">Submenu 3</a></li>
        </ul>
    </li>
    <li>
        <a href="#/home">Menu 2</a>
    </li>
</ul>

In jQuery, nella nostra logica applicativa, lo attiveremmo con qualcosa di simile:

$('.main-menu').dropdownMenu();

Quando guardiamo la vista, non è immediatamente ovvio che ci sia qualche funzionalità qui. Per le piccole applicazioni, va bene. Ma per applicazioni non banali, le cose diventano rapidamente confuse e difficili da mantenere.

In AngularJS, tuttavia, la vista è la registrazione ufficiale della funzionalità basata sulla vista. La nostra dichiarazione ul sembrerebbe invece questa:

<ul class="main-menu" dropdown-menu>
    ...
</ul>

Questi due fanno la stessa cosa, ma nella versione AngularJS chiunque guarda il modello sa cosa dovrebbe succedere. Ogni volta che un nuovo membro del team di sviluppo viene a conoscenza , può guardare a questo e quindi sapere che c'è una direttiva chiamata dropdownMenu opera su di esso; non ha bisogno di intuire la risposta giusta o setacciare alcun codice. La vista ci diceva cosa doveva succedere. Molto più pulito

Gli sviluppatori nuovi di AngularJS spesso fanno una domanda del tipo: come faccio a trovare tutti i collegamenti di un tipo specifico e ad aggiungere una direttiva su di essi. Lo sviluppatore è sempre sbalordito quando rispondiamo: non lo fai. Ma la ragione per cui non lo fai è che questo è come mezzo-jQuery, mezzo-AngularJS, e non va bene. Il problema qui è che lo sviluppatore sta cercando di "fare jQuery" nel contesto di AngularJS. Non funzionerà mai bene La vista è il record ufficiale. Al di fuori di una direttiva (di seguito più avanti), non si modifica mai, mai e poi mai , il DOM. E le direttive vengono applicate nella vista , quindi l'intento è chiaro.

Ricorda: non progettare e quindi contrassegnare. Devi architetto e quindi progettare.

Associazione dati

Questa è di gran lunga una delle più straordinarie caratteristiche di AngularJS e elimina la necessità di eseguire i tipi di manipolazioni DOM che ho menzionato nella sezione precedente. AngularJS aggiornerà automaticamente la tua vista in modo da non dover! In jQuery, rispondiamo agli eventi e quindi aggiorniamo il contenuto. Qualcosa di simile a:

$.ajax({
  url: '/myEndpoint.json',
  success: function ( data, status ) {
    $('ul#log').append('<li>Data Received!</li>');
  }
});

Per una vista simile a questa:

<ul class="messages" id="log">
</ul>

Oltre a mescolare le preoccupazioni, abbiamo anche gli stessi problemi di intenti significanti che ho menzionato prima. Ma ancora più importante, abbiamo dovuto fare riferimento e aggiornare manualmente un nodo DOM. E se vogliamo cancellare una voce di log, dobbiamo codificarci anche contro il DOM. Come testiamo la logica a parte il DOM? E se volessimo cambiare la presentazione?

Questo è un po 'disordinato e un po' fragile. Ma in AngularJS, possiamo fare questo:

$http( '/myEndpoint.json' ).then( function ( response ) {
    $scope.log.push( { msg: 'Data Received!' } );
});

E il nostro punto di vista può assomigliare a questo:

<ul class="messages">
    <li ng-repeat="entry in log">{{ entry.msg }}</li>
</ul>

Ma del resto, il nostro punto di vista potrebbe assomigliare a questo:

<div class="messages">
    <div class="alert" ng-repeat="entry in log">
        {{ entry.msg }}
    </div>
</div>

E ora invece di usare una lista non ordinata, stiamo usando le caselle di avviso Bootstrap. E non abbiamo mai dovuto cambiare il codice del controller! Ma ancora più importante, indipendentemente da dove o come viene aggiornato il registro, anche la vista cambierà. Automaticamente. Neat!

Anche se non l'ho mostrato qui, l'associazione dei dati è bidirezionale. Pertanto, tali messaggi di registro potrebbero essere modificabili anche nella vista: <input ng-model="entry.msg" /> . E c'era molta gioia.

Strato di modello distinto

In jQuery, il DOM è un po 'come il modello. Ma in AngularJS, abbiamo un livello di modello separato che possiamo gestire in qualsiasi modo vogliamo, completamente indipendente dalla vista. Ciò aiuta il suddetto legame ai dati, mantiene la separazione delle preoccupazioni e introduce una testabilità di gran lunga maggiore. Altre risposte hanno menzionato questo punto, quindi mi limiterò a lasciarlo.

Separazione degli interessi

E tutto questo si lega a questo tema fondamentale: mantieni le tue preoccupazioni separate. Il tuo punto di vista funge da record ufficiale di ciò che dovrebbe accadere (per la maggior parte); il tuo modello rappresenta i tuoi dati; si dispone di un livello di servizio per eseguire attività riutilizzabili; fai manipolazione DOM e aumenta la tua visione con le direttive; e lo incolli tutti insieme con i controller. Questo è stato anche menzionato in altre risposte, e l'unica cosa che aggiungerei riguarda la testabilità, che discuterò in un'altra sezione di seguito.

Iniezione di dipendenza

Per aiutarci con la separazione delle preoccupazioni è l' iniezione di dipendenza (DI). Se vieni da un linguaggio server-side (da Java a PHP ) probabilmente hai già familiarità con questo concetto, ma se sei un ragazzo lato client proveniente da jQuery, questo concetto può sembrare qualsiasi cosa, da sciocco a superfluo a hipster . Ma non lo è. :-)

Da una prospettiva ampia, DI significa che è possibile dichiarare i componenti molto liberamente e quindi da qualsiasi altro componente, basta chiedere un'istanza di esso e sarà concesso. Non è necessario conoscere l'ordine di caricamento, i percorsi dei file o simili. Il potere potrebbe non essere immediatamente visibile, ma fornirò un solo esempio (comune): test.

Diciamo che nella nostra applicazione, abbiamo bisogno di un servizio che implementa lo storage sul lato server tramite un'API REST e, a seconda dello stato dell'applicazione, anche dell'archiviazione locale. Quando eseguiamo test sui nostri controller, non vogliamo dover comunicare con il server - stiamo testando il controller , dopo tutto. Possiamo semplicemente aggiungere un servizio fittizio con lo stesso nome del nostro componente originale, e l'iniettore assicurerà che il nostro controllore ottenga automaticamente il falso - il nostro controllore non lo fa e non ha bisogno di sapere la differenza.

A proposito di test ...

4. Sviluppo guidato dal test - sempre

Questo fa davvero parte della sezione 3 sull'architettura, ma è così importante che lo sto mettendo come la sua sezione di primo livello.

Di tutti i molti plugin jQuery che hai visto, usato o scritto, quanti di loro avevano una suite di test di accompagnamento? Non molti perché jQuery non è molto adatto a questo. Ma AngularJS è.

In jQuery, l'unico modo per testare è spesso creare il componente in modo indipendente con una pagina di esempio / demo sulla quale i nostri test possono eseguire la manipolazione del DOM. Quindi, dobbiamo sviluppare separatamente un componente e quindi integrarlo nella nostra applicazione. Che inconveniente! Per la maggior parte del tempo, quando si sviluppa con jQuery, optiamo per iterativo anziché per lo sviluppo basato su test. E chi potrebbe biasimarci?

Ma poiché abbiamo una separazione delle preoccupazioni, possiamo fare lo sviluppo basato su test in modo iterativo in AngularJS! Ad esempio, diciamo che vogliamo una direttiva super-semplice per indicare nel nostro menu qual è il nostro attuale percorso. Possiamo dichiarare ciò che vogliamo nella nostra applicazione:

<a href="/hello" when-active>Hello</a>

Ok, ora possiamo scrivere un test per la direttiva non-esistente when-active :

it( 'should add "active" when the route changes', inject(function() {
    var elm = $compile( '<a href="/hello" when-active>Hello</a>' )( $scope );

    $location.path('/not-matching');
    expect( elm.hasClass('active') ).toBeFalsey();

    $location.path( '/hello' );
    expect( elm.hasClass('active') ).toBeTruthy();
}));

E quando eseguiamo il nostro test, possiamo confermare che fallisce. Solo ora dovremmo creare la nostra direttiva:

.directive( 'whenActive', function ( $location ) {
    return {
        scope: true,
        link: function ( scope, element, attrs ) {
            scope.$on( '$routeChangeSuccess', function () {
                if ( $location.path() == element.attr( 'href' ) ) {
                    element.addClass( 'active' );
                }
                else {
                    element.removeClass( 'active' );
                }
            });
        }
    };
});

Il nostro test ora passa e il nostro menu funziona come richiesto. Il nostro sviluppo è sia iterativo che test-driven. Wicked-cool.

5. Concettualmente, le direttive non sono jQuery pacchettizzate

Sentirai spesso "solo manipolazione DOM in una direttiva". Questa è una necessità. Trattalo con la dovuta deferenza!

Ma tuffiamoci un po 'più in profondità ...

Alcune direttive semplicemente decorano ciò che è già presente nella vista (think ngClass ) e quindi a volte manipolano DOM in modo immediato e quindi vengono sostanzialmente eseguite. Ma se una direttiva è come un "widget" e ha un modello, dovrebbe anche rispettare la separazione delle preoccupazioni. Cioè, anche il modello dovrebbe rimanere ampiamente indipendente dalla sua implementazione nelle funzioni di link e controller.

AngularJS è dotato di un intero set di strumenti per rendere questo molto facile; con ngClass possiamo aggiornare dinamicamente la classe; ngModel consente il collegamento dati bidirezionale; ngShow e ngHide mostrano o nascondono un elemento a livello di programmazione; e molti altri, compresi quelli che scriviamo noi stessi. In altre parole, possiamo fare tutti i tipi di suggestione senza la manipolazione DOM. Minore è la manipolazione del DOM, le verifiche più semplici sono da testare, più facile è lo stile, più è facile cambiarle in futuro e più sono riutilizzabili e distribuibili.

Vedo molti sviluppatori nuovi in ​​AngularJS che usano le direttive come luogo in cui lanciare un sacco di jQuery. In altre parole, pensano "dal momento che non posso manipolare DOM nel controller, prenderò quel codice metterlo in una direttiva". Anche se questo è sicuramente molto meglio, spesso è ancora sbagliato .

Pensa al logger programmato nella sezione 3. Anche se lo inseriamo in una direttiva, vogliamo comunque farlo nella "Angular Way". Ancora non prende alcuna manipolazione DOM! Ci sono molte volte in cui la manipolazione del DOM è necessaria, ma è molto più rara di quanto pensi! Prima di manipolare DOM in qualsiasi punto dell'applicazione, chiediti se è davvero necessario. Potrebbe esserci un modo migliore.

Ecco un rapido esempio che mostra il modello che vedo più frequentemente. Vogliamo un pulsante modificabile. (Nota: questo esempio è un po 'inventato e uno skosh verboso per rappresentare casi più complicati che sono risolti esattamente nello stesso modo.)

.directive( 'myDirective', function () {
    return {
        template: '<a class="btn">Toggle me!</a>',
        link: function ( scope, element, attrs ) {
            var on = false;

            $(element).click( function () {
                on = !on;
                $(element).toggleClass('active', on);
            });
        }
    };
});

Ci sono alcune cose che non vanno in questo:

  1. Innanzitutto, jQuery non è mai stato necessario. Non c'è niente che abbiamo fatto qui che ha richiesto jQuery!
  2. Secondo, anche se abbiamo già jQuery sulla nostra pagina, non c'è motivo di usarlo qui; possiamo semplicemente usare angular.element e il nostro componente funzionerà ancora quando viene rilasciato in un progetto che non ha jQuery.
  3. Terzo, anche supponendo che jQuery fosse necessario affinché questa direttiva funzioni, jqLite ( angular.element ) userà sempre jQuery se fosse caricato! Quindi non abbiamo bisogno di usare $ - possiamo semplicemente usare angular.element .
  4. Quarto, strettamente correlato al terzo, è che gli elementi jqLite non devono essere racchiusi in $ - l' element passato alla funzione link sarebbe già un elemento jQuery!
  5. E quinto, che abbiamo menzionato nelle sezioni precedenti, perché stiamo mescolando i modelli alla nostra logica?

Questa direttiva può essere riscritta (anche per casi molto complicati!) Molto più semplicemente in questo modo:

.directive( 'myDirective', function () {
    return {
        scope: true,
        template: '<a class="btn" ng-class="{active: on}" ng-click="toggle()">Toggle me!</a>',
        link: function ( scope, element, attrs ) {
            scope.on = false;

            scope.toggle = function () {
                scope.on = !scope.on;
            };
        }
    };
});

Ancora una volta, il modello è presente nel modello, quindi tu (oi tuoi utenti) puoi facilmente sostituirlo con uno che soddisfa qualsiasi stile necessario e la logica non è mai stata toccata. Riusabilità - boom!

E ci sono ancora tutti quegli altri vantaggi, come testare: è facile! Indipendentemente dal modello, l'API interna della direttiva non viene mai toccata, quindi il refactoring è semplice. È possibile modificare il modello quanto si desidera senza toccare la direttiva. E non importa cosa cambi, i tuoi test continuano a passare.

w00t!

Quindi se le direttive non sono solo raccolte di funzioni simili a jQuery, quali sono? Le direttive sono in realtà estensioni di HTML . Se HTML non fa qualcosa che ti serve, scrivi una direttiva per farlo per te, e poi usalo come se fosse parte dell'HTML.

In altre parole, se AngularJS non fa qualcosa fuori dalla scatola, pensa a come il team lo realizzerebbe per adattarsi perfettamente a ngClick , ngClass e altri.

Sommario

Non usare nemmeno jQuery. Non includerlo nemmeno. Ti terrà indietro. E quando arrivi a un problema che pensi di sapere come risolvere in jQuery, prima di raggiungere il $ , prova a pensare a come farlo all'interno del AngularJS. Se non lo sai, chiedi! 19 volte su 20, il modo migliore per farlo non richiede jQuery e cercare di risolverlo con risultati di jQuery in più lavoro per te.


jQuery è una libreria di manipolazione DOM.

AngularJS è un framework MV *.

In effetti, AngularJS è uno dei pochi framework MV * JavaScript (molti strumenti JavaScript MVC rientrano ancora nella libreria delle categorie).

Essendo un framework, ospita il tuo codice e prende la proprietà delle decisioni su cosa chiamare e quando!

AngularJS stesso include una edizione jQuery-lite al suo interno. Quindi, per alcune selezioni / manipolazioni DOM di base, non è necessario includere la libreria jQuery (salva molti byte da eseguire sulla rete).

AngularJS ha il concetto di "Direttive" per la manipolazione del DOM e la progettazione di componenti UI riutilizzabili, quindi dovresti usarlo ogni volta che senti il ​​bisogno di fare cose relative alla manipolazione DOM (le direttive sono solo un posto dove dovresti scrivere il codice jQuery mentre usi AngularJS).

AngularJS implica una curva di apprendimento (più di jQuery :-).

-> Per qualsiasi sviluppatore proveniente da background di jQuery, il mio primo consiglio sarebbe "imparare JavaScript come linguaggio di prima classe prima di saltare su un framework ricco come AngularJS!" Ho imparato il fatto sopra nel modo più duro.

In bocca al lupo.


AngularJS e jQuery:

AngularJs e JQuery sono completamente diversi ad ogni livello tranne la funzionalità JQLite e lo vedrai quando inizierai ad imparare le caratteristiche principali di AngularJs (l'ho spiegato in seguito).

AngularJs è un framework lato client che offre la possibilità di creare l'applicazione lato client indipendente. JQuery è una libreria lato client che gioca attorno al DOM.

AngularJs Cool Principle - Se vuoi che alcune modifiche sulla tua interfaccia utente vengano prese in considerazione dal punto di vista del cambiamento dei dati del modello. Cambia i tuoi dati e l'interfaccia utente si renderà nuovamente. Non è necessario giocare intorno a DOM ogni volta, a meno che e fino a quando non sia richiesto e questo dovrebbe anche essere gestito attraverso le direttive angolari.

Per rispondere a questa domanda, voglio condividere la mia esperienza sulla prima applicazione aziendale con AngularJS. Queste sono le caratteristiche più straordinarie che Angular fornisce dove iniziamo a cambiare la nostra mentalità jQuery e otteniamo l'Angolare come una struttura e non come una libreria.

L'associazione dei dati a due vie è sorprendente: avevo una griglia con tutte le funzionalità UPDATE, DELTE, INSERT. Ho un oggetto dati che lega il modello della griglia usando ng-repeat. Hai solo bisogno di scrivere una singola riga di semplice codice JavaScript per eliminare e inserire e il gioco è fatto. la griglia si aggiorna automaticamente quando il modello di griglia cambia istantaneamente. La funzionalità di aggiornamento è in tempo reale, nessun codice per questo. Ti senti fantastico !!!

Le direttive riutilizzabili sono super: scrivi direttive in un unico posto e utilizzale in tutta l'applicazione. OH MIO DIO!!! Ho usato queste direttive per il paging, regex, validazioni, ecc. È davvero fantastico!

Il routing è forte: dipende dalla tua implementazione come vuoi usarlo, ma richiede pochissime righe di codice per instradare la richiesta per specificare HTML e controller (JavaScript)

I controller sono grandi: i controller si prendono cura del proprio codice HTML, ma questa separazione funziona bene per le funzionalità comuni. Se si desidera richiamare la stessa funzione al clic di un pulsante su HTML master, è sufficiente scrivere lo stesso nome di funzione in ciascun controller e scrivere il codice individuale.

Plugin: ci sono molte altre funzioni simili come mostrare una sovrapposizione nella tua app. Non è necessario scrivere codice per questo, basta usare un plug-in overlay disponibile come overlay wc e questo si prenderà automaticamente cura di tutte le richieste XMLHttpRequest (XHR).

Ideale per l' architettura RESTful : l' essere un framework completo rende AngularJS ideale per lavorare con un'architettura RESTful. Chiamare le API REST CRUD è molto più semplice e

Servizi : scrivere codici comuni utilizzando servizi e meno codice nei controller. I sevizi possono essere utilizzati per condividere funzionalità comuni tra i controller.

Estensibilità : Angular ha esteso le direttive HTML utilizzando direttive angolari. Scrivi espressioni in html e valutale in runtime. Crea le tue direttive e i tuoi servizi e usali in un altro progetto senza ulteriori sforzi.


Queste sono alcune risposte molto belle, ma lunghe.

Per riassumere le mie esperienze:

  1. Controller e provider (servizi, fabbriche, ecc.) Servono per modificare il modello di dati, NON HTML.
  2. HTML e direttive definiscono il layout e il binding al modello.
  3. Se è necessario condividere i dati tra i controllori, creare un servizio o una fabbrica, sono singoletti condivisi nell'applicazione.
  4. Se hai bisogno di un widget HTML, crea una direttiva.
  5. Se hai alcuni dati e stai provando ad aggiornare HTML ... STOP! aggiorna il modello e assicurati che il tuo codice HTML sia associato al modello.

jQuery: pensi molto a "QUERYing the DOM " per gli elementi DOM e fai qualcosa.

AngularJS: THE model is the truth, e tu pensi sempre da quell'ANGLE.

Ad esempio, quando si ottengono dati dal server che si intende visualizzare in un formato nel DOM, in jQuery, è necessario '1. TROVA 'dove nel DOM vuoi inserire questi dati, il' 2. AGGIORNA / APPENDA 'lì creando un nuovo nodo o semplicemente impostando il suo innerHTML . Quindi, quando vuoi aggiornare questa vista, allora '3. TROVA 'la posizione e' 4. AGGIORNARE'. Questo ciclo di ricerca e aggiornamento eseguito nello stesso contesto di recupero e formattazione dei dati dal server è disponibile in AngularJS.

Con AngularJS hai il tuo modello (oggetti JavaScript a cui sei già abituato) e il valore del modello ti parla del modello (ovviamente) e della vista, e un'operazione sul modello si propaga automaticamente alla vista, quindi non lo fai Devo pensarci. Ti troverai in AngularJS non trovando più cose nel DOM.

Per dirla in un altro modo, in jQuery, devi pensare ai selettori CSS, cioè, dove è il divo tdche ha una classe o un attributo, ecc., In modo che possa ottenere il loro HTML o colore o valore, ma in AngularJS, ti troverai a pensare in questo modo: di quale modello mi occupo, imposterò il valore del modello sul vero. Non ti preoccuperai se la vista che riflette questo valore è una casella spuntata o risiede in un tdelemento (i dettagli che avresti spesso dovuto pensare in jQuery).

E con la manipolazione del DOM in AngularJS, ti ritrovi ad aggiungere direttive e filtri, che puoi pensare come estensioni HTML valide.

Un'altra cosa che sperimenterai in AngularJS: in jQuery chiami molto le funzioni jQuery, in AngularJS, AngularJS chiamerà le tue funzioni, quindi AngularJS ti dirà come fare le cose, ma i benefici ne valgono la pena, quindi imparare AngularJS di solito significa imparare ciò che AngularJS vuole o il modo in cui AngularJS richiede che tu presenti le tue funzioni e lo chiamerà di conseguenza. Questa è una delle cose che rende AngularJS un framework piuttosto che una libreria.


Puoi descrivere il cambio di paradigma che è necessario?

Imperativo vs dichiarativo

Con jQuery dici al DOM cosa deve succedere, passo dopo passo. Con AngularJS descrivi quali risultati vuoi ma non come farlo. Maggiori informazioni su questo here . Inoltre, controlla la risposta di Mark Rajcok.

Come posso progettare e progettare le app Web lato client in modo diverso?

AngularJS è un intero framework lato client che utilizza il pattern MVC (controlla la loro rappresentazione grafica ). Si concentra molto sulla separazione delle preoccupazioni.

Qual è la più grande differenza? Cosa dovrei smettere di fare / usare; cosa dovrei iniziare a fare / usare invece?

jQuery è una libreria

AngularJS è una bellissima struttura client-side, altamente testabile, che combina tonnellate di cose interessanti come MVC, dipendenza , iniezione di dati e molto altro.

Si concentra sulla separazione delle preoccupazioni e dei test (test unitario e test end-to-end), che facilita lo sviluppo basato sui test.

Il modo migliore per iniziare sta passando attraverso il loro fantastico tutorial . Puoi passare attraverso i passaggi in un paio d'ore; tuttavia, nel caso in cui desideri dominare i concetti dietro le quinte, includono una miriade di riferimenti per ulteriori letture.

Esistono considerazioni / restrizioni sul lato server?

Puoi usarlo su applicazioni esistenti dove stai già utilizzando jQuery puro. Tuttavia, se si desidera sfruttare appieno le funzionalità di AngularJS, è possibile prendere in considerazione la codifica del lato server utilizzando un approccio RESTful .

Ciò consentirà di sfruttare la propria produzione di risorse , che crea un'astrazione API RESTful lato server e rende le chiamate lato server (ottieni, salva, elimina, ecc.) Incredibilmente facile.


Come principiante JavaScript MV * e focalizzato esclusivamente sull'architettura dell'applicazione (non sul lato client / server), raccomanderei senz'altro la seguente risorsa (che sono sorpreso non è stata ancora menzionata): JavaScript Design Patterns , di Addy Osmani , come introduzione a diversi modelli di progettazione JavaScript . I termini utilizzati in questa risposta sono tratti dal documento collegato sopra. Non ho intenzione di ripetere ciò che è stato formulato veramente bene nella risposta accettata. Invece, questa risposta rimanda agli sfondi teorici che alimentano AngularJS (e altre librerie).

Come me, realizzerete rapidamente che AngularJS (o Ember.js , Durandal e altri framework MV *) è una struttura complessa che riunisce molti dei diversi modelli di progettazione JavaScript.

Ho trovato più facile anche testare (1) codice JavaScript nativo e (2) librerie più piccole per ognuno di questi modelli separatamente prima di immergermi in un unico framework globale. Questo mi ha permesso di capire meglio quali sono le questioni cruciali che un framework affronta (perché sei personalmente di fronte al problema).

Per esempio:

  • Programmazione orientata agli oggetti di JavaScript (questo è un link di ricerca di Google). Non è una libreria, ma sicuramente un prerequisito per qualsiasi programmazione applicativa. Mi ha insegnato le implementazioni native dei modelli prototipo, costruttore, singleton e decoratore
  • jQuery / Underscore per il pattern di facciata (come WYSIWYG per manipolare il DOM)
  • Prototype.js per il modello prototipo / costruttore / mix
  • RequireJS / Curl.js per il modello del modulo / AMD
  • KnockoutJS per il pattern osservabile, pubblicazione / sottoscrizione

NB: questo elenco non è completo, né "le migliori librerie"; sono semplicemente le librerie che ho usato. Queste librerie includono anche più schemi, quelli menzionati sono solo i loro focus principali o intenti originali. Se ritieni che manchi qualcosa da questa lista, per favore menzionala nei commenti, e sarò lieto di aggiungerla.


Trovo interessante questa domanda, perché la mia prima seria esposizione alla programmazione JavaScript è stata Node.js e AngularJS. Non ho mai imparato jQuery, e credo sia una buona cosa, perché non devo disimparare nulla. Infatti, evito attivamente soluzioni jQuery ai miei problemi, e invece, cerco solo un "modo AngularJS" per risolverli. Quindi, credo che la mia risposta a questa domanda si ridurrebbe essenzialmente a "pensare come qualcuno che non ha mai imparato jQuery" ed evitare qualsiasi tentazione di incorporare direttamente jQuery (ovviamente AngularJS lo usa in una certa misura dietro le quinte).







angularjs