1. Μην σχεδιάζετε τη σελίδα σας και μετά την αλλάζετε με χειρισμούς DOM.

Στο jQuery, σχεδιάζετε μια σελίδα και στη συνέχεια την κάνετε δυναμική. Αυτό συμβαίνει επειδή η jQuery σχεδιάστηκε για επαύξηση και έχει αναπτυχθεί απίστευτα από αυτή την απλή προϋπόθεση. Αλλά στο AngularJS, πρέπει να ξεκινήσετε από το μηδέν με την αρχιτεκτονική σας στο μυαλό σας. Αντί να ξεκινάτε σκεπτόμενοι "Έχω αυτό το κομμάτι του DOM και θέλω να το κάνω να κάνει X", πρέπει να ξεκινήσετε με αυτό που θέλετε να πετύχετε, μετά να σχεδιάσετε την εφαρμογή σας και τέλος να σχεδιάσετε την προβολή σας.

2. Μην ενισχύετε την jQuery με την AngularJS.

Παρομοίως, μην ξεκινάτε με την ιδέα ότι η jQuery κάνει το X, Y και Z, οπότε θα προσθέσω απλά το AngularJS από πάνω για τα μοντέλα και τους ελεγκτές. Αυτό είναι πραγματικά δελεαστικό όταν μόλις ξεκινάτε, γι' αυτό και πάντα συνιστώ στους νέους προγραμματιστές AngularJS να μην χρησιμοποιούν καθόλου την jQuery, τουλάχιστον μέχρι να συνηθίσουν να κάνουν τα πράγματα με τον "Angular Way". Έχω δει πολλούς προγραμματιστές εδώ και στη λίστα αλληλογραφίας να δημιουργούν αυτές τις περίπλοκες λύσεις με jQuery plugins των 150 ή 200 γραμμών κώδικα που στη συνέχεια κολλάνε στο AngularJS με μια συλλογή από callbacks και $applys που είναι μπερδεμένα και περίπλοκα, αλλά τελικά τα καταφέρνουν να δουλεύουν! Το πρόβλημα είναι ότι στις περισσότερες περιπτώσεις αυτό το jQuery plugin θα μπορούσε να ξαναγραφτεί στο AngularJS σε ένα κλάσμα του κώδικα, όπου ξαφνικά όλα γίνονται κατανοητά και απλά. Το συμπέρασμα είναι το εξής: όταν αναζητάτε λύση, πρώτα "σκεφτείτε σε AngularJS" αν δεν μπορείτε να σκεφτείτε μια λύση, ρωτήστε την κοινότητα- αν μετά από όλα αυτά δεν υπάρχει εύκολη λύση, τότε μη διστάσετε να πιάσετε το jQuery. Αλλά μην αφήσετε το jQuery να γίνει δεκανίκι, αλλιώς δεν θα κατακτήσετε ποτέ το AngularJS.

3. Να σκέφτεστε πάντα με όρους αρχιτεκτονικής

Αρχικά να ξέρετε ότι οι εφαρμογές μίας σελίδας είναι εφαρμογές. Είναι όχι ιστοσελίδες. Επομένως, πρέπει να σκεφτόμαστε σαν προγραμματιστές της πλευράς του διακομιστή εκτός από το να σκεφτόμαστε σαν προγραμματιστές της πλευράς του πελάτη. Πρέπει να σκεφτούμε πώς θα χωρίσουμε την εφαρμογή μας σε επιμέρους, επεκτάσιμα, ελέγξιμα στοιχεία. Τότε λοιπόν πώς το κάνετε αυτό; Πώς "σκέφτεστε σε AngularJS"; Ακολουθούν ορισμένες γενικές αρχές, σε αντιδιαστολή με την jQuery.

Η προβολή είναι το "επίσημο αρχείο&quot,

Στο jQuery, αλλάζουμε προγραμματιστικά την προβολή. Θα μπορούσαμε να έχουμε ένα αναπτυσσόμενο μενού που ορίζεται ως ένα ul όπως παρακάτω:

<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>

Στο jQuery, στη λογική της εφαρμογής μας, θα το ενεργοποιούσαμε με κάτι τέτοιο:

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

Όταν απλά κοιτάμε την προβολή, δεν είναι άμεσα προφανές ότι υπάρχει κάποια λειτουργικότητα εδώ. Για μικρές εφαρμογές, αυτό είναι μια χαρά. Αλλά για μη τετριμμένες εφαρμογές, τα πράγματα γίνονται γρήγορα συγκεχυμένα και δύσκολα συντηρήσιμα. Στο AngularJS, όμως, η προβολή είναι η επίσημη καταγραφή της λειτουργικότητας που βασίζεται στην προβολή. Η δήλωσή μας ul θα έμοιαζε ως εξής:

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

Αυτά τα δύο κάνουν το ίδιο πράγμα, αλλά στην έκδοση AngularJS οποιοσδήποτε κοιτάζει το πρότυπο ξέρει τι'υποτίθεται ότι πρέπει να συμβεί. Κάθε φορά που ένα νέο μέλος της ομάδας ανάπτυξης έρχεται στο σκάφος, μπορεί να κοιτάξει αυτό και στη συνέχεια να ξέρει ότι υπάρχει μια οδηγία που ονομάζεται dropdownMenu που λειτουργεί σε αυτό- δεν χρειάζεται να διαισθανθεί τη σωστή απάντηση ή να κοσκινίσει οποιονδήποτε κώδικα. Η προβολή μας είπε τι έπρεπε να συμβεί. Πολύ πιο καθαρό. Οι προγραμματιστές που είναι νέοι στο AngularJS συχνά κάνουν μια ερώτηση όπως: πώς μπορώ να βρω όλους τους συνδέσμους ενός συγκεκριμένου είδους και να προσθέσω μια οδηγία πάνω τους. Ο προγραμματιστής είναι πάντα κατάπληκτος όταν του απαντάμε: δεν το κάνετε. Αλλά ο λόγος που δεν το κάνετε αυτό είναι ότι αυτό είναι σαν μισή-jQuery, μισή-AngularJS, και δεν είναι καλό. Το πρόβλημα εδώ είναι ότι ο προγραμματιστής προσπαθεί να "κάνει jQuery" στο πλαίσιο του AngularJS. Αυτό δεν πρόκειται ποτέ να λειτουργήσει καλά. Η προβολή είναι το επίσημο αρχείο. Εκτός από μια οδηγία (περισσότερα σχετικά με αυτό παρακάτω), δεν αλλάζετε ποτέ, ποτέ, ποτέ το DOM. Και οι οδηγίες εφαρμόζονται στην προβολή, οπότε η πρόθεση είναι σαφής. Θυμηθείτε: μην σχεδιάζετε και μετά μαρκάρετε. Πρέπει να σχεδιάζετε και μετά να σχεδιάζετε.

Δέσμευση δεδομένων

Αυτό είναι μακράν ένα από τα πιο φοβερά χαρακτηριστικά του AngularJS και κόβει ένα μεγάλο μέρος της ανάγκης να κάνετε τα είδη των χειρισμών του DOM που ανέφερα στην προηγούμενη ενότητα. Το AngularJS θα ενημερώνει αυτόματα την προβολή σας, ώστε να μην χρειάζεται να το κάνετε εσείς! Στην jQuery, ανταποκρινόμαστε σε συμβάντα και στη συνέχεια ενημερώνουμε το περιεχόμενο. Κάτι σαν:

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

Για μια προβολή που μοιάζει κάπως έτσι:

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

Εκτός από την ανάμειξη των ανησυχιών, έχουμε επίσης τα ίδια προβλήματα σηματοδότησης της πρόθεσης που ανέφερα προηγουμένως. Αλλά το πιο σημαντικό είναι ότι έπρεπε να κάνουμε χειροκίνητη αναφορά και ενημέρωση ενός κόμβου DOM. Και αν θέλουμε να διαγράψουμε μια εγγραφή καταγραφής, πρέπει να κωδικοποιήσουμε ενάντια στο DOM και γι' αυτό. Πώς ελέγχουμε τη λογική εκτός από το DOM; Και τι γίνεται αν θέλουμε να αλλάξουμε την παρουσίαση; Αυτό είναι λίγο ακατάστατο και λίγο εύθραυστο. Αλλά στο AngularJS, μπορούμε να το κάνουμε αυτό:

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

Και η προβολή μας μπορεί να μοιάζει κάπως έτσι:

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

Αλλά γι' αυτό το θέμα, η προβολή μας θα μπορούσε να μοιάζει με αυτό:

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

Και τώρα, αντί να χρησιμοποιούμε μια μη ταξινομημένη λίστα, χρησιμοποιούμε πλαίσια ειδοποιήσεων του Bootstrap. Και δεν χρειάστηκε ποτέ να αλλάξουμε τον κώδικα του ελεγκτή! Αλλά το πιο σημαντικό είναι ότι, ανεξάρτητα από το που ή πώς ενημερώνεται το αρχείο καταγραφής, θα αλλάξει και η προβολή. Αυτόματα. Υπέροχα! Αν και δεν το έδειξα εδώ, η δέσμευση δεδομένων είναι αμφίδρομη. Έτσι, αυτά τα μηνύματα καταγραφής θα μπορούσαν επίσης να είναι επεξεργάσιμα στην προβολή ακριβώς με αυτό τον τρόπο: <input ng-model="entry.msg" />. Και υπήρξε μεγάλη χαρά.

Ξεχωριστό επίπεδο μοντέλου

Στην jQuery, το DOM είναι κάτι σαν το μοντέλο. Αλλά στο AngularJS, έχουμε ένα ξεχωριστό στρώμα μοντέλου που μπορούμε να διαχειριστούμε με όποιον τρόπο θέλουμε, εντελώς ανεξάρτητα από την προβολή. Αυτό βοηθάει για την παραπάνω δέσμευση δεδομένων, διατηρεί τον διαχωρισμό των ανησυχιών και εισάγει πολύ μεγαλύτερη δυνατότητα ελέγχου. Άλλες απαντήσεις ανέφεραν αυτό το σημείο, οπότε θα το αφήσω σε αυτό.

Διαχωρισμός των ανησυχιών

Και όλα τα παραπάνω συνδέονται με αυτό το γενικότερο θέμα: κρατήστε τις ανησυχίες σας χωριστά. Η προβολή σας ενεργεί ως η επίσημη καταγραφή του τι υποτίθεται ότι πρέπει να συμβεί (ως επί το πλείστον)- το μοντέλο σας αντιπροσωπεύει τα δεδομένα σας- έχετε ένα επίπεδο υπηρεσιών για να εκτελείτε επαναχρησιμοποιήσιμες εργασίες- κάνετε χειρισμό του DOM και ενισχύετε την προβολή σας με οδηγίες- και τα ενώνετε όλα μαζί με ελεγκτές. Αυτό αναφέρθηκε και σε άλλες απαντήσεις, και το μόνο πράγμα που θα πρόσθετα αφορά τη δυνατότητα ελέγχου, την οποία συζητώ σε άλλη ενότητα παρακάτω.

Έγχυση εξαρτήσεων

Για να μας βοηθήσει με τον διαχωρισμό των ανησυχιών είναι η dependency injection (DI). Αν έρχεστε από μια γλώσσα server-side (από Java έως PHP) πιθανόν να είστε ήδη εξοικειωμένοι με αυτή την έννοια, αλλά αν είστε τύπος της client-side που προέρχεται από την jQuery, αυτή η έννοια μπορεί να σας φανεί από ανόητη έως περιττή έως hipster. Αλλά δεν είναι :-) Από μια ευρεία προοπτική, το DI σημαίνει ότι μπορείτε να δηλώσετε συστατικά πολύ ελεύθερα και στη συνέχεια, από οποιοδήποτε άλλο συστατικό, απλά να ζητήσετε ένα instance του και θα σας χορηγηθεί. Δεν χρειάζεται να γνωρίζετε για τη σειρά φόρτωσης, ή τις θέσεις των αρχείων, ή οτιδήποτε παρόμοιο. Η δύναμη μπορεί να μην είναι άμεσα ορατή, αλλά θα σας δώσω μόνο ένα (κοινό) παράδειγμα: τις δοκιμές. Ας υποθέσουμε ότι στην εφαρμογή μας, χρειαζόμαστε μια υπηρεσία που υλοποιεί αποθήκευση από την πλευρά του διακομιστή μέσω ενός REST API και, ανάλογα με την κατάσταση της εφαρμογής, και τοπική αποθήκευση. Όταν εκτελούμε δοκιμές στους ελεγκτές μας, δεν θέλουμε να χρειάζεται να επικοινωνούμε με τον διακομιστή - άλλωστε, δοκιμάζουμε τον ελεγκτή. Μπορούμε απλά να προσθέσουμε μια υπηρεσία απομίμησης με το ίδιο όνομα με το αρχικό μας στοιχείο, και ο εγχυτήρας θα διασφαλίσει ότι ο ελεγκτής μας θα πάρει αυτόματα την ψεύτικη - ο ελεγκτής μας δεν ξέρει και δεν χρειάζεται να ξέρει τη διαφορά. Μιλώντας για δοκιμές...

4. Ανάπτυξη με γνώμονα τη δοκιμή - πάντα

Αυτό είναι στην πραγματικότητα μέρος της ενότητας 3 για την αρχιτεκτονική, αλλά είναι τόσο σημαντικό που το βάζω ως δική του ενότητα υψηλού επιπέδου. Από όλα τα πολλά πρόσθετα jQuery που έχετε δει, χρησιμοποιήσει ή γράψει, πόσα από αυτά είχαν συνοδευτική σουίτα δοκιμών; Όχι πάρα πολλά, επειδή η jQuery δεν είναι πολύ δεκτική σε κάτι τέτοιο. Το AngularJS όμως είναι. Στο jQuery, ο μόνος τρόπος για δοκιμές είναι συχνά να δημιουργήσουμε το συστατικό ανεξάρτητα με ένα δείγμα/μια σελίδα επίδειξης έναντι της οποίας οι δοκιμές μας μπορούν να εκτελέσουν χειρισμό του DOM. Οπότε τότε πρέπει να αναπτύξουμε ένα συστατικό ξεχωριστά και έπειτα να το ενσωματώσουμε στην εφαρμογή μας. Πόσο άβολο! Έτσι, πολλές φορές, όταν αναπτύσσουμε με το jQuery, επιλέγουμε την επαναληπτική αντί της ανάπτυξης με βάση τις δοκιμές. Και ποιος θα μπορούσε να μας κατηγορήσει; Αλλά επειδή έχουμε διαχωρισμό των ανησυχιών, μπορούμε να κάνουμε επαναληπτική ανάπτυξη με γνώμονα τη δοκιμή στο AngularJS! Για παράδειγμα, ας'ς πούμε ότι θέλουμε μια εξαιρετικά απλή οδηγία για να δείξουμε στο μενού μας ποια είναι η τρέχουσα διαδρομή μας. Μπορούμε να δηλώσουμε αυτό που θέλουμε στην προβολή της εφαρμογής μας:

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

Εντάξει, τώρα μπορούμε να γράψουμε ένα τεστ για την ανύπαρκτη οδηγία 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();
}));

Και όταν εκτελούμε τη δοκιμή μας, μπορούμε να επιβεβαιώσουμε ότι αποτυγχάνει. Μόνο τώρα θα πρέπει να δημιουργήσουμε την οδηγία μας:

.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' );
                }
            });
        }
    };
});

Η δοκιμή μας τώρα περνάει και το μενού μας εκτελεί όπως ζητείται. Η ανάπτυξή μας είναι και επαναληπτική και καθοδηγούμενη από δοκιμές. Πολύ ωραία.

5. Εννοιολογικά, οι οδηγίες δεν είναι συσκευασμένες jQuery

Συχνά θα ακούσετε "μόνο να κάνετε χειρισμό του DOM σε μια οδηγία". Αυτό είναι μια αναγκαιότητα. Αντιμετωπίστε το με το δέοντα σεβασμό! Αλλά ας βουτήξουμε λίγο βαθύτερα... Μερικές οδηγίες απλά διακοσμούν αυτό που υπάρχει ήδη στην προβολή (σκεφτείτε το ngClass) και επομένως μερικές φορές κάνουν χειρισμό του DOM αμέσως και μετά ουσιαστικά τελειώνουν. Αλλά αν μια οδηγία είναι σαν ένα "widget" και έχει ένα πρότυπο, θα πρέπει επίσης να σέβεται τον διαχωρισμό των ανησυχιών. Δηλαδή, το πρότυπο επίσης θα πρέπει να παραμένει σε μεγάλο βαθμό ανεξάρτητο από την υλοποίησή του στις συναρτήσεις συνδέσμου και ελεγκτή. Το AngularJS έρχεται με ένα ολόκληρο σύνολο εργαλείων για να το κάνει αυτό πολύ εύκολο: με το ngClass μπορούμε να ενημερώσουμε δυναμικά την κλάση, το ngModel επιτρέπει την αμφίδρομη δέσμευση δεδομένων, τα ngShow και ngHide δείχνουν ή κρύβουν προγραμματιστικά ένα στοιχείο και πολλά άλλα - συμπεριλαμβανομένων αυτών που γράφουμε εμείς οι ίδιοι. Με άλλα λόγια, μπορούμε να κάνουμε όλα τα είδη των απίθανων πραγμάτων χωρίς χειρισμό του DOM. Όσο λιγότερος χειρισμός του DOM, τόσο πιο εύκολο είναι να δοκιμαστούν οι οδηγίες, τόσο πιο εύκολο είναι να διαμορφωθούν, τόσο πιο εύκολο είναι να αλλάξουν στο μέλλον και τόσο πιο επαναχρησιμοποιήσιμες και διανεμητέες είναι. Βλέπω πολλούς προγραμματιστές που είναι νέοι στο AngularJS να χρησιμοποιούν τις directives ως το μέρος που θα πετάξουν ένα μάτσο jQuery. Με άλλα λόγια, σκέφτονται "αφού δεν μπορώ να κάνω χειρισμό του DOM στον ελεγκτή, θα πάρω αυτόν τον κώδικα και θα τον βάλω σε μια οδηγία". Ενώ αυτό είναι σίγουρα πολύ καλύτερο, είναι συχνά ακόμα λάθος. Σκεφτείτε τον καταγραφέα που προγραμματίσαμε στην ενότητα 3. Ακόμα και αν το βάλουμε σε μια οδηγία, ακόμα θέλουμε να το κάνουμε με τον "Angular Way". Αυτό ακόμη δεν χρειάζεται κανέναν χειρισμό του DOM! Υπάρχουν πολλές φορές που ο χειρισμός του DOM είναι απαραίτητος, αλλά είναι πολύ σπανιότερα απ' ό,τι νομίζετε! Πριν κάνετε χειρισμό του DOM οπουδήποτε στην εφαρμογή σας, αναρωτηθείτε αν το χρειάζεστε πραγματικά. Μπορεί να υπάρχει καλύτερος τρόπος. Εδώ'είναι ένα γρήγορο παράδειγμα που δείχνει το μοτίβο που βλέπω πιο συχνά. Θέλουμε ένα κουμπί με δυνατότητα εναλλαγής. (Σημείωση: αυτό το παράδειγμα είναι λίγο επιτηδευμένο και λίγο φλύαρο για να αναπαραστήσει πιο περίπλοκες περιπτώσεις που επιλύονται με τον ίδιο ακριβώς τρόπο).

.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);
            });
        }
    };
});

Υπάρχουν μερικά πράγματα που δεν είναι σωστά με αυτό:

1. Πρώτον, η jQuery δεν ήταν ποτέ απαραίτητη. Δεν υπάρχει'τίποτα που κάναμε εδώ που να χρειαζόταν το jQuery καθόλου!
2. Δεύτερον, ακόμα και αν έχουμε ήδη jQuery στη σελίδα μας, δεν υπάρχει κανένας λόγος να το χρησιμοποιήσουμε εδώ. μπορούμε απλά να χρησιμοποιήσουμε το angular.element και το στοιχείο μας θα εξακολουθεί να λειτουργεί όταν το ρίχνουμε σε ένα έργο που δεν έχει jQuery.
3. Τρίτον, ακόμα και αν υποθέσουμε ότι η jQuery ήταν απαραίτητη για να λειτουργήσει αυτή η οδηγία, το jqLite (angular.element) θα χρησιμοποιεί πάντα την jQuery αν έχει φορτωθεί! Έτσι, δεν χρειάζεται να χρησιμοποιήσουμε το $ - μπορούμε απλά να χρησιμοποιήσουμε το angular.element.
4. Τέταρτο, στενά συνδεδεμένο με το τρίτο, είναι ότι τα στοιχεία jqLite δεν χρειάζεται να τυλίγονται σε $ - το element που περνάει στη συνάρτηση link θα είναι ήδη ένα στοιχείο jQuery!
5. Και πέμπτον, το οποίο'έχουμε αναφέρει σε προηγούμενες ενότητες, γιατί αναμειγνύουμε πράγματα προτύπου στη λογική μας; Αυτή η οδηγία μπορεί να ξαναγραφτεί (ακόμα και για πολύ περίπλοκες περιπτώσεις!) πολύ πιο απλά ως εξής:

.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;
            };
        }
    };
});

Και πάλι, τα πράγματα του προτύπου βρίσκονται στο πρότυπο, οπότε εσείς (ή οι χρήστες σας) μπορείτε εύκολα να τα αντικαταστήσετε με ένα που να ανταποκρίνεται σε οποιοδήποτε απαραίτητο στυλ, και η λογική δεν χρειάστηκε ποτέ να αγγιχτεί. Επαναχρησιμοποίηση - μπουμ! Και υπάρχουν ακόμα όλα αυτά τα άλλα οφέλη, όπως η δοκιμή - είναι εύκολο! Ανεξάρτητα από το τι υπάρχει στο πρότυπο, το εσωτερικό API της οδηγίας δεν αγγίζεται ποτέ, οπότε η αναδόμηση είναι εύκολη. Μπορείτε να αλλάξετε το πρότυπο όσο θέλετε χωρίς να αγγίξετε την οδηγία. Και ανεξάρτητα από το τι αλλάζετε, οι δοκιμές σας εξακολουθούν να περνούν. w00t! Αν λοιπόν οι οδηγίες δεν είναι απλά συλλογές συναρτήσεων που μοιάζουν με jQuery, τι είναι; Οι οδηγίες είναι στην πραγματικότητα επεκτάσεις της HTML. Αν η HTML δεν κάνει κάτι που χρειάζεστε, γράφετε μια οδηγία για να το κάνει για εσάς και στη συνέχεια τη χρησιμοποιείτε σαν να ήταν μέρος της HTML. Για να το θέσουμε αλλιώς, αν το AngularJS δεν κάνει κάτι από το κουτί, σκεφτείτε πώς η ομάδα θα το πετύχαινε ώστε να ταιριάζει με το ngClick, το ngClass, κ.λπ.

Περίληψη

Μην χρησιμοποιείτε καν την jQuery. Μην το συμπεριλάβετε καν. Θα σας κρατήσει πίσω. Και όταν έρχεστε σε ένα πρόβλημα που νομίζετε ότι ξέρετε ήδη πώς να το λύσετε με την jQuery, πριν πιάσετε το $, προσπαθήστε να σκεφτείτε πώς μπορείτε να το κάνετε μέσα στα όρια της AngularJS. Αν δεν ξέρετε, ρωτήστε! 19 φορές στις 20, ο καλύτερος τρόπος για να το κάνετε δεν χρειάζεται jQuery και το να προσπαθήσετε να το λύσετε με jQuery έχει ως αποτέλεσμα περισσότερη δουλειά για εσάς.

Επιτακτική → δηλωτική

Στο jQuery, οι επιλογείς χρησιμοποιούνται για την εύρεση στοιχείων DOM και στη συνέχεια για τη δέσμευση/εγγραφή χειριστών συμβάντων σε αυτά. Όταν ενεργοποιείται ένα συμβάν, αυτός ο (προστακτικός) κώδικας εκτελείται για να ενημερώσει/αλλάξει το DOM.

Στο AngularJS, θέλετε να σκέφτεστε τις προβολές και όχι τα στοιχεία DOM. Οι προβολές είναι (δηλωτικές) HTML που περιέχουν κατευθύνσεις της AngularJS. Οι οδηγίες ρυθμίζουν τους χειριστές συμβάντων πίσω από τις σκηνές για εμάς και μας δίνουν δυναμική δέσμευση δεδομένων. Οι επιλογείς χρησιμοποιούνται σπάνια, οπότε η ανάγκη για IDs (και ορισμένους τύπους κλάσεων) μειώνεται σημαντικά. Οι προβολές είναι συνδεδεμένες με μοντέλα (μέσω πεδίων εφαρμογής). Οι προβολές είναι μια προβολή του μοντέλου. Τα γεγονότα αλλάζουν τα μοντέλα (δηλαδή τα δεδομένα, τις ιδιότητες εμβέλειας) και οι προβολές που προβάλλουν αυτά τα μοντέλα ενημερώνονται "αυτόματα&quot,

Στο AngularJS, σκεφτείτε τα μοντέλα και όχι τα επιλεγμένα με jQuery στοιχεία DOM που περιέχουν τα δεδομένα σας. Σκεφτείτε τις προβολές ως προβολές αυτών των μοντέλων, αντί να καταχωρείτε ανακλήσεις για να χειρίζεστε αυτό που βλέπει ο χρήστης.

Διαχωρισμός των ανησυχιών

Η jQuery χρησιμοποιεί διακριτική JavaScript - η συμπεριφορά (JavaScript) διαχωρίζεται από τη δομή (HTML).

Το AngularJS χρησιμοποιεί ελεγκτές και οδηγίες (κάθε μία από τις οποίες μπορεί να έχει τον δικό της ελεγκτή και/ή συναρτήσεις μεταγλώττισης και σύνδεσης) για την απομάκρυνση της συμπεριφοράς από την προβολή/δομή (HTML). Η Angular διαθέτει επίσης services και filters για να βοηθήσει στο διαχωρισμό/οργάνωση της εφαρμογής σας.

Δείτε επίσης https://stackoverflow.com/a/14346528/215945

Σχεδιασμός εφαρμογών

Μια προσέγγιση για το σχεδιασμό μιας εφαρμογής AngularJS:

1. Σκεφτείτε τα μοντέλα σας. Δημιουργήστε υπηρεσίες ή δικά σας αντικείμενα JavaScript για αυτά τα μοντέλα.
2. Σκεφτείτε πώς θέλετε να παρουσιάσετε τα μοντέλα σας -- τις προβολές σας. Δημιουργήστε πρότυπα HTML για κάθε προβολή, χρησιμοποιώντας τις απαραίτητες οδηγίες για να αποκτήσετε δυναμική δέσμευση δεδομένων.
3. Προσαρτήστε έναν ελεγκτή σε κάθε προβολή (χρησιμοποιώντας ng-view και δρομολόγηση ή ng-controller). Βάλτε τον ελεγκτή να βρίσκει/βρίσκει μόνο τα δεδομένα του μοντέλου που χρειάζεται η προβολή για να κάνει τη δουλειά της. Κάντε τους ελεγκτές όσο το δυνατόν λεπτότερους.

Πρωτοτυπική κληρονομικότητα

Μπορείτε να κάνετε πολλά με την jQuery χωρίς να γνωρίζετε πώς λειτουργεί η πρωτοτυπική κληρονομικότητα της JavaScript. Κατά την ανάπτυξη εφαρμογών AngularJS, θα αποφύγετε ορισμένες κοινές παγίδες αν έχετε καλή κατανόηση της κληρονομικότητας της JavaScript. Συνιστώμενη ανάγνωση: https://stackoverflow.com/questions/14049480/what-are-the-nuances-of-scope-prototypal-prototypical-inheritance-in-angularjs

Μπορείτε να περιγράψετε την αλλαγή παραδείγματος που είναι απαραίτητη;

Εμπεριληπτική έναντι δηλωτικής

Με την jQuery λέτε στο DOM τι πρέπει να συμβεί, βήμα προς βήμα. Με το AngularJS περιγράφετε τι αποτελέσματα θέλετε, αλλά όχι πώς να το κάνετε. Περισσότερα σχετικά με αυτό εδώ. Επίσης, δείτε την απάντηση του Mark Rajcok's.

Πώς μπορώ να αρχιτεκτονική και να σχεδιάζω εφαρμογές ιστού από την πλευρά του πελάτη διαφορετικά;

Το AngularJS είναι ένα ολόκληρο πλαίσιο για την πλευρά του πελάτη που χρησιμοποιεί το πρότυπο MVC (δείτε τη γραφική αναπαράσταση). Επικεντρώνεται σε μεγάλο βαθμό στον διαχωρισμό των ανησυχιών.

Ποια είναι η μεγαλύτερη διαφορά; Τι πρέπει να σταματήσω να κάνω/χρησιμοποιώ; Τι πρέπει να αρχίσω να κάνω/χρησιμοποιώ αντ' αυτού;

Η jQuery είναι μια βιβλιοθήκη

Το AngularJS είναι ένα πανέμορφο πλαίσιο από την πλευρά του πελάτη, εξαιρετικά ελέγξιμο, το οποίο συνδυάζει τόνους ωραίων πραγμάτων, όπως MVC, dependency injection, δέσμευση δεδομένων και πολλά άλλα.

Επικεντρώνεται στον διαχωρισμό των ανησυχιών και στις δοκιμές (unit testing και end-to-end testing), γεγονός που διευκολύνει τη δοκιμαστικοποιημένη ανάπτυξη.

Ο καλύτερος τρόπος για να ξεκινήσετε είναι να παρακολουθήσετε το φοβερό σεμινάριό τους. Μπορείτε να περάσετε τα βήματα μέσα σε δύο ώρες- ωστόσο, σε περίπτωση που θέλετε να κατακτήσετε τις έννοιες που κρύβονται πίσω από τις σκηνές, περιλαμβάνουν μια πληθώρα παραπομπών για περαιτέρω ανάγνωση.

Υπάρχουν οποιεσδήποτε σκέψεις/περιορισμοί από την πλευρά του διακομιστή;

Μπορείτε να το χρησιμοποιήσετε σε υπάρχουσες εφαρμογές στις οποίες χρησιμοποιείτε ήδη αμιγώς jQuery. Ωστόσο, αν θέλετε να εκμεταλλευτείτε πλήρως τα χαρακτηριστικά του AngularJS, μπορείτε να εξετάσετε το ενδεχόμενο κωδικοποίησης της πλευράς διακομιστή με χρήση μιας προσέγγισης RESTful.

Με αυτόν τον τρόπο θα μπορέσετε να αξιοποιήσετε το resource factory τους, το οποίο δημιουργεί μια αφαίρεση του RESTful API της πλευράς του διακομιστή σας και καθιστά τις κλήσεις από την πλευρά του διακομιστή (get, save, delete κ.λπ.) απίστευτα εύκολες.