"Berpikir dalam AngularJS" jika saya memiliki latar belakang jQuery? [Tutup]


4514

Misalkan saya terbiasa dengan pengembangan aplikasi sisi klien di jQuery , tapi sekarang saya ingin mulai menggunakan AngularJS . Bisakah Anda menggambarkan perubahan paradigma yang diperlukan? Berikut adalah beberapa pertanyaan yang dapat membantu Anda menyusun jawaban:

  • Bagaimana cara saya merancang dan mendesain aplikasi web sisi klien secara berbeda? Apa perbedaan terbesar?
  • Apa yang harus saya berhenti lakukan / gunakan; Apa yang harus saya mulai lakukan / gunakan?
  • Apakah ada pertimbangan / batasan sisi server?

Saya tidak mencari perbandingan terperinci antara jQuerydan AngularJS.


Bagi mereka yang akrab dengan "ASP.NET MVC" atau "RoR" - anggap saja Angular sebagai "klien-sisi MVC" dan hanya itu.
Serge Shultz

Jawaban:


7178

1. Jangan mendesain halaman Anda, dan kemudian ubah dengan manipulasi DOM

Di jQuery, Anda mendesain halaman, dan kemudian membuatnya dinamis. Ini karena jQuery dirancang untuk augmentasi dan telah berkembang luar biasa dari premis sederhana itu.

Tetapi dalam AngularJS, Anda harus mulai dari bawah dengan arsitektur Anda dalam pikiran. Alih-alih memulai dengan berpikir "Saya memiliki bagian DOM ini dan saya ingin membuatnya menjadi X", Anda harus mulai dengan apa yang ingin Anda capai, kemudian mendesain aplikasi Anda, dan akhirnya mendesain tampilan Anda.

2. Jangan menambah jQuery dengan AngularJS

Demikian pula, jangan mulai dengan gagasan bahwa jQuery melakukan X, Y, dan Z, jadi saya hanya akan menambahkan AngularJS di atas itu untuk model dan pengontrol. Ini sangat menggoda ketika Anda baru memulai, itulah sebabnya saya selalu merekomendasikan bahwa pengembang AngularJS baru tidak menggunakan jQuery sama sekali, setidaknya sampai mereka terbiasa melakukan hal-hal dengan "Angular Way".

Saya telah melihat banyak pengembang di sini dan di milis membuat solusi rumit ini dengan plugin jQuery dari 150 atau 200 baris kode yang kemudian mereka rekatkan ke AngularJS dengan koleksi panggilan balik dan $applys yang membingungkan dan berbelit-belit; tetapi mereka akhirnya membuatnya bekerja! Masalahnya adalah bahwa dalam kebanyakan kasus plugin jQuery dapat ditulis ulang di AngularJS di sebagian kecil dari kode, di mana tiba-tiba semuanya menjadi mudah dipahami dan langsung.

Intinya adalah ini: ketika memberikan solusi, pertama "pikirkan dalam AngularJS"; jika Anda tidak dapat menemukan solusi, tanyakan pada komunitas; jika setelah semua itu tidak ada solusi yang mudah, maka jangan ragu untuk meraih jQuery. Tapi jangan biarkan jQuery menjadi penopang atau Anda tidak akan pernah menguasai AngularJS.

3. Selalu berpikir dari segi arsitektur

Pertama tahu bahwa aplikasi satu halaman adalah aplikasi . Itu bukan halaman web. Jadi kita perlu berpikir seperti pengembang sisi server selain berpikir seperti pengembang sisi klien. Kita harus berpikir tentang bagaimana membagi aplikasi kita menjadi komponen-komponen individual, dapat dikembangkan, dan dapat diuji.

Jadi bagaimana Anda melakukannya? Bagaimana Anda "berpikir dalam AngularJS"? Berikut adalah beberapa prinsip umum, berbeda dengan jQuery.

Pandangan adalah "catatan resmi"

Di jQuery, kami mengubah tampilan secara terprogram. Kita dapat memiliki menu dropdown yang didefinisikan sebagai ulseperti:

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

Di jQuery, dalam logika aplikasi kami, kami akan mengaktifkannya dengan sesuatu seperti:

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

Ketika kita hanya melihat tampilan, tidak segera jelas bahwa ada fungsi apa pun di sini. Untuk aplikasi kecil, tidak masalah. Tetapi untuk aplikasi non-sepele, hal-hal cepat membingungkan dan sulit untuk dipelihara.

Namun, dalam AngularJS, tampilan adalah catatan resmi fungsionalitas berbasis tampilan. ulDeklarasi kami akan terlihat seperti ini sebagai gantinya:

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

Keduanya melakukan hal yang sama, tetapi dalam versi AngularJS siapa pun yang melihat template tahu apa yang seharusnya terjadi. Setiap kali anggota baru tim pengembangan datang, dia dapat melihat ini dan kemudian tahu bahwa ada arahan yang disebut dropdownMenuberoperasi di dalamnya; dia tidak perlu memberikan jawaban yang benar atau menyaring kode apa pun. Pandangan itu memberi tahu kami apa yang seharusnya terjadi. Jauh lebih bersih.

Pengembang yang baru menggunakan AngularJS sering mengajukan pertanyaan seperti: bagaimana cara menemukan semua tautan dari jenis tertentu dan menambahkan arahan ke mereka. Pengembang selalu terperangah ketika kami menjawab: Anda tidak. Tetapi alasan Anda tidak melakukan itu adalah karena ini seperti setengah jQuery, setengah AngularJS, dan tidak baik. Masalahnya di sini adalah bahwa pengembang mencoba "melakukan jQuery" dalam konteks AngularJS. Itu tidak akan berhasil dengan baik. Tampilan adalah catatan resmi. Di luar arahan (lebih lanjut tentang ini di bawah), Anda tidak pernah, tidak pernah mengubah DOM. Dan arahan diterapkan dalam tampilan , jadi maksudnya jelas.

Ingat: jangan mendesain, lalu mark up. Anda harus arsitek, dan kemudian mendesain.

Pengikatan data

Sejauh ini, ini adalah salah satu fitur paling mengagumkan dari AngularJS dan memotong banyak kebutuhan untuk melakukan jenis manipulasi DOM yang saya sebutkan di bagian sebelumnya. AngularJS akan secara otomatis memperbarui tampilan Anda sehingga Anda tidak perlu melakukannya! Di jQuery, kami merespons acara dan kemudian memperbarui konten. Sesuatu seperti:

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

Untuk tampilan yang terlihat seperti ini:

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

Selain memadukan kekhawatiran, kami juga memiliki masalah yang sama dengan niat menandakan yang saya sebutkan sebelumnya. Tetapi yang lebih penting, kami harus secara manual merujuk dan memperbarui simpul DOM. Dan jika kita ingin menghapus entri log, kita harus kode terhadap DOM untuk itu juga. Bagaimana kita menguji logika selain dari DOM? Dan bagaimana jika kita ingin mengubah presentasi?

Ini sedikit berantakan dan agak rapuh. Tetapi di AngularJS, kita bisa melakukan ini:

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

Dan pandangan kita dapat terlihat seperti ini:

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

Tetapi dalam hal ini, pandangan kami bisa terlihat seperti ini:

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

Dan sekarang alih-alih menggunakan daftar yang tidak berurutan, kami menggunakan kotak peringatan Bootstrap. Dan kami tidak pernah harus mengubah kode pengontrol! Tetapi yang lebih penting, di mana pun atau bagaimana log diperbarui, tampilan akan berubah juga. Secara otomatis. Rapi!

Meskipun saya tidak menunjukkannya di sini, pengikatan data bersifat dua arah. Jadi pesan-pesan log juga bisa menjadi diedit dalam tampilan hanya dengan melakukan hal ini: <input ng-model="entry.msg" />. Dan ada banyak sukacita.

Lapisan model yang berbeda

Di jQuery, DOM seperti model. Namun dalam AngularJS, kami memiliki lapisan model terpisah yang dapat kami kelola dengan cara apa pun yang kami inginkan, sepenuhnya independen dari tampilan. Ini membantu untuk pengikatan data di atas, mempertahankan pemisahan masalah , dan memperkenalkan kemampuan uji yang jauh lebih besar. Jawaban lain menyebutkan poin ini, jadi saya akan membiarkannya begitu saja.

Pemisahan masalah

Dan semua hal di atas terkait dengan tema yang terlalu melengkung ini: pisahkan kekhawatiran Anda. Pandangan Anda bertindak sebagai catatan resmi tentang apa yang seharusnya terjadi (sebagian besar); model Anda mewakili data Anda; Anda memiliki lapisan layanan untuk melakukan tugas yang dapat digunakan kembali; Anda melakukan manipulasi DOM dan menambah pandangan Anda dengan arahan; dan Anda merekatkan semuanya dengan pengontrol. Ini juga disebutkan dalam jawaban lain, dan satu-satunya hal yang saya tambahkan berkaitan dengan testabilitas, yang saya bahas di bagian lain di bawah ini.

Ketergantungan injeksi

Untuk membantu kami mengatasi masalah adalah injeksi ketergantungan (DI). Jika Anda berasal dari bahasa sisi server (dari Jawa ke PHP ) Anda mungkin sudah akrab dengan konsep ini, tetapi jika Anda seorang pria sisi klien yang datang dari jQuery, konsep ini bisa terlihat apa saja, dari konyol hingga berlebihan untuk hipster . Tapi ternyata tidak. :-)

Dari perspektif yang luas, DI berarti bahwa Anda dapat mendeklarasikan komponen dengan sangat bebas dan kemudian dari komponen lain, hanya meminta contoh dari itu dan itu akan diberikan. Anda tidak perlu tahu tentang memuat pesanan, atau lokasi file, atau apa pun seperti itu. Kekuatan mungkin tidak langsung terlihat, tetapi saya akan memberikan hanya satu (umum) contoh: pengujian.

Katakanlah dalam aplikasi kita, kita memerlukan layanan yang mengimplementasikan penyimpanan sisi server melalui REST API dan, tergantung pada status aplikasi, penyimpanan lokal juga. Saat menjalankan tes pada pengontrol kami, kami tidak ingin harus berkomunikasi dengan server - bagaimanapun, kami sedang menguji pengontrol . Kami hanya dapat menambahkan layanan tiruan dengan nama yang sama dengan komponen asli kami, dan injektor akan memastikan bahwa controller kami mendapatkan yang palsu secara otomatis - controller kami tidak dan tidak perlu mengetahui perbedaannya.

Berbicara tentang pengujian ...

4. Pengembangan yang digerakkan oleh tes - selalu

Ini benar-benar bagian dari bagian 3 pada arsitektur, tetapi sangat penting bahwa saya menempatkannya sebagai bagian tingkat atas sendiri.

Dari semua plugin jQuery yang pernah Anda lihat, gunakan, atau tulis, berapa banyak dari mereka yang memiliki test suite yang menyertai? Tidak terlalu banyak karena jQuery tidak terlalu setuju dengan itu. Tapi AngularJS adalah.

Di jQuery, satu-satunya cara untuk menguji adalah sering membuat komponen secara mandiri dengan halaman contoh / demo yang dengannya pengujian kami dapat melakukan manipulasi DOM. Jadi kita harus mengembangkan komponen secara terpisah dan kemudian mengintegrasikannya ke dalam aplikasi kita. Sangat tidak nyaman! Sering kali, ketika mengembangkan dengan jQuery, kami memilih untuk iteratif daripada pengembangan yang digerakkan oleh tes. Dan siapa yang bisa menyalahkan kita?

Tetapi karena kita memiliki pemisahan kekhawatiran, kita dapat melakukan pengembangan yang digerakkan oleh tes secara berulang di AngularJS! Sebagai contoh, katakanlah kita ingin arahan super sederhana untuk menunjukkan dalam menu kita apa rute kita saat ini. Kami dapat menyatakan apa yang kami inginkan dalam tampilan aplikasi kami:

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

Oke, sekarang kita bisa menulis tes untuk when-activearahan yang tidak ada :

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

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

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

Dan ketika kami menjalankan tes kami, kami dapat mengonfirmasi bahwa itu gagal. Hanya sekarang kita dapat membuat arahan kita:

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

Tes kami sekarang berlalu dan menu kami berfungsi seperti yang diminta. Pengembangan kami adalah baik berulang dan test-driven. Keren jahat.

5. Secara konseptual, arahan tidak dikemas jQuery

Anda akan sering mendengar "hanya melakukan manipulasi DOM dalam arahan". Ini suatu keharusan. Perlakukan dengan hormat!

Tapi mari selami sedikit lebih dalam ...

Beberapa arahan hanya menghiasi apa yang sudah ada dalam pandangan (berpikir ngClass) dan karena itu kadang-kadang melakukan manipulasi DOM langsung dan kemudian pada dasarnya dilakukan. Tetapi jika arahan seperti "widget" dan memiliki template, itu juga harus menghormati pemisahan kekhawatiran. Artinya, template juga harus tetap sebagian besar independen dari implementasinya dalam fungsi tautan dan pengontrol.

AngularJS hadir dengan seluruh rangkaian alat untuk menjadikan ini sangat mudah; dengan ngClasskita dapat memperbarui kelas secara dinamis; ngModelmemungkinkan pengikatan data dua arah; ngShowdan secara ngHideterprogram menampilkan atau menyembunyikan suatu elemen; dan banyak lagi - termasuk yang kita tulis sendiri. Dengan kata lain, kita dapat melakukan segala macam keangkeran tanpa manipulasi DOM. Semakin sedikit manipulasi DOM, semakin mudah arahan untuk diuji, semakin mudah mereka untuk gaya, semakin mudah mereka untuk berubah di masa depan, dan semakin dapat digunakan kembali dan didistribusikan.

Saya melihat banyak pengembang baru di AngularJS menggunakan arahan sebagai tempat untuk melempar sekelompok jQuery. Dengan kata lain, mereka berpikir "karena saya tidak bisa melakukan manipulasi DOM di controller, saya akan mengambil kode itu memasukkannya ke dalam arahan". Meskipun itu tentu saja jauh lebih baik, seringkali masih salah .

Pikirkan logger yang kami programkan di bagian 3. Bahkan jika kami menempatkan itu dalam arahan, kami masih ingin melakukannya dengan "Angular Way". Ini masih tidak mengambil manipulasi DOM! Ada banyak waktu ketika manipulasi DOM diperlukan, tetapi jauh lebih jarang daripada yang Anda pikirkan! Sebelum melakukan manipulasi DOM di mana saja di aplikasi Anda, tanyakan pada diri Anda apakah Anda benar-benar perlu. Mungkin ada cara yang lebih baik.

Berikut adalah contoh cepat yang menunjukkan pola yang paling sering saya lihat. Kami ingin tombol toggleable. (Catatan: contoh ini sedikit dibuat dan skosh verbose untuk mewakili kasus yang lebih rumit yang diselesaikan dengan cara yang persis sama.)

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

Ada beberapa hal yang salah dengan ini:

  1. Pertama, jQuery tidak pernah diperlukan. Tidak ada yang kami lakukan di sini yang membutuhkan jQuery sama sekali!
  2. Kedua, bahkan jika kita sudah memiliki jQuery di halaman kita, tidak ada alasan untuk menggunakannya di sini; kita cukup menggunakan angular.elementdan komponen kita akan tetap berfungsi ketika masuk ke proyek yang tidak memiliki jQuery.
  3. Ketiga, bahkan dengan asumsi jQuery yang diperlukan untuk direktif ini untuk bekerja, jqLite ( angular.element) akan selalu menggunakan jQuery jika itu penuh! Jadi kita tidak perlu menggunakan $- kita hanya bisa menggunakan angular.element.
  4. Keempat, terkait erat dengan yang ketiga, adalah bahwa elemen jqLite tidak perlu dibungkus $- elementyang dilewatkan ke linkfungsi sudah akan menjadi elemen jQuery!
  5. Dan kelima, yang telah kami sebutkan di bagian sebelumnya, mengapa kita mencampurkan hal-hal template ke dalam logika kita?

Arahan ini dapat ditulis ulang (bahkan untuk kasus yang sangat rumit!) Lebih sederhana seperti:

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

Sekali lagi, hal-hal template ada di template, sehingga Anda (atau pengguna Anda) dapat dengan mudah menukarnya dengan yang memenuhi gaya apa pun yang diperlukan, dan logika tidak harus disentuh. Dapat digunakan kembali - booming!

Dan masih ada semua manfaat lainnya, seperti pengujian - mudah! Tidak peduli apa yang ada di templat, API internal direktif tidak pernah disentuh, jadi refactoring mudah. Anda dapat mengubah template sebanyak yang Anda inginkan tanpa menyentuh arahan. Dan apa pun yang Anda ubah, tes Anda tetap lulus.

w00t!

Jadi jika arahan tidak hanya kumpulan fungsi seperti jQuery, apakah itu? Arahan sebenarnya adalah ekstensi dari HTML . Jika HTML tidak melakukan sesuatu yang perlu Anda lakukan, Anda menulis arahan untuk melakukannya untuk Anda, dan kemudian menggunakannya seolah-olah itu adalah bagian dari HTML.

Dengan kata lain, jika AngularJS tidak melakukan sesuatu di luar kotak, berpikir bagaimana tim akan mencapai agar sesuai benar dengan ngClick, ngClass, et al.

Ringkasan

Jangan gunakan jQuery. Bahkan tidak memasukkannya. Itu akan menahan Anda. Dan ketika Anda sampai pada masalah yang Anda pikir Anda tahu bagaimana menyelesaikannya di jQuery, sebelum Anda meraihnya $, coba pikirkan bagaimana melakukannya dalam batas AngularJS. Jika Anda tidak tahu, tanyakan! 19 kali dari 20, cara terbaik untuk melakukannya tidak perlu jQuery dan mencoba menyelesaikannya dengan hasil jQuery dalam pekerjaan yang lebih banyak untuk Anda.


204
Saya pikir menggabungkan bekerja dengan JQuery dalam aplikasi sudut adalah kasus penggunaan yang penting karena semua plugin JQuery yang ada telah ditulis. Saya tidak menulis ulang FancyBox di jQuery untuk menjaga aplikasi Angular murni.
taudep

119
@taudep Saya tidak berpikir kami tidak setuju sebanyak yang Anda pikirkan. Sebagian besar plugin jQuery dapat ditulis ulang di AngularJS dengan murah, dan dalam hal ini kita harus melakukannya. Untuk sesuatu yang rumit yang tidak ada padanannya, maka lakukanlah. Mengutip dari Bagian 2: 'Intinya adalah ini: ketika memberikan solusi, pertama "pikirkan dalam AngularJS"; jika Anda tidak dapat menemukan solusi, tanyakan pada komunitas; jika setelah semua itu tidak ada solusi yang mudah, maka jangan ragu untuk meraih jQuery . Tapi jangan biarkan jQuery menjadi penopang atau Anda tidak akan pernah menguasai AngularJS. ' [penekanan ditambahkan]
Josh David Miller

67
seorang Cina menerjemahkan jawaban yang luar biasa ini, semoga membantu. hanzheng.github.io/tech/angularjs/2013/10/28/…
Han Zheng

18
@ Benno Apa yang dia maksud dengan "no manipulasi DOM" adalah bahwa kode Anda dalam arahan tidak secara langsung melakukan manipulasi DOM. Kode itu tidak tahu apa-apa tentang DOM, itu hanya memodifikasi variabel js dalam model Anda. Ya, hasil akhirnya adalah bahwa DOM akan dimodifikasi, tetapi itu karena di luar kode yang kita tulis, ada binding yang bereaksi terhadap variabel kita berubah, tetapi di dalam arahan kita tidak tahu apa-apa tentang hal itu, membuat pemisahan yang bersih antara manipulasi DOM dan logika bisnis. Dalam contoh jQuery Anda, Anda secara langsung mengubah DOM dengan mengatakan "tambahkan teks ini ke elemen ini"
wired_in

11
@trusktr Jika mengembangkan pernah menetapkan nilai elemen masukan menggunakan jQuery dalam sebuah aplikasi AngularJS, dia melakukan sebuah pedih kesalahan. Satu-satunya pengecualian yang dapat saya pikirkan adalah plugin jQuery yang ada yang terlalu sulit untuk port yang mengubah input secara otomatis, dalam hal ini menghubungkan ke callback atau mengatur arloji sangat penting pula untuk membawa perubahan sesuai dengan aplikasi.
Josh David Miller

407

Imperatif → deklaratif

Di jQuery, penyeleksi digunakan untuk menemukan elemen DOM dan kemudian mengikat / mendaftarkan penangan event kepada mereka. Ketika suatu peristiwa muncul, kode (imperatif) itu dijalankan untuk memperbarui / mengubah DOM.

Di AngularJS, Anda ingin memikirkan tampilan daripada elemen DOM. Tampilan adalah (deklaratif) HTML yang berisi arahan AngularJS . Arahan mengatur penangan acara di belakang layar untuk kami dan memberi kami penyatuan data dinamis. Penyeleksi jarang digunakan, sehingga kebutuhan untuk ID (dan beberapa jenis kelas) sangat berkurang. Tampilan terkait dengan model (melalui cakupan). Tampilan adalah proyeksi dari model. Acara mengubah model (yaitu, data, properti lingkup), dan pandangan yang memproyeksikan model tersebut memperbarui "secara otomatis."

Di AngularJS, pikirkan model, daripada elemen DOM yang dipilih jQuery yang menyimpan data Anda. Pikirkan pandangan sebagai proyeksi dari model-model itu, daripada mendaftarkan panggilan balik untuk memanipulasi apa yang dilihat pengguna.

Pemisahan masalah

jQuery menggunakan JavaScript yang tidak mencolok - perilaku (JavaScript) dipisahkan dari struktur (HTML).

AngularJS menggunakan pengontrol dan arahan (masing-masing dapat memiliki pengontrol sendiri, dan / atau mengkompilasi dan menghubungkan fungsi) untuk menghapus perilaku dari view / structure (HTML). Angular juga memiliki layanan dan filter untuk membantu memisahkan / mengatur aplikasi Anda.

Lihat juga https://stackoverflow.com/a/14346528/215945

Desain aplikasi

Satu pendekatan untuk merancang aplikasi AngularJS:

  1. Pikirkan tentang model Anda. Buat layanan atau objek JavaScript Anda sendiri untuk model-model itu.
  2. Pikirkan tentang bagaimana Anda ingin mempresentasikan model Anda - pandangan Anda. Buat template HTML untuk setiap tampilan, menggunakan arahan yang diperlukan untuk mendapatkan penyatuan data dinamis.
  3. Lampirkan pengontrol ke setiap tampilan (menggunakan ng-view dan routing, atau ng-controller). Biarkan pengontrol menemukan / mendapatkan hanya data model apa pun yang perlu dilihat oleh tugasnya. Buat pengontrol setipis mungkin.

Warisan prototipe

Anda dapat melakukan banyak hal dengan jQuery tanpa mengetahui tentang cara kerja warisan prototipal JavaScript. Saat mengembangkan aplikasi AngularJS, Anda akan menghindari beberapa jebakan umum jika Anda memiliki pemahaman yang baik tentang warisan JavaScript. Bacaan yang disarankan: Apa nuansa lingkup prototipal / warisan prototipikal di AngularJS?


1
bisakah kamu. menjelaskan bagaimana elemen dom berbeda dari tampilan?
Rajkamal Subramanian

22
@rajkamal, elemen DOM adalah (jelas) elemen tunggal, dan di jQuery itulah yang sering kita pilih / target / manipulasi. Tampilan Angular adalah kumpulan / templat elemen DOM terkait: tampilan menu, tampilan header, tampilan footer, tampilan sidebar kanan, tampilan profil, mungkin beberapa tampilan konten utama (dapat diubah melalui tampilan-ng). Pada dasarnya, Anda ingin memecah halaman Anda menjadi tampilan yang berbeda. Setiap tampilan memiliki pengontrol terkait sendiri. Setiap tampilan memproyeksikan bagian dari model Anda.
Mark Rajcok

3
jQuery BUKAN keharusan. ondan whenfungsi tingkat tinggi, beroperasi pada anggota objek koleksi jQuery.
Jack Viers

18
Jadi untuk apa kode dieksekusi di dalam callback on? Imperatif.
cwharris

5
Imperatif vs deklaratif ini sebenarnya hanya masalah abstraksi. Pada akhirnya, semua kode deklaratif (apa yang harus dilakukan) diimplementasikan secara imperatif (bagaimana melakukannya) baik oleh pengembang dalam subrutin pada tingkat abstraksi yang lebih rendah, oleh kerangka kerja atau kompiler / juru bahasa. Untuk mengatakan bahwa "jQuery sangat penting" secara umum adalah pernyataan yang aneh, terutama mengingat bahwa itu sebenarnya menyediakan API yang lebih deklaratif dalam hal manipulasi DOM "manual".
Alex

184

AngularJS vs jQuery

AngularJS dan jQuery mengadopsi ideologi yang sangat berbeda. Jika Anda berasal dari jQuery, Anda mungkin menemukan beberapa perbedaan yang mengejutkan. Sudut dapat membuat Anda marah.

Ini normal, Anda harus mendorong. Angular sepadan.

Perbedaan besar (TLDR)

jQuery memberi Anda toolkit untuk memilih bit DOM yang sewenang-wenang dan membuat perubahan ad-hoc padanya. Anda dapat melakukan hampir semua hal yang Anda suka sepotong demi sepotong.

AngularJS malah memberi Anda kompiler .

Apa artinya ini adalah bahwa AngularJS membaca seluruh DOM Anda dari atas ke bawah dan memperlakukannya sebagai kode, secara harfiah sebagai instruksi ke kompiler. Ketika melintasi DOM, ia mencari arahan khusus (arahan kompiler) yang memberi tahu kompiler AngularJ bagaimana berperilaku dan apa yang harus dilakukan. Arahan adalah objek kecil yang penuh dengan JavaScript yang dapat cocok dengan atribut, tag, kelas, atau bahkan komentar.

Ketika kompiler Angular menentukan bahwa sepotong DOM cocok dengan direktif tertentu, ia memanggil fungsi direktif, meneruskannya elemen DOM, atribut apa pun, $ lingkup saat ini (yang merupakan toko variabel lokal), dan beberapa bit berguna lainnya. Atribut-atribut ini dapat berisi ekspresi yang dapat ditafsirkan oleh Arahan, dan yang memberi tahu cara membuat, dan kapan harus menggambar ulang itu sendiri.

Arahan kemudian dapat menarik komponen Angular tambahan seperti pengontrol, layanan, dll. Apa yang keluar di bagian bawah kompiler adalah aplikasi web yang sepenuhnya terbentuk, terhubung dan siap untuk digunakan.

Ini berarti bahwa Angular adalah Template Driven . Template Anda mendorong JavaScript, bukan sebaliknya. Ini adalah pembalikan peran yang radikal, dan kebalikan total dari JavaScript yang tidak mencolok yang telah kami tulis selama 10 tahun terakhir. Ini perlu waktu untuk membiasakan diri.

Jika ini kedengarannya terlalu preskriptif dan membatasi, tidak ada yang lebih jauh dari kebenaran. Karena AngularJS memperlakukan HTML Anda sebagai kode, Anda mendapatkan rincian tingkat HTML dalam aplikasi web Anda . Segalanya mungkin, dan kebanyakan hal ternyata sangat mudah begitu Anda membuat lompatan konseptual.

Mari kita turun ke seluk beluk.

Pertama, Angular tidak menggantikan jQuery

Angular dan jQuery melakukan hal yang berbeda. AngularJS memberi Anda satu set alat untuk menghasilkan aplikasi web. jQuery terutama memberi Anda alat untuk memodifikasi DOM. Jika jQuery ada di halaman Anda, AngularJS akan menggunakannya secara otomatis. Jika tidak, AngularJS dikirimkan dengan jQuery Lite, yang merupakan versi jQuery yang dapat dikurangi, tetapi masih dapat digunakan dengan sempurna.

Misko suka jQuery dan tidak keberatan Anda menggunakannya. Namun demikian, Anda akan mengetahui bahwa Anda dapat menyelesaikan hampir semua pekerjaan Anda menggunakan kombinasi cakupan, templat, dan arahan, dan Anda harus memilih alur kerja ini jika memungkinkan karena kode Anda akan lebih diskrit, lebih dapat dikonfigurasi, dan lebih banyak lagi Sudut.

Jika Anda menggunakan jQuery, Anda tidak harus memercikkannya di semua tempat. Tempat yang tepat untuk manipulasi DOM di AngularJS adalah dalam arahan. Lebih lanjut tentang ini nanti.

JavaScript tidak mencolok dengan Selectors vs. Declarative Templates

jQuery biasanya diterapkan secara tidak mencolok. Kode JavaScript Anda ditautkan di header (atau footer), dan ini adalah satu-satunya tempat yang disebutkan. Kami menggunakan penyeleksi untuk memilih bit halaman dan menulis plugin untuk memodifikasi bagian-bagian itu.

JavaScript di kontrol. HTML memiliki keberadaan yang sepenuhnya independen. HTML Anda tetap semantik bahkan tanpa JavaScript. Atribut Onclick adalah praktik yang sangat buruk.

Salah satu hal pertama yang akan Anda perhatikan tentang AngularJS adalah atribut khusus ada di mana-mana . HTML Anda akan dipenuhi dengan atribut, yang pada dasarnya adalah atribut onClick pada steroid. Ini adalah arahan (arahan kompiler), dan merupakan salah satu cara utama di mana templat terhubung ke model.

Ketika Anda pertama kali melihat ini, Anda mungkin tergoda untuk menulis AngularJS sebagai JavaScript mengganggu sekolah lama (seperti yang saya lakukan pada awalnya). Bahkan, AngularJS tidak bermain dengan aturan itu. Di AngularJS, HTML5 Anda adalah templat. Ini dikompilasi oleh AngularJS untuk menghasilkan halaman web Anda.

Ini perbedaan besar pertama. Untuk jQuery, halaman web Anda adalah DOM untuk dimanipulasi. Untuk AngularJS, HTML Anda adalah kode yang harus dikompilasi. AngularJS membaca di seluruh halaman web Anda dan secara harfiah mengkompilasinya menjadi halaman web baru menggunakan kompiler bawaannya.

Template Anda harus deklaratif; maknanya harus jelas hanya dengan membacanya. Kami menggunakan atribut khusus dengan nama yang bermakna. Kami membuat elemen HTML baru, lagi dengan nama yang bermakna. Seorang desainer dengan pengetahuan HTML minimal dan tanpa keterampilan coding dapat membaca template AngularJS Anda dan memahami apa yang dilakukannya. Ia dapat melakukan modifikasi. Ini adalah cara Angular.

Templatnya ada di kursi pengemudi.

Salah satu pertanyaan pertama yang saya tanyakan pada diri saya ketika memulai AngularJS dan menjalankan tutorial adalah "Di mana kode saya?" . Saya tidak menulis JavaScript, namun saya memiliki semua perilaku ini. Jawabannya jelas. Karena AngularJS mengkompilasi DOM, AngularJS memperlakukan HTML Anda sebagai kode. Untuk banyak kasus sederhana seringkali cukup hanya dengan menulis templat dan membiarkan AngularJS mengompilasinya menjadi aplikasi untuk Anda.

Template Anda mendorong aplikasi Anda. Ini diperlakukan sebagai DSL . Anda menulis komponen AngularJS, dan AngularJS akan menariknya dan membuatnya tersedia pada waktu yang tepat berdasarkan struktur templat Anda. Ini sangat berbeda dengan pola MVC standar , di mana template hanya untuk output.

Ini lebih mirip dengan XSLT daripada Ruby on Rails misalnya.

Ini adalah pembalikan kontrol radikal yang perlu dibiasakan.

Berhentilah mencoba mengarahkan aplikasi Anda dari JavaScript. Biarkan templat menggerakkan aplikasi, dan biarkan AngularJS merawat kabel komponen bersama-sama. Ini juga merupakan cara Angular.

HTML Semantik vs. Model Semantik

Dengan jQuery, halaman HTML Anda harus berisi konten bermakna semantik. Jika JavaScript dimatikan (oleh pengguna atau mesin pencari) konten Anda tetap dapat diakses.

Karena AngularJS memperlakukan halaman HTML Anda sebagai templat. Template tidak seharusnya semantik karena konten Anda biasanya disimpan dalam model Anda yang pada akhirnya berasal dari API Anda. AngularJS mengkompilasi DOM Anda dengan model untuk menghasilkan halaman web semantik.

Sumber HTML Anda tidak lagi semantik, sebaliknya, API Anda dan DOM yang dikompilasi adalah semantik.

Di AngularJS, makna hidup dalam model, HTML hanyalah templat, hanya untuk tampilan.

Pada titik ini Anda mungkin memiliki semua pertanyaan tentang SEO dan aksesibilitas, dan memang demikian. Ada masalah terbuka di sini. Sebagian besar pembaca layar sekarang akan menguraikan JavaScript. Mesin pencari juga dapat mengindeks konten AJAXed . Namun demikian, Anda harus memastikan bahwa Anda menggunakan URL pushstate dan Anda memiliki sitemap yang baik. Lihat di sini untuk diskusi tentang masalah ini: https://stackoverflow.com/a/23245379/687677

Pemisahan keprihatinan (SOC) vs MVC

Pemisahan keprihatinan (SOC) adalah pola yang tumbuh selama bertahun-tahun dalam pengembangan web karena berbagai alasan termasuk SEO, aksesibilitas dan ketidakcocokan browser. Ini terlihat seperti ini:

  1. HTML - Arti semantik. HTML harus berdiri sendiri.
  2. CSS - Styling, tanpa CSS halaman masih dapat dibaca.
  3. JavaScript - Perilaku, tanpa skrip, konten tetap ada.

Sekali lagi, AngularJS tidak bermain sesuai aturan mereka. Dalam satu pukulan, AngularJS menghilangkan satu dekade kearifan yang diterima dan sebagai gantinya menerapkan pola MVC di mana templat tidak lagi semantik, bahkan tidak sedikit.

Ini terlihat seperti ini:

  1. Model - model Anda berisi data semantik Anda. Model biasanya objek JSON . Model ada sebagai atribut dari objek yang disebut $ scope. Anda juga dapat menyimpan fungsi-fungsi utilitas praktis pada $ scope yang dapat diakses oleh template Anda.
  2. Lihat - Pandangan Anda ditulis dalam HTML. Tampilan biasanya tidak semantik karena data Anda hidup dalam model.
  3. Pengontrol - Pengontrol Anda adalah fungsi JavaScript yang mengaitkan tampilan ke model. Fungsinya untuk menginisialisasi $ scope. Tergantung pada aplikasi Anda, Anda mungkin atau mungkin tidak perlu membuat pengontrol. Anda dapat memiliki banyak pengontrol di satu halaman.

MVC dan SOC tidak berada pada ujung yang berlawanan dari skala yang sama, mereka berada pada sumbu yang sama sekali berbeda. SOC tidak masuk akal dalam konteks AngularJS. Anda harus melupakannya dan melanjutkan.

Jika, seperti saya, Anda hidup melalui perang browser, Anda mungkin menemukan ide ini cukup ofensif. Lupakan, itu akan sia-sia, aku janji.

Plugin vs Arahan

Plugin memperpanjang jQuery. Arahan AngularJS memperluas kemampuan browser Anda.

Di jQuery kami mendefinisikan plugin dengan menambahkan fungsi ke jQuery.prototype. Kami kemudian menghubungkan ini ke DOM dengan memilih elemen dan memanggil plugin pada hasilnya. Idenya adalah untuk memperluas kemampuan jQuery.

Misalnya, jika Anda ingin korsel di halaman Anda, Anda dapat menentukan daftar angka yang tidak terurut, mungkin dibungkus dengan elemen nav. Anda kemudian dapat menulis beberapa jQuery untuk memilih daftar pada halaman dan mengubah gaya itu sebagai galeri dengan batas waktu untuk melakukan animasi geser.

Di AngularJS, kami mendefinisikan arahan. Arahan adalah fungsi yang mengembalikan objek JSON. Objek ini memberi tahu AngularJS elemen DOM apa yang harus dicari, dan perubahan apa yang harus dilakukan padanya. Arahan terhubung ke template menggunakan atribut atau elemen, yang Anda temukan. Idenya adalah untuk memperluas kemampuan HTML dengan atribut dan elemen baru.

Cara AngularJS adalah untuk memperluas kemampuan HTML yang tampak asli. Anda harus menulis HTML yang mirip HTML, diperluas dengan atribut dan elemen khusus.

Jika Anda ingin korsel, cukup gunakan <carousel />elemen, lalu tentukan arahan untuk menarik template, dan buat pengisap itu berfungsi.

Banyak arahan kecil vs. plugin besar dengan sakelar konfigurasi

Kecenderungan dengan jQuery adalah untuk menulis plugin besar yang hebat seperti lightbox yang kemudian kita konfigurasikan dengan mengirimkan berbagai nilai dan opsi.

Ini adalah kesalahan di AngularJS.

Ambil contoh dropdown. Saat menulis plugin dropdown Anda mungkin tergoda untuk kode di penangan klik, mungkin fungsi untuk menambahkan chevron yang naik atau turun, mungkin mengubah kelas elemen yang tidak dilipat, tampilkan sembunyikan menu, semua hal bermanfaat.

Sampai Anda ingin melakukan perubahan kecil.

Katakanlah Anda memiliki menu yang ingin Anda buka di hover. Nah sekarang kita punya masalah. Plugin kami telah menghubungkan kabel di handler klik kami untuk kami, kami akan perlu menambahkan opsi konfigurasi untuk membuatnya berperilaku berbeda dalam kasus khusus ini.

Di AngularJS kami menulis arahan yang lebih kecil. Arahan dropdown kami akan sangat kecil. Mungkin mempertahankan status terlipat, dan menyediakan metode untuk melipat (), membuka () atau beralih (). Metode-metode ini hanya akan memperbarui $ scope.menu.visible yang merupakan boolean yang memegang status.

Sekarang di templat kami, kami dapat memasang ini:

<a ng-click="toggle()">Menu</a>
<ul ng-show="menu.visible">
  ...
</ul>

Perlu memperbarui di mouseover?

<a ng-mouseenter="unfold()" ng-mouseleave="fold()">Menu</a>
<ul ng-show="menu.visible">
  ...
</ul>

Template mendorong aplikasi sehingga kami mendapatkan rincian tingkat HTML. Jika kita ingin membuat pengecualian kasus per kasus, templat membuatnya mudah.

Penutupan vs. $ scope

Plugin JQuery dibuat dalam penutupan. Privasi dijaga dalam penutupan itu. Terserah Anda untuk mempertahankan rantai cakupan Anda dalam penutupan itu. Anda hanya benar-benar memiliki akses ke set node DOM yang diteruskan ke plugin oleh jQuery, ditambah variabel lokal apa pun yang ditentukan dalam penutupan dan semua global yang telah Anda tetapkan. Ini berarti plugin cukup lengkap. Ini adalah hal yang baik, tetapi bisa membatasi ketika membuat seluruh aplikasi. Mencoba meneruskan data antara bagian halaman dinamis menjadi tugas.

AngularJS memiliki objek $ lingkup. Ini adalah objek khusus yang dibuat dan dikelola oleh AngularJS di mana Anda menyimpan model Anda. Arahan tertentu akan menghasilkan $ lingkup baru, yang secara default mewarisi dari $ lingkup pembungkusnya menggunakan warisan prototipe JavaScript. Objek $ scope dapat diakses di controller dan view.

Ini bagian yang pintar. Karena struktur $ lingkup pewarisan kira-kira mengikuti struktur DOM, elemen memiliki akses ke cakupannya sendiri, dan segala lingkup yang berisi mulus, sampai ke lingkup $ global (yang tidak sama dengan lingkup global).

Ini membuatnya lebih mudah untuk meneruskan data, dan untuk menyimpan data pada tingkat yang sesuai. Jika dropdown dibuka, hanya ruang lingkup $ dropdown yang perlu mengetahuinya. Jika pengguna memperbarui preferensi mereka, Anda mungkin ingin memperbarui lingkup $ global, dan setiap ruang bersarang mendengarkan preferensi pengguna akan secara otomatis diperingatkan.

Ini mungkin terdengar rumit, pada kenyataannya, begitu Anda bersantai, itu seperti terbang. Anda tidak perlu membuat objek $ scope, AngularJS membuat instantiate dan mengkonfigurasinya untuk Anda, dengan benar dan tepat berdasarkan hierarki templat Anda. AngularJS kemudian membuatnya tersedia untuk komponen Anda menggunakan keajaiban injeksi ketergantungan (lebih lanjut tentang ini nanti).

Perubahan DOM manual vs. Pengikatan Data

Di jQuery, Anda membuat semua perubahan DOM dengan tangan. Anda membangun elemen DOM baru secara terprogram. Jika Anda memiliki larik JSON dan ingin meletakkannya di DOM, Anda harus menulis fungsi untuk menghasilkan HTML dan menyisipkannya.

Di AngularJS Anda dapat melakukan ini juga, tetapi Anda dianjurkan untuk menggunakan pengikatan data. Ubah model Anda, dan karena DOM terikat padanya melalui templat, DOM Anda akan secara otomatis memperbarui, tidak diperlukan intervensi.

Karena pengikatan data dilakukan dari template, menggunakan atribut atau sintaks kurung kurawal, itu sangat mudah dilakukan. Ada sedikit overhead kognitif yang terkait dengannya sehingga Anda akan menemukan diri Anda melakukannya sepanjang waktu.

<input ng-model="user.name" />

Ikat elemen input ke $scope.user.name. Memperbarui input akan memperbarui nilai dalam ruang lingkup Anda saat ini, dan sebaliknya.

Juga:

<p>
  {{user.name}}
</p>

akan menampilkan nama pengguna dalam paragraf. Ini adalah pengikatan langsung, jadi jika $scope.user.namenilainya diperbarui, template juga akan diperbarui.

Ajax sepanjang waktu

Di jQuery membuat panggilan Ajax cukup sederhana, tetapi itu masih sesuatu yang Anda mungkin berpikir dua kali. Ada kerumitan tambahan untuk dipikirkan, dan sepotong script yang harus dipelihara.

Di AngularJS, Ajax adalah solusi masuk ke default Anda dan itu terjadi setiap saat, hampir tanpa Anda sadari. Anda dapat memasukkan template dengan ng-include. Anda dapat menerapkan templat dengan arahan khusus yang paling sederhana. Anda dapat membungkus panggilan Ajax dalam layanan dan membuat sendiri layanan GitHub , atau layanan Flickr , yang dapat Anda akses dengan mudah.

Obyek Layanan vs Fungsi Helper

Di jQuery, jika kami ingin menyelesaikan tugas kecil yang tidak terkait dengan dom, seperti menarik umpan dari API, kami mungkin menulis sedikit fungsi untuk melakukannya di penutupan kami. Itu solusi yang valid, tetapi bagaimana jika kita sering mengakses feed itu? Bagaimana jika kita ingin menggunakan kembali kode itu di aplikasi lain?

AngularJS memberi kita objek layanan.

Layanan adalah objek sederhana yang berisi fungsi dan data. Mereka selalu lajang, artinya tidak akan pernah ada lebih dari satu dari mereka. Katakanlah kita ingin mengakses Stack Overflow API, kita mungkin menulis StackOverflowServiceyang mendefinisikan metode untuk melakukannya.

Katakanlah kita memiliki keranjang belanja. Kami mungkin mendefinisikan ShoppingCartService yang mengelola keranjang kami dan berisi metode untuk menambah dan menghapus item. Karena layanan ini singleton, dan digunakan bersama oleh semua komponen lain, objek apa pun yang perlu dapat menulis ke keranjang belanja dan menarik data darinya. Itu selalu keranjang yang sama.

Objek layanan adalah komponen AngularJS mandiri yang dapat kita gunakan dan gunakan kembali sesuai keinginan kita. Mereka adalah objek JSON sederhana yang berisi fungsi dan data. Mereka selalu lajang, jadi jika Anda menyimpan data pada layanan di satu tempat, Anda bisa mengeluarkan data itu di tempat lain hanya dengan meminta layanan yang sama.

Dependency injection (DI) vs. Instatiation - alias de-spaghettification

AngularJS mengelola dependensi Anda untuk Anda. Jika Anda menginginkan objek, cukup rujuk dan AngularJS akan mendapatkannya untuk Anda.

Sampai Anda mulai menggunakan ini, sulit untuk menjelaskan betapa besar manfaatnya waktu ini. Tidak ada yang seperti AngularJS DI ada di dalam jQuery.

DI berarti bahwa alih-alih menulis aplikasi Anda dan menghubungkannya bersama-sama, Anda malah menentukan pustaka komponen, masing-masing diidentifikasi oleh string.

Katakanlah saya memiliki komponen yang disebut 'FlickrService' yang mendefinisikan metode untuk menarik umpan JSON dari Flickr. Sekarang, jika saya ingin menulis controller yang dapat mengakses Flickr, saya hanya perlu merujuk ke 'FlickrService' dengan namanya ketika saya mendeklarasikan controller. AngularJS akan merawat instantiating komponen dan membuatnya tersedia untuk controller saya.

Sebagai contoh, di sini saya mendefinisikan layanan:

myApp.service('FlickrService', function() {
  return {
    getFeed: function() { // do something here }
  }
});

Sekarang ketika saya ingin menggunakan layanan itu, saya hanya menyebutnya dengan nama seperti ini:

myApp.controller('myController', ['FlickrService', function(FlickrService) {
  FlickrService.getFeed()
}]);

AngularJS akan mengenali bahwa objek FlickrService diperlukan untuk instantiate controller, dan akan memberikan satu untuk kita.

Hal ini membuat pemasangan kabel menjadi sangat mudah, dan cukup banyak menghilangkan kecenderungan menuju spagettification. Kami memiliki daftar komponen yang datar, dan AngularJS menyerahkannya kepada kami satu per satu saat dan ketika kami membutuhkannya.

Arsitektur layanan modular

jQuery mengatakan sangat sedikit tentang bagaimana Anda harus mengatur kode Anda. AngularJS memiliki pendapat.

AngularJS memberi Anda modul di mana Anda dapat menempatkan kode Anda. Jika Anda menulis skrip yang berbicara dengan Flickr misalnya, Anda mungkin ingin membuat modul Flickr untuk memasukkan semua fungsi terkait Flickr Anda. Modul dapat menyertakan modul lain (DI). Aplikasi utama Anda biasanya berupa modul, dan ini harus mencakup semua modul lain yang akan menjadi sandaran aplikasi Anda.

Anda mendapatkan penggunaan kembali kode sederhana, jika Anda ingin menulis aplikasi lain berdasarkan Flickr, Anda cukup memasukkan modul Flickr dan voila, Anda memiliki akses ke semua fungsi terkait Flickr di aplikasi baru Anda.

Modul berisi komponen AngularJS. Ketika kami menyertakan modul, semua komponen dalam modul itu tersedia bagi kami sebagai daftar sederhana yang diidentifikasi oleh string uniknya . Kami kemudian dapat menyuntikkan komponen-komponen tersebut satu sama lain menggunakan mekanisme injeksi ketergantungan AngularJS.

Untuk menyimpulkan

AngularJS dan jQuery bukan musuh. Dimungkinkan untuk menggunakan jQuery dalam AngularJS dengan sangat baik. Jika Anda menggunakan AngularJS dengan baik (templat, pengikatan data, $ scope, arahan, dll.) Anda akan menemukan Anda membutuhkan jQuery yang jauh lebih sedikit daripada yang mungkin Anda perlukan.

Hal utama yang harus disadari adalah bahwa templat Anda mendorong aplikasi Anda. Berhentilah mencoba menulis plugin besar yang melakukan segalanya. Alih-alih menulis arahan kecil yang melakukan satu hal, kemudian tulis templat sederhana untuk menyatukannya.

Pikirkan lebih sedikit tentang JavaScript yang tidak mencolok, dan sebaliknya pikirkan dalam hal ekstensi HTML.

Buku kecilku

Saya sangat bersemangat tentang AngularJS, saya menulis buku pendek tentang itu yang Anda dapat membaca online http://nicholasjohnson.com/angular-book/ . Saya harap ini membantu.


6
Gagasan bahwa "Pemisahan Kekhawatiran" berbeda dari "MVC (Model, View, Controller)" sepenuhnya palsu. Model bahasa web yang memisahkan kekhawatiran (HTML, CSS, dan JS) melakukannya dengan membiarkan orang menaruh barang di halaman web (markup / HTML) tanpa peduli bagaimana tampilannya (gaya / tata letak / CSS) atau apa yang "dikerjakan" (Acara DOM / AJAX / JavaScript). MVC juga memisahkan kekhawatiran. Setiap "lapisan" dalam pola MVC memiliki peran yang berbeda - baik data, routing / logika, atau rendering. Lapisan digabungkan dengan callback, rute dan binding model. Secara teori, seseorang dapat berspesialisasi dalam setiap lapisan, yang sering terjadi.

Sebagai seseorang yang berasal dari latar belakang SOC yang ketat, dan sebagai penasihat lama untuk standar web sejak perang browser, saya awalnya menemukan bahwa template non-semantik, non-validasi Angular menyusahkan. Saya hanya ingin menjelaskan bahwa untuk menulis Angular perlu melepaskan SOC seperti yang umumnya dilakukan. Ini bisa menjadi transisi yang sulit.
superluminary

Anda benar. SOC adalah istilah yang luas, tetapi di dunia web SOC memiliki (atau mungkin memiliki) arti yang sangat spesifik: HTML semantik, CSS presentasi, dan JavaScript untuk perilaku. Saya membuat beberapa asumsi tentang audiens saya yang mungkin tidak masuk akal, jadi saya harus minta maaf juga.
superluminary

Saya menemukan jawaban Anda paling jelas dan mencerahkan. Saya cukup pemula di sini, jadi, jika saya memiliki ekstensi untuk mengubah halaman yang ada (yang tidak saya kendalikan), haruskah saya menyimpan JQuery?
Daniel Möller

152

Bisakah Anda menggambarkan perubahan paradigma yang diperlukan?

Imperatif vs Deklaratif

Dengan jQuery Anda memberi tahu DOM apa yang perlu terjadi, langkah demi langkah. Dengan AngularJS Anda menggambarkan hasil apa yang Anda inginkan tetapi tidak bagaimana melakukannya. Lebih lanjut tentang ini di sini . Juga, periksa jawaban Mark Rajcok.

Bagaimana cara saya merancang dan mendesain aplikasi web sisi klien secara berbeda?

AngularJS adalah seluruh kerangka kerja sisi klien yang menggunakan pola MVC (lihat representasi grafis mereka ). Ini sangat berfokus pada pemisahan masalah.

Apa perbedaan terbesar? Apa yang harus saya berhenti lakukan / gunakan; apa yang harus saya mulai lakukan / gunakan?

jQuery adalah perpustakaan

AngularJS adalah kerangka kerja sisi klien yang indah, sangat dapat diuji, yang menggabungkan banyak hal keren seperti MVC, injeksi ketergantungan , pengikatan data, dan banyak lagi.

Ini berfokus pada pemisahan masalah dan pengujian (pengujian unit dan pengujian ujung ke ujung), yang memfasilitasi pengembangan yang digerakkan oleh pengujian.

Cara terbaik untuk memulai adalah melalui tutorial mereka yang luar biasa . Anda bisa melalui langkah-langkah dalam beberapa jam; Namun, jika Anda ingin menguasai konsep di balik layar, mereka menyertakan segudang referensi untuk dibaca lebih lanjut.

Apakah ada pertimbangan / batasan sisi server?

Anda dapat menggunakannya pada aplikasi yang sudah ada di mana Anda sudah menggunakan jQuery murni. Namun, jika Anda ingin memanfaatkan sepenuhnya fitur AngularJS, Anda dapat mempertimbangkan mengkodekan sisi server menggunakan pendekatan RESTful .

Melakukan hal itu akan memungkinkan Anda untuk memanfaatkan pabrik sumber daya mereka , yang menciptakan abstraksi sisi server Anda RESTful API dan membuat panggilan sisi server (dapatkan, simpan, hapus, dll.) Sangat mudah.


27
Saya pikir Anda berlumpur di perairan dengan berbicara tentang bagaimana jQuery adalah "perpustakaan" dan Angular adalah "kerangka kerja" ... untuk satu hal, saya pikir mungkin untuk berpendapat bahwa jQuery adalah kerangka kerja ... ini adalah abstraksi manipulasi DOM dan penanganan acara. Ini mungkin bukan kerangka kerja untuk hal yang sama seperti Angular, tapi itulah dilema yang ditanyakan oleh penanya: mereka tidak benar-benar tahu perbedaan antara Angular dan jQuery, dan untuk semua penanya tahu, jQuery adalah kerangka kerja untuk membangun situs web yang banyak membutuhkan klien. Jadi berdebat tentang terminologi tidak akan menjelaskan semuanya.
Zando

15
Saya pikir Anda adalah orang yang semakin bingung. Pertanyaan ini membahas dengan tepat stackoverflow.com/questions/7062775 ini . Juga, jawaban ini dapat membantu mengklarifikasi apa perbedaan antara kerangka kerja dan pustaka: stackoverflow.com/a/148759/620448
Ulises

6
Perpustakaan tidak menjadi "kerangka kerja" hanya karena kumpulan fungsinya sangat berguna atau besar. Kerangka kerja membuat keputusan untuk Anda. Ketika Anda mulai menggunakan AngularJS, Anda cenderung digabungkan dengan sifatnya. (Mis: Anda seharusnya hanya memperbarui DOM dalam arahan, jika tidak sesuatu akan kacau.) Itu karena AngularJS adalah kerangka kerja. Saat Anda menggunakan jQuery, Anda dapat mencampur dan mencocokkan alat dengan relatif mudah dengan risiko konflik yang minimal. Itu karena jQuery adalah perpustakaan, dan setidaknya setengah yang layak juga.

8
Sebuah perpustakaan adalah kode yang Anda menelepon. Sebuah kerangka adalah kode yang memanggil kode Anda. Menurut definisi ini, Angular adalah kerangka kerja. Anda menyediakannya dengan komponen dan Angular memastikan bahwa komponen Anda dipakai dengan dependensi yang mereka butuhkan.
superluminary

84

Untuk menggambarkan "pergeseran paradigma", saya pikir jawaban singkat sudah cukup.

AngularJS mengubah cara Anda menemukan elemen

Di jQuery , Anda biasanya menggunakan penyeleksi untuk menemukan elemen, dan kemudian memasang mereka:
$('#id .class').click(doStuff);

Di AngularJS , Anda menggunakan arahan untuk menandai elemen secara langsung, untuk menghubungkan mereka:
<a ng-click="doStuff()">

AngularJS tidak perlu (atau ingin) Anda menemukan elemen menggunakan penyeleksi - perbedaan utama antara jqLite AngularJS versus jQuery full-blown adalah bahwa jqLite tidak mendukung penyeleksi .

Jadi ketika orang mengatakan "tidak termasuk jQuery sama sekali", itu terutama karena mereka tidak ingin Anda menggunakan penyeleksi; mereka ingin Anda belajar menggunakan arahan. Langsung, bukan pilih!


13
Sama seperti penafian, ada BANYAK perbedaan yang lebih besar antara Angular dan jQuery. Tetapi menemukan elemen adalah elemen yang membutuhkan perubahan pemikiran terbesar.
Scott Rippey

1
maafkan saya jika saya salah, tapi saya pikir pemilih adalah apa yang Anda gunakan untuk menemukan elemen DOM? Anda lebih suka menyimpan setiap bagian dari UI yang baru Anda muat dalam referensi, daripada hanya memilih satu atau 2 elemen yang dapat diklik pengguna, saat bepergian menggunakan pemilih? terdengar lebih sulit bagiku ..
RozzA

3
@AlexanderPritchard Inti dari Angular adalah Anda tidak memilih dari JavaScript, Anda langsung dari template Anda. Ini adalah inversi kontrol yang menempatkan kekuasaan di tangan perancang. Ini adalah prinsip desain yang disengaja. Untuk benar-benar mendapatkan Angular, Anda harus memikirkan kode Anda dengan cara ini. Ini sulit untuk dilakukan.
superluminary

3
@superluminary Kutipan yang bagus! "jangan pilih; langsung!" Serius, aku akan menggunakannya.
Scott Rippey

1
Ini adalah salah satu hal favorit saya tentang AngularJS. Saya tidak perlu khawatir tentang tim UX yang merusak fungsionalitas saya atau saya merusak gaya mereka. Mereka menggunakan kelas, saya menggunakan arahan, titik. Saya tidak ketinggalan pemilih sedikit pun.
adam0101

69

jQuery

jQuery membuat perintah JavaScript yang sangat panjang seperti getElementByHerpDerpperamban pendek dan lintas.

AngularJS

AngularJS memungkinkan Anda membuat tag / atribut HTML Anda sendiri yang melakukan hal-hal yang berfungsi baik dengan aplikasi web dinamis (karena HTML dirancang untuk laman statis).

Edit:

Mengatakan "Saya memiliki latar belakang jQuery bagaimana pendapat saya di AngularJS?" seperti mengatakan "Saya memiliki latar belakang HTML bagaimana menurut saya dalam JavaScript?" Fakta bahwa Anda mengajukan pertanyaan menunjukkan kemungkinan besar Anda tidak memahami tujuan mendasar dari kedua sumber ini. Inilah sebabnya saya memilih untuk menjawab pertanyaan dengan hanya menunjukkan perbedaan mendasar daripada melalui daftar yang mengatakan "AngularJS memanfaatkan arahan sedangkan jQuery menggunakan penyeleksi CSS untuk membuat objek jQuery yang melakukan ini dan itu dll ..." . Pertanyaan ini tidak membutuhkan jawaban yang panjang.

jQuery adalah cara untuk membuat pemrograman JavaScript di browser lebih mudah. Perintah yang lebih pendek, lintas browser, dll.

AngularJS memperluas HTML, jadi Anda tidak perlu meletakkan <div>semua tempat hanya untuk membuat aplikasi. Itu membuat HTML benar-benar berfungsi untuk aplikasi daripada apa yang dirancang untuknya, yang merupakan halaman web statis. Ini menyelesaikan ini dengan cara memutar menggunakan JavaScript, tetapi pada dasarnya itu adalah ekstensi dari HTML, bukan JavaScript.


@ Robert tergantung apa yang Anda lakukan. $(".myclass")sangat umum, dan lebih mudah dalam jQuery daripada PO-Javascript.
Rob Grant

61

jQuery: Anda banyak berpikir tentang 'QUERYing the DOM ' untuk elemen DOM dan melakukan sesuatu.

AngularJS: THE model adalah kebenaran, dan Anda selalu berpikir dari ANGLE itu.

Misalnya, ketika Anda mendapatkan data dari THE server yang ingin Anda tampilkan dalam beberapa format di DOM, di jQuery, Anda perlu '1. CARI 'di mana di DOM Anda ingin menempatkan data ini,' 2. Perbarui / tambahkan itu di sana dengan membuat simpul baru atau hanya mengatur innerHTML -nya . Kemudian ketika Anda ingin memperbarui tampilan ini, Anda kemudian '3. CARI 'lokasi dan' 4. MEMPERBARUI'. Siklus menemukan dan memperbarui semua ini dilakukan dalam konteks yang sama untuk mendapatkan dan memformat data dari server hilang di AngularJS.

Dengan AngularJS Anda memiliki model (objek JavaScript yang sudah Anda gunakan sebelumnya) dan nilai model memberi tahu Anda tentang model (jelas) dan tentang tampilan, dan operasi pada model secara otomatis menyebar ke tampilan, jadi Anda tidak perlu Aku tidak harus memikirkannya. Anda akan menemukan diri Anda di AngularJS tidak lagi menemukan hal-hal di DOM.

Dengan kata lain, di jQuery, Anda harus berpikir tentang pemilih CSS, yaitu, di mana divatau tdyang memiliki kelas atau atribut, dll, sehingga saya bisa mendapatkan HTML atau warna atau nilai, tetapi di AngularJS, Anda akan mendapati diri Anda berpikir seperti ini: model apa yang saya hadapi, saya akan menetapkan nilai model menjadi benar. Anda tidak mempermasalahkan apakah tampilan yang mencerminkan nilai ini adalah kotak centang atau berada dalam tdelemen (detail yang sering perlu Anda pikirkan di jQuery).

Dan dengan manipulasi DOM di AngularJS, Anda menemukan diri Anda menambahkan arahan dan filter, yang dapat Anda anggap sebagai ekstensi HTML yang valid.

Satu hal lagi yang akan Anda alami di AngularJS: di jQuery Anda sering memanggil fungsi jQuery, di AngularJS, AngularJS akan memanggil fungsi Anda, jadi AngularJS akan 'memberi tahu Anda bagaimana melakukan sesuatu', tetapi manfaatnya sepadan, jadi belajar AngularJS biasanya berarti mempelajari apa yang diinginkan AngularJS atau cara AngularJS mengharuskan Anda menyajikan fungsi Anda dan itu akan memanggilnya sesuai. Ini adalah salah satu hal yang membuat AngularJS kerangka kerja daripada perpustakaan.


46

Itu adalah beberapa jawaban yang sangat bagus, tetapi panjang.

Singkatnya pengalaman saya:

  1. Pengontrol dan penyedia (layanan, pabrik, dll.) Adalah untuk memodifikasi model data, BUKAN HTML.
  2. HTML dan arahan menentukan tata letak dan mengikat ke model.
  3. Jika Anda perlu berbagi data antar pengendali, buat layanan atau pabrik - mereka lajang yang dibagikan di seluruh aplikasi.
  4. Jika Anda membutuhkan widget HTML, buat direktif.
  5. Jika Anda memiliki beberapa data dan sekarang mencoba memperbarui HTML ... BERHENTI! perbarui model, dan pastikan HTML Anda terikat pada model.

45

jQuery adalah perpustakaan manipulasi DOM.

AngularJS adalah kerangka kerja MV *.

Bahkan, AngularJS adalah salah satu dari beberapa kerangka kerja JavaScript MV * (banyak alat JavaScript MVC masih berada di bawah pustaka kategori).

Menjadi kerangka kerja, ia menjadi tuan rumah kode Anda dan mengambil kepemilikan keputusan tentang apa yang harus dipanggil dan kapan!

AngularJS sendiri menyertakan edisi jQuery-lite di dalamnya. Jadi untuk beberapa pemilihan / manipulasi DOM dasar, Anda benar-benar tidak perlu memasukkan pustaka jQuery (ini menghemat banyak byte untuk dijalankan di jaringan.)

AngularJS memiliki konsep "Arahan" untuk manipulasi DOM dan merancang komponen UI yang dapat digunakan kembali, jadi Anda harus menggunakannya kapan pun Anda merasa perlu melakukan hal-hal yang terkait manipulasi DOM (arahan hanya tempat di mana Anda harus menulis kode jQuery saat menggunakan AngularJS).

AngularJS melibatkan beberapa kurva belajar (lebih dari jQuery :-).

-> Untuk setiap pengembang yang berasal dari latar belakang jQuery, saran pertama saya adalah "belajar JavaScript sebagai bahasa kelas satu sebelum melompat ke kerangka kerja yang kaya seperti AngularJS!" Saya belajar fakta di atas dengan cara yang sulit.

Semoga berhasil.


34

Mereka adalah apel dan jeruk. Anda tidak ingin membandingkannya. Mereka adalah dua hal yang berbeda. AngularJs telah memiliki jQuery lite bawaan yang memungkinkan Anda untuk melakukan manipulasi DOM dasar tanpa bahkan menyertakan versi jQuery yang penuh sesak nafas.

jQuery adalah tentang manipulasi DOM. Ini menyelesaikan semua rasa sakit lintas browser jika tidak Anda harus berurusan dengan tetapi itu bukan kerangka kerja yang memungkinkan Anda untuk membagi aplikasi Anda menjadi komponen seperti AngularJS.

Yang menyenangkan tentang AngularJs adalah memungkinkan Anda untuk memisahkan / mengisolasi manipulasi DOM dalam arahan. Ada arahan bawaan yang siap untuk Anda gunakan seperti ng-klik. Anda dapat membuat arahan khusus Anda sendiri yang akan berisi semua logika tampilan atau manipulasi DOM sehingga Anda tidak berakhir dengan menggabungkan kode manipulasi DOM dalam pengontrol atau layanan yang harus menangani logika bisnis.

Angular memecah aplikasi Anda menjadi - Pengendali - Layanan - Tampilan - dll.

dan ada satu hal lagi, itulah arahannya. Ini adalah atribut yang dapat Anda lampirkan ke elemen DOM dan Anda bisa menjadi gila dengan jQuery di dalamnya tanpa khawatir tentang jQuery Anda pernah bertentangan dengan komponen AngularJs atau mengacaukan arsitekturnya.

Saya mendengar dari pertemuan yang saya hadiri, salah satu pendiri Angular mengatakan mereka bekerja sangat keras untuk memisahkan manipulasi DOM jadi jangan mencoba untuk memasukkan mereka kembali.


31

Dengarkan podcast JavaScript Jabber: Episode # 32 yang menampilkan pencipta asli AngularJS: Misko Hevery & Igor Minar. Mereka berbicara banyak tentang bagaimana rasanya datang ke AngularJS dari latar belakang JavaScript lainnya, terutama jQuery.

Salah satu poin yang dibuat di podcast membuat banyak hal klik untuk saya sehubungan dengan pertanyaan Anda:

MISKO : [...] salah satu hal yang kami pikir sangat sulit di Angular adalah, bagaimana kami menyediakan banyak pintu darurat sehingga Anda bisa keluar dan pada dasarnya mencari jalan keluar dari ini. Jadi bagi kami, jawabannya adalah hal yang disebut "Arahan". Dan dengan arahan, Anda pada dasarnya menjadi JavaScript jQuery kecil biasa, Anda dapat melakukan apa pun yang Anda inginkan.

IGOR : Jadi anggap direktif sebagai instruksi kepada kompiler yang memberi tahu itu kapan pun Anda menemukan elemen tertentu ini atau CSS ini di template, dan Anda menyimpan kode semacam ini dan kode itu bertanggung jawab atas elemen dan semua yang ada di bawah elemen itu di pohon DOM.

Transkrip seluruh episode tersedia di tautan yang disediakan di atas.

Jadi, untuk langsung menjawab pertanyaan Anda: AngularJS adalah -sangat-pendapatan dan merupakan kerangka kerja MV * yang sebenarnya. Namun, Anda masih bisa melakukan semua hal keren yang Anda kenal dan sukai dengan jQuery di dalam arahan. Ini bukan masalah "Bagaimana saya melakukan apa yang saya gunakan di jQuery?" sebanyak itu masalah "Bagaimana cara menambah AngularJS dengan semua hal yang saya lakukan di jQuery?"

Ini benar-benar dua keadaan pikiran yang sangat berbeda.


2
Saya tidak yakin saya akan setuju bahwa Angular SANGAT berargumen. Anda ingin berpendapat, lihat Ember. Saya akan menggambarkan Angular memiliki pendapat goldilocks - untuk banyak hal yang saya lihat, jQuery memiliki terlalu sedikit pendapat dan Ember memiliki terlalu banyak. Sudut sepertinya tepat.
fool4jesus

30

Saya menemukan pertanyaan ini menarik, karena paparan serius pertama saya untuk pemrograman JavaScript adalah Node.js dan AngularJS. Saya tidak pernah belajar jQuery, dan saya kira itu hal yang baik, karena saya tidak harus melepaskan apa pun. Bahkan, saya secara aktif menghindari solusi jQuery untuk masalah saya, dan sebagai gantinya, semata-mata mencari "cara AngularJS" untuk menyelesaikannya. Jadi, saya kira jawaban saya untuk pertanyaan ini pada dasarnya akan menjadi, "berpikir seperti seseorang yang tidak pernah belajar jQuery" dan menghindari godaan untuk memasukkan jQuery secara langsung (jelas AngularJS menggunakannya sampai batas tertentu di belakang layar).


23

AngularJS dan jQuery:

AngularJs dan JQuery benar-benar berbeda di setiap level kecuali fungsionalitas JQLite dan Anda akan melihatnya begitu Anda mulai mempelajari fitur inti AngularJs (saya jelaskan di bawah).

AngularJs adalah kerangka kerja sisi klien yang menawarkan untuk membangun aplikasi sisi klien independen. JQuery adalah pustaka sisi klien yang bermain di sekitar DOM.

AngularJs Cool Principle - Jika Anda ingin beberapa perubahan pada UI Anda pikirkan dari perspektif perubahan data model. Ubah data Anda dan UI akan merender ulang sendiri. Anda tidak perlu bermain-main dengan DOM setiap kali kecuali dan sampai hampir tidak diperlukan dan itu juga harus ditangani melalui Arahan Angular.

Untuk menjawab pertanyaan ini, saya ingin berbagi pengalaman tentang aplikasi perusahaan pertama dengan AngularJS. Ini adalah fitur paling luar biasa yang disediakan Angular di mana kita mulai mengubah pola pikir jQuery kita dan kita mendapatkan Angular seperti kerangka kerja dan bukan perpustakaan.

Pengikatan data dua arah luar biasa: Saya memiliki grid dengan semua fungsi UPDATE, DELTE, INSERT. Saya memiliki objek data yang mengikat model grid menggunakan ng-repeat. Anda hanya perlu menulis satu baris kode JavaScript sederhana untuk dihapus dan disisipkan dan hanya itu. kisi secara otomatis diperbarui saat model kisi berubah secara instan. Fungsi pembaruan adalah waktu nyata, tidak ada kode untuk itu. Anda merasa luar biasa !!!

Arahan yang dapat digunakan kembali adalah super: Tulis arahan di satu tempat dan gunakan di seluruh aplikasi. OH TUHAN!!! Saya menggunakan arahan ini untuk paging, regex, validasi, dll. Ini sangat keren!

Routingnya kuat: Terserah implementasi Anda bagaimana Anda ingin menggunakannya, tetapi itu membutuhkan sangat sedikit baris kode untuk merutekan permintaan untuk menentukan HTML dan pengontrol (JavaScript)

Pengontrol hebat: Pengontrol menangani HTML mereka sendiri, tetapi pemisahan ini juga berfungsi dengan baik untuk fungsi umum. Jika Anda ingin memanggil fungsi yang sama dengan mengklik tombol pada master HTML, cukup tulis nama fungsi yang sama di setiap pengontrol dan tulis kode individual.

Plugin: Ada banyak fitur serupa lainnya seperti menampilkan hamparan di aplikasi Anda. Anda tidak perlu menulis kode untuk itu, cukup gunakan plugin overlay yang tersedia sebagai wc-overlay, dan ini akan secara otomatis menangani semua permintaan XMLHttpRequest (XHR).

Ideal untuk arsitektur RESTful : Menjadi kerangka kerja yang lengkap membuat AngularJS hebat untuk bekerja dengan arsitektur RESTful. Untuk memanggil REST CRUD APIs sangat mudah dan

Layanan : Menulis kode umum menggunakan layanan dan lebih sedikit kode di pengontrol. Sevices dapat digunakan untuk berbagi fungsionalitas umum di antara pengontrol.

Ekstensibilitas : Angular telah memperluas arahan HTML menggunakan arahan arahan. Tulis ekspresi di dalam html dan evaluasi saat runtime. Buat arahan dan layanan Anda sendiri dan gunakan di proyek lain tanpa usaha ekstra.


20

Sebagai JavaScript MV * pemula dan murni berfokus pada arsitektur aplikasi (bukan masalah server / sisi klien), saya pasti akan merekomendasikan sumber daya berikut (yang saya terkejut belum disebutkan): Pola Desain JavaScript , oleh Addy Osmani , sebagai pengantar Pola Desain JavaScript yang berbeda . Istilah yang digunakan dalam jawaban ini diambil dari dokumen tertaut di atas. Saya tidak akan mengulangi apa yang dikatakan dengan sangat baik dalam jawaban yang diterima. Sebagai gantinya, jawaban ini menghubungkan kembali ke latar belakang teoritis yang menjadi kekuatan AngularJS (dan perpustakaan lainnya).

Seperti saya, Anda akan segera menyadari bahwa kerangka AngularJS (atau Ember.js , Durandal, & MV * lainnya) adalah salah satu kerangka kerja rumit yang menggabungkan banyak pola desain JavaScript yang berbeda.

Saya merasa lebih mudah juga, untuk menguji (1) kode JavaScript asli dan (2) perpustakaan yang lebih kecil untuk masing-masing pola ini secara terpisah sebelum menyelam ke dalam satu kerangka kerja global. Ini memungkinkan saya untuk lebih memahami isu-isu penting mana yang dikemukakan oleh suatu kerangka kerja (karena Anda secara pribadi dihadapkan pada masalah).

Sebagai contoh:

  • Pemrograman Berorientasi Objek JavaScript (ini adalah tautan pencarian Google). Ini bukan perpustakaan, tetapi tentu saja prasyarat untuk pemrograman aplikasi apa pun. Itu mengajari saya implementasi asli dari prototipe, konstruktor, singleton & pola dekorator
  • jQuery / Garis Bawah untuk pola fasad (seperti WYSIWYG untuk memanipulasi DOM)
  • Prototype.js untuk pola prototipe / konstruktor / mixin
  • MemerlukanJS / Curl.js untuk pola modul / AMD
  • KnockoutJS untuk pola yang dapat diamati, terbitkan / berlangganan

NB: Daftar ini tidak lengkap, atau 'perpustakaan terbaik'; mereka kebetulan adalah perpustakaan yang saya gunakan. Perpustakaan ini juga mencakup lebih banyak pola, yang disebutkan hanyalah fokus utama atau maksud asli mereka. Jika Anda merasa ada sesuatu yang hilang dari daftar ini, mohon sebutkan di komentar, dan saya akan dengan senang hati menambahkannya.


12

Sebenarnya, jika Anda menggunakan AngularJS, Anda tidak perlu jQuery lagi. AngularJS sendiri memiliki pengikatan dan arahan, yang merupakan "pengganti" yang sangat baik untuk sebagian besar hal yang dapat Anda lakukan dengan jQuery.

Saya biasanya mengembangkan aplikasi seluler menggunakan AngularJS dan Cordova . Satu-satunya hal dari jQuery yang saya butuhkan adalah Selector.

Dengan googling, saya melihat bahwa ada modul pemilih jQuery mandiri di luar sana. Ini Sizzle.

Dan saya memutuskan untuk membuat potongan kode kecil yang membantu saya dengan cepat memulai situs web menggunakan AngularJS dengan kekuatan jQuery Selector (menggunakan Sizzle).

Saya membagikan kode saya di sini: https://github.com/huytd/Sizzular

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.