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


Misalkan saya akrab dengan mengembangkan aplikasi sisi klien di jQuery, tapi sekarang saya ingin mulai menggunakannya AngularJS. Bisakah Anda menggambarkan pergeseran paradigma yang diperlukan? Berikut beberapa pertanyaan yang mungkin bisa membantu Anda menyusun jawaban:

  • Bagaimana cara saya mendesain dan mendesain aplikasi sisi klien secara berbeda? Apa perbedaan terbesarnya?
  • Apa yang harus saya berhenti lakukan / gunakan; Apa yang harus saya mulai lakukan / gunakan?
  • Apakah ada pertimbangan / pembatasan dari sisi server?

Saya tidak mencari perbandingan terperinci antara jQuery dan AngularJS.


4525
2018-02-21 04:09


asal


Jawaban:


1. Jangan desain halaman Anda, lalu ubah dengan DOM manipulasi

Di jQuery, Anda mendesain halaman, lalu Anda membuatnya dinamis. Ini karena jQuery dirancang untuk augmentasi dan tumbuh luar biasa dari premis sederhana.

Namun di AngularJS, Anda harus mulai dari awal dengan arsitektur Anda dalam pikiran. Daripada memulai dengan berpikir "Saya memiliki bagian DOM ini dan saya ingin membuatnya X", Anda harus mulai dengan apa yang ingin Anda capai, kemudian pergi tentang merancang aplikasi Anda, dan akhirnya pergi tentang merancang pandangan 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 adalah 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 dengan plugin jQuery dari 150 atau 200 baris kode yang kemudian mereka tempelkan ke AngularJS dengan koleksi callback dan $applyYang membingungkan dan berbelit-belit; tetapi mereka akhirnya berhasil! Masalahnya adalah bahwa dalam paling kasus bahwa plugin jQuery dapat ditulis ulang dalam AngularJS di sebagian kecil kode, di mana tiba-tiba semuanya menjadi mudah dipahami dan lugas.

Intinya adalah ini: ketika solusi, pertama "berpikir dalam AngularJS"; jika Anda tidak dapat memikirkan solusi, tanyakan kepada masyarakat; jika setelah semua itu tidak ada solusi yang mudah, kemudian merasa bebas untuk meraih jQuery. Tapi jangan biarkan jQuery menjadi penopang atau Anda tidak akan pernah menguasai AngularJS.

3. Selalu berpikir dalam kerangka arsitektur

Pertama tahu itu aplikasi satu halaman adalah aplikasi. Mereka tidak Halaman web. Jadi kita perlu berpikir seperti pengembang sisi server sebagai tambahan berpikir seperti pengembang sisi klien. Kita harus berpikir tentang bagaimana membagi aplikasi kita menjadi komponen yang dapat diperluas, dapat diuji, dan dapat diuji.

Sehingga kemudian bagaimana apakah kamu melakukan itu? Bagaimana Anda "berpikir dalam AngularJS"? Berikut adalah beberapa prinsip umum, berbeda dengan jQuery.

Pandangannya adalah "catatan resmi"

Di jQuery, kami secara terprogram mengubah tampilan. Kita bisa memiliki menu dropdown yang didefinisikan sebagai ul seperti ini:

<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 di sini. Untuk aplikasi kecil, itu bagus. Tetapi untuk aplikasi yang tidak sepele, segala sesuatunya menjadi membingungkan dan sulit dipelihara.

Namun, di AngularJS, tampilan adalah rekaman resmi fungsionalitas berbasis tampilan. Kami ul deklarasi 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 mengetahui apa yang seharusnya terjadi. Setiap kali ada anggota baru tim pengembangan yang bergabung, dia dapat melihat ini dan kemudian tahu bahwa ada direktif yang disebut dropdownMenu beroperasi di atasnya; dia tidak perlu intuisi jawaban yang benar atau menyaring kode apa pun. Pandangan itu memberi tahu kami apa yang seharusnya terjadi. Jauh lebih bersih.

Pengembang baru ke AngularJS sering mengajukan pertanyaan seperti: bagaimana cara menemukan semua tautan dari jenis tertentu dan menambahkan arahan kepada mereka. Pengembang selalu terkejut ketika kami membalas: Anda tidak. Tapi alasan Anda tidak melakukan itu adalah bahwa ini seperti setengah jQuery, setengah AngularJS, dan tidak bagus. Masalahnya di sini adalah bahwa pengembang mencoba "melakukan jQuery" dalam konteks AngularJS. Itu tidak akan pernah berhasil. Pandangan aku s catatan resmi. Di luar arahan (lebih lanjut di bawah ini), Anda tidak pernah, pernah, tak pernah ubah DOM. Dan arahan diterapkan dalam tampilan, jadi niatnya jelas.

Ingat: jangan desain, dan kemudian beri markup. Anda harus menjadi arsitek, dan kemudian mendesain.

Pengikatan data

Ini adalah salah satu fitur yang 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 menanggapi 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>

Terlepas dari masalah pencampuran, kami juga memiliki masalah yang sama dengan menandakan niat yang saya sebutkan sebelumnya. Tetapi yang lebih penting, kami harus mereferensikan dan memperbarui node DOM secara manual. Dan jika kita ingin menghapus entri log, kita harus mengkodekan terhadap DOM untuk itu juga. Bagaimana kita menguji logika terpisah dari DOM? Dan bagaimana jika kita ingin mengubah presentasi?

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

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

Dan pandangan kami dapat terlihat seperti ini:

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

Tetapi dalam hal ini, pandangan kita 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 diurutkan, kami menggunakan kotak peringatan Bootstrap. Dan kami tidak pernah mengubah kode pengontrol! Tetapi yang lebih penting, tidak masalah dimana atau bagaimana log diperbarui, tampilan juga akan berubah. Secara otomatis. Rapi!

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

Lapisan model berbeda

Di jQuery, DOM adalah jenis seperti model. Namun di AngularJS, kami memiliki lapisan model terpisah yang dapat kami kelola dengan cara apa pun yang kami inginkan, sepenuhnya terlepas dari pandangan. Ini membantu untuk mengikat data di atas, mempertahankan pemisahan masalah, dan memperkenalkan testability yang jauh lebih besar. Jawaban lain menyebutkan poin ini, jadi saya akan berhenti begitu saja.

Pemisahan kekhawatiran

Dan semua ikatan di atas ke dalam tema over-arching ini: jaga kekhawatiran Anda tetap terpisah. Pandangan Anda bertindak sebagai catatan resmi tentang apa yang seharusnya terjadi (untuk 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 tempelkan semuanya bersama dengan pengontrol. Ini juga disebutkan dalam jawaban lain, dan satu-satunya hal yang akan saya tambahkan berkaitan dengan testability, yang saya diskusikan di bagian lain di bawah ini.

Injeksi ketergantungan

Untuk membantu kami dengan pemisahan kekhawatiran injeksi ketergantungan (DI). Jika Anda berasal dari bahasa sisi server (dari Jawa untuk PHP) Anda mungkin sudah akrab dengan konsep ini, tetapi jika Anda adalah pria sisi-klien yang berasal dari jQuery, konsep ini dapat terlihat dari konyol hingga berlebihan hingga hipster. Tapi ternyata tidak. :-)

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

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

Berbicara tentang pengujian ...

4. Pengembangan berdasarkan tes - selalu

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

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

Di jQuery, satu-satunya cara untuk menguji sering kali adalah membuat komponen secara independen dengan halaman contoh / demo yang dapat digunakan untuk pengujian kami terhadap manipulasi DOM. Jadi kita harus mengembangkan komponen secara terpisah dan kemudian mengintegrasikannya ke aplikasi kita. Betapa merepotkan! Begitu banyak waktu, ketika berkembang dengan jQuery, kami memilih untuk iteratif daripada pengembangan berbasis tes. Dan siapa yang bisa menyalahkan kita?

Tetapi karena kami memiliki kepedulian yang terpisah, kami dapat melakukan pengembangan berdasarkan uji secara iteratif di AngularJS! Sebagai contoh, katakanlah kita ingin direktif super sederhana untuk menunjukkan di 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 yang tidak ada when-active direktif:

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

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

.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 berkinerja seperti yang diminta. Perkembangan kami adalah kedua berulang-ulang dan test-driven. Sangat keren.

5. Secara konseptual, arahan adalah tidak paket jQuery

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

Tapi mari selami sedikit lebih dalam ...

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

AngularJS hadir dengan seperangkat alat untuk membuat ini sangat mudah; dengan ngClass kita dapat memperbarui kelas secara dinamis; ngModel memungkinkan pengikatan data dua arah; ngShow dan ngHide secara terprogram menampilkan atau menyembunyikan elemen; dan banyak lagi - termasuk yang kami tulis sendiri. Dengan kata lain, kita bisa melakukan segala macam keangkeran tanpa Manipulasi DOM. Semakin sedikit manipulasi DOM, arahan yang lebih mudah untuk diuji, semakin mudah mereka untuk bergaya, semakin mudah mereka berubah di masa depan, dan semakin dapat digunakan kembali dan didistribusikan.

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

Pikirkan logger yang kami programkan di bagian 3. Bahkan jika kami memasukkannya ke dalam direktif, kami masih ingin melakukannya dengan "Angular Way". Saya t masih tidak mengambil manipulasi DOM! Ada banyak waktu ketika manipulasi DOM diperlukan, tetapi itu a banyak lebih langka dari yang Anda pikirkan! Sebelum melakukan manipulasi DOM di mana saja dalam aplikasi Anda, tanyakan pada diri Anda apakah Anda benar-benar perlu. Mungkin ada cara yang lebih baik.

Berikut contoh cepat yang menunjukkan pola yang paling sering saya lihat. Kami ingin tombol toggleable. (Catatan: contoh ini sedikit dibuat dan skosh verbose untuk merepresentasikan 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, meskipun kami sudah memiliki jQuery di halaman kami, tidak ada alasan untuk menggunakannya di sini; kita bisa menggunakan angular.element dan komponen kami akan tetap berfungsi ketika jatuh ke proyek yang tidak memiliki jQuery.
  3. Ketiga, bahkan mengasumsikan jQuery adalah diperlukan untuk arahan ini untuk bekerja, jqLite (angular.element) akan selalu gunakan jQuery jika sudah dimuat! Jadi kita tidak perlu menggunakan $ - Kita bisa menggunakan angular.element.
  4. Keempat, terkait erat dengan yang ketiga, adalah bahwa elemen jqLite tidak perlu dibungkus $ - the element yang diteruskan ke link fungsi akan sudah jadi elemen jQuery!
  5. Dan kelima, yang telah kami sebutkan di bagian sebelumnya, mengapa kita mencampur hal-hal template ke dalam logika kita?

Arahan ini dapat ditulis ulang (bahkan untuk kasus yang sangat rumit!) Jauh 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 dalam template, sehingga Anda (atau pengguna Anda) dapat dengan mudah menukarnya dengan yang memenuhi gaya yang diperlukan, dan logika tidak pernah harus disentuh. Reusability - booming!

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

w00t!

Jadi, jika arahan bukan hanya koleksi fungsi seperti jQuery, apa itu? Arahan sebenarnya 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, pikirkan bagaimana tim akan melakukannya dengan benar ngClick, ngClass, et al.

Ringkasan

Bahkan tidak menggunakan jQuery. Bahkan jangan memasukkannya. Itu akan menahanmu. Dan ketika Anda datang ke masalah yang Anda pikir Anda tahu bagaimana memecahkan di jQuery sudah, sebelum Anda meraih $, cobalah untuk berpikir tentang bagaimana melakukannya dalam batasan AngularJS. Jika Anda tidak tahu, tanyakan! 19 kali dari 20, cara terbaik untuk melakukannya tidak perlu jQuery dan mencoba menyelesaikannya dengan hasil jQuery di lebih banyak pekerjaan untuk Anda.


7187
2018-02-21 21:26



Imperatif → deklaratif

Di jQuery, penyeleksi digunakan untuk menemukan DOM elemen dan kemudian mengikat / mendaftarkan penangan kejadian kepada mereka. Ketika suatu peristiwa memicu, bahwa (imperatif) kode mengeksekusi untuk memperbarui / mengubah DOM.

Di AngularJS, Anda ingin memikirkannya dilihat daripada elemen DOM. Tampilan adalah (deklaratif) HTML yang berisi AngularJS arahan. Arahan mengatur penangan kejadian di belakang layar untuk kami dan memberi kami penyatuan data dinamis. Para pemilih jarang digunakan, jadi kebutuhan akan ID (dan beberapa jenis kelas) sangat berkurang. Tampilan terikat model (melalui cakupan). Tampilan merupakan proyeksi model. Peristiwa model perubahan (yaitu, data, ruang lingkup properti), dan pandangan yang memproyeksikan model-model tersebut memperbarui "secara otomatis."

Di AngularJS, pikirkan tentang model, daripada elemen DOM yang dipilih jQuery yang menyimpan data Anda. Pikirkan pandangan sebagai proyeksi dari model tersebut, daripada mendaftarkan callback untuk memanipulasi apa yang dilihat oleh pengguna.

Pemisahan kekhawatiran

jQuery mempekerjakan JavaScript tidak mengganggu - behavior (JavaScript) terpisah dari struktur (HTML).

AngularJS digunakan pengendali dan arahan (masing-masing dapat memiliki pengendali sendiri, dan / atau mengkompilasi dan menghubungkan fungsi) untuk menghapus perilaku dari tampilan / struktur (HTML). Sudut juga memiliki jasa 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 tersebut.
  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. Pasang pengontrol untuk setiap tampilan (menggunakan ng-view dan routing, atau ng-controller). Minta pengendali 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 bagaimana cara kerja warisan prototipe JavaScript. Ketika mengembangkan aplikasi AngularJS, Anda akan menghindari beberapa jebakan umum jika Anda memiliki pemahaman yang baik tentang warisan JavaScript. Bacaan yang disarankan: Apa saja nuansa ruang lingkup prototipe / prototipikal warisan di AngularJS?


408
2018-02-21 04:09



AngularJS vs. jQuery

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

Ini normal, Anda harus mendorongnya. Sudut sangat berharga.

Perbedaan besar (TLDR)

jQuery memberi Anda toolkit untuk memilih bit acak DOM dan membuat perubahan ad-hoc untuk mereka. Anda dapat melakukan banyak hal yang Anda suka sepotong demi sepotong.

AngularJS malah memberi Anda penyusun.

Apa artinya ini adalah bahwa AngularJS membaca seluruh DOM Anda dari atas ke bawah dan memperlakukannya sebagai kode, secara harfiah sebagai instruksi kepada compiler. Saat melintasi DOM, Ini terlihat spesifik arahan (arahan compiler) yang memberitahu compiler AngularJS bagaimana berperilaku dan apa yang harus dilakukan. Arahan adalah objek kecil penuh JavaScript yang dapat cocok dengan atribut, tag, kelas, atau bahkan komentar.

Ketika compiler Angular menentukan bahwa bagian dari DOM sesuai dengan arahan tertentu, ia memanggil fungsi direktif, memberikan elemen DOM, atribut apa pun, lingkup $ saat ini (yang merupakan penyimpanan variabel lokal), dan beberapa bit berguna lainnya. Atribut-atribut ini mungkin mengandung ekspresi yang dapat diinterpretasikan oleh Directive, dan yang memberitahukannya bagaimana render, dan kapan harus redraw itu sendiri.

Arahan selanjutnya dapat menarik komponen tambahan Sudut seperti pengontrol, layanan, dll. Yang keluar dari bagian bawah kompilator adalah aplikasi web yang sepenuhnya terbentuk, terhubung dan siap 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 tidak mengganggu yang telah kami tulis selama 10 tahun terakhir atau lebih. Ini bisa membutuhkan waktu untuk membiasakan diri.

Jika ini terdengar seperti over-preskriptif dan membatasi, tidak ada yang lebih jauh dari kebenaran. Karena AngularJS memperlakukan HTML Anda sebagai kode, Anda mendapatkannya Perincian tingkat HTML di aplikasi web Anda. Segalanya mungkin, dan banyak hal yang sangat mudah setelah Anda membuat beberapa lompatan konseptual.

Mari kita menuju ke sepele.

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 hadir di halaman Anda, AngularJS akan menggunakannya secara otomatis. Jika tidak, AngularJS akan dikirim dengan jQuery Lite, yang merupakan versi jQuery yang dapat digunakan, tetapi masih sangat berguna.

Misko suka jQuery dan tidak keberatan jika kamu menggunakannya. Namun Anda akan menemukan saat Anda memajukan bahwa Anda bisa mendapatkan hampir semua pekerjaan Anda selesai menggunakan kombinasi ruang lingkup, templat dan arahan, dan Anda sebaiknya memilih alur kerja ini jika mungkin karena kode Anda akan lebih diskrit, lebih dapat dikonfigurasi, dan lebih banyak lagi Sudut.

Jika Anda menggunakan jQuery, Anda seharusnya tidak menaburkannya di semua tempat. Tempat yang tepat untuk manipulasi DOM di AngularJS adalah direktif. Lebih lanjut tentang ini nanti.

JavaScript tidak obyektif dengan Selectors vs. Declarative Templates

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

JavaScript memegang kendali. 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 itu atribut khusus ada di mana-mana. HTML Anda akan dikotori dengan atribut ng, yang pada dasarnya atribut onClick pada steroid. Ini adalah arahan (arahan compiler), dan merupakan salah satu cara utama di mana template terhubung ke model.

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

Ini adalah perbedaan besar pertama. Untuk jQuery, halaman web Anda adalah DOM yang akan dimanipulasi. Untuk AngularJS, HTML Anda adalah kode yang harus dikompilasi. AngularJS membaca di seluruh halaman web Anda dan secara harfiah mengkompilasinya ke halaman web baru menggunakan compiler yang ada di dalamnya.

Template Anda harus deklaratif; artinya harus jelas hanya dengan membacanya. Kami menggunakan atribut khusus dengan nama yang bermakna. Kami membuat elemen HTML baru, lagi dengan nama yang bermakna. Seorang perancang dengan pengetahuan HTML minimal dan tidak ada keterampilan pengkodean dapat membaca template AngularJS Anda dan memahami apa yang dilakukannya. Ia dapat melakukan modifikasi. Ini adalah cara Sudut.

Template ada di kursi pengemudi.

Salah satu pertanyaan pertama yang saya tanyakan pada diri sendiri ketika memulai AngularJS dan menjalankan melalui tutorial adalah "Di mana kode saya?". Saya telah menulis JavaScript, namun saya memiliki semua perilaku ini. Jawabannya jelas. Karena AngularJS mengkompilasi DOM, AngularJS memperlakukan HTML Anda sebagai kode. Untuk banyak kasus sederhana sering cukup hanya menulis template dan membiarkan AngularJS mengkompilasinya 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 template Anda. Ini sangat berbeda dengan standar MVC pola, di mana template hanya untuk output.

Ini lebih mirip dengan XSLT dari Ruby on Rails sebagai contoh.

Ini adalah pembalikan kontrol radikal yang membutuhkan waktu untuk membiasakan diri.

Berhenti mencoba untuk mendorong aplikasi Anda dari JavaScript Anda. Biarkan templat tersebut mendorong aplikasi, dan biarkan AngularJS mengurus pengkabelan komponen bersama-sama. Ini juga cara Sudut.

Semantic HTML vs. Model Semantik

Dengan jQuery halaman HTML Anda harus mengandung 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 akhirnya berasal dari API Anda. AngularJS mengkompilasi DOM Anda dengan model untuk menghasilkan halaman web semantik.

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

Di AngularJS, yang berarti hidup dalam model, HTML hanyalah sebuah templat, hanya untuk tampilan.

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

Pemisahan kekhawatiran (SOC) vs MVC

Pemisahan kekhawatiran (SOC) adalah pola yang tumbuh selama bertahun-tahun pengembangan web untuk berbagai alasan termasuk SEO, aksesibilitas dan ketidakcocokan browser. Terlihat seperti ini:

  1. HTML - Makna Semantik. HTML harus berdiri sendiri.
  2. CSS - Styling, tanpa CSS halaman masih bisa dibaca.
  3. JavaScript - Perilaku, tanpa skrip, kontennya tetap ada.

Sekali lagi, AngularJS tidak bermain sesuai aturan mereka. Dalam stroke, AngularJS tidak lagi memiliki satu dekade kebijaksanaan yang diterima dan sebagai gantinya mengimplementasikan pola MVC di mana template tidak lagi semantik, bahkan tidak sedikit.

Terlihat seperti ini:

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

MVC dan SOC tidak berada di ujung yang berlawanan dengan skala yang sama, mereka berada pada sumbu yang benar-benar 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 menyinggung. Dapatkan lebih dari itu, itu akan sia-sia, aku janji.

Plugin vs. Petunjuk

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 hasil. Idenya adalah untuk memperluas kemampuan jQuery.

Misalnya, jika Anda ingin korsel di halaman Anda, Anda mungkin mendefinisikan daftar angka yang tidak berurutan, mungkin dibungkus dalam elemen nav. Anda mungkin kemudian menulis beberapa jQuery untuk memilih daftar di halaman dan restyle itu sebagai galeri dengan timeout 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 dibuat untuk mereka. Arahan terhubung ke templat menggunakan atribut atau elemen, yang Anda temukan. Idenya adalah untuk memperluas kemampuan HTML dengan atribut dan elemen baru.

Cara AngularJS adalah memperluas kemampuan native looking HTML. Anda harus menulis HTML yang terlihat seperti HTML, diperluas dengan atribut dan elemen khusus.

Jika Anda menginginkan korsel, cukup gunakan a <carousel /> elemen, kemudian tentukan perintah untuk menarik template, dan buat pengisap itu berfungsi.

Banyak arahan kecil vs plugin besar dengan switch konfigurasi

Kecenderungan dengan jQuery adalah menulis plugin besar seperti lightbox yang kemudian kita konfigurasi dengan melewatkan banyak nilai dan opsi.

Ini adalah kesalahan dalam AngularJS.

Ambil contoh dropdown. Ketika menulis sebuah plugin dropdown Anda mungkin tergoda untuk mengkodekan penangan klik, mungkin fungsi untuk menambahkan chevron yang naik atau turun, mungkin mengubah kelas elemen yang tidak dilipat, tampilkan menyembunyikan menu, semua hal yang membantu.

Sampai Anda ingin membuat perubahan kecil.

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

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

Sekarang di template kami kita dapat mentransfer ini:

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

Perlu memperbarui pada gerakan mouse?

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

Template mendorong aplikasi sehingga kami mendapatkan perincian tingkat HTML. Jika kita ingin membuat perkara perkecualian perkara, templatenya membuatnya mudah.

Penutupan vs. lingkup $

Plugin JQuery dibuat dalam penutupan. Privasi dipertahankan dalam penutupan itu. Terserah Anda untuk mempertahankan rantai lingkup Anda dalam penutupan itu. Anda hanya benar-benar memiliki akses ke set node DOM yang diteruskan ke plugin oleh jQuery, ditambah variabel lokal yang ditentukan dalam penutupan dan setiap global yang telah Anda tetapkan. Ini berarti bahwa plugin cukup mandiri. Ini adalah hal yang baik, tetapi bisa menjadi restriktif saat membuat aplikasi keseluruhan. Mencoba untuk mengirim data antara bagian-bagian halaman yang dinamis menjadi tugas.

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

Ini adalah bagian yang pintar. Karena struktur $ scope inheritance secara kasar mengikuti struktur DOM, elemen memiliki akses ke ruang lingkup mereka sendiri, dan setiap lingkup yang mengandung mulus, semua jalan sampai ke lingkup global $ (yang tidak sama dengan lingkup global).

Ini membuatnya lebih mudah untuk mengirim data ke sekitar, dan untuk menyimpan data pada tingkat yang sesuai. Jika dropdown dibuka, hanya dropdown $ scope yang perlu Anda ketahui. Jika pengguna memperbarui preferensi mereka, Anda mungkin ingin memperbarui lingkup global $, dan lingkup bersarang apa pun yang mendengarkan preferensi pengguna akan secara otomatis disiagakan.

Ini mungkin terdengar rumit, pada kenyataannya, begitu Anda bersantai di dalamnya, rasanya seperti terbang. Anda tidak perlu membuat objek lingkup $, AngularJS instantiates dan mengkonfigurasi untuk Anda, dengan benar dan tepat berdasarkan hierarki template Anda. AngularJS kemudian membuatnya tersedia untuk komponen Anda menggunakan keajaiban injeksi ketergantungan (lebih lanjut tentang ini nanti).

Perubahan DOM manual vs. Data Binding

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

Di AngularJS Anda dapat melakukan ini juga, tetapi Anda didorong untuk menggunakan pengikatan data. Ubah model Anda, dan karena DOM terikat padanya melalui template DOM Anda akan secara otomatis diperbarui, tidak ada intervensi yang diperlukan.

Karena pengikatan data dilakukan dari template, baik menggunakan atribut atau sintaks penjepit keriting, itu sangat mudah dilakukan. Ada sedikit overhead kognitif yang terkait dengannya sehingga Anda akan selalu melakukannya sepanjang waktu.

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

Mengikat elemen input ke $scope.user.name. Memperbarui masukan akan memperbarui nilai dalam cakupan Anda saat ini, dan sebaliknya.

Juga:

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

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

Ajax sepanjang waktu

Dalam jQuery membuat panggilan Ajax cukup sederhana, tetapi itu masih sesuatu yang mungkin Anda pikirkan dua kali. Ada kerumitan tambahan untuk dipikirkan, dan skrip yang adil untuk dipertahankan.

Di AngularJS, Ajax adalah solusi standar Anda dan itu terjadi sepanjang waktu, hampir tanpa Anda sadari. Anda dapat menyertakan template dengan ng-include. Anda dapat menerapkan template dengan direktif khusus yang paling sederhana. Anda dapat membungkus panggilan Ajax dalam layanan dan membuat diri Anda a GitHub layanan, atau Flickr layanan, yang dapat Anda akses dengan sangat mudah.

Objek Layanan vs Fungsi Pembantu

Di jQuery, jika kami ingin menyelesaikan tugas kecil yang tidak terkait dengan dominasi seperti menarik umpan dari API, kami mungkin akan menulis sedikit fungsi untuk melakukan itu dalam penutupan kami. Itu adalah solusi yang valid, tetapi bagaimana jika kita ingin 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, yang berarti tidak mungkin ada lebih dari satu. Katakanlah kami ingin mengakses API Stack Overflow, kami mungkin menulis a StackOverflowService yang menentukan 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 layanannya tunggal, dan dibagi oleh semua komponen lain, objek apa pun yang perlu dapat ditulis ke keranjang belanja dan mengambil data darinya. Itu selalu kereta yang sama.

Objek layanan adalah komponen AngularJS yang dapat digunakan dan digunakan 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 mendapatkan data itu di tempat lain hanya dengan meminta layanan yang sama.

Injeksi ketergantungan (DI) vs Instatiasi - alias de-spaghettification

AngularJS mengelola dependensi Anda untuk Anda. Jika Anda menginginkan suatu objek, cukup merujuk padanya dan AngularJS akan mendapatkannya untuk Anda.

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

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

Katakanlah saya memiliki komponen bernama 'FlickrService' yang mendefinisikan metode untuk menarik feed JSON dari Flickr. Sekarang, jika saya ingin menulis pengontrol yang dapat mengakses Flickr, saya hanya perlu merujuk ke 'FlickrService' dengan nama ketika saya menyatakan pengontrol. AngularJS akan mengurus instantiating komponen dan membuatnya tersedia untuk controller saya.

Misalnya, 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 menginstansi pengendali, dan akan menyediakannya untuk kita.

Hal ini membuat perkabelan bersama sangat mudah, dan cukup banyak menghilangkan kecenderungan apapun terhadap spagettification. Kami memiliki daftar komponen yang datar, dan AngularJS menyerahkannya kepada kami satu per satu 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 membungkus 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 tergantung pada aplikasi Anda.

Anda mendapatkan kode ulang yang sederhana, jika Anda ingin menulis aplikasi lain berdasarkan Flickr, Anda dapat menyertakan modul Flickr dan voila, Anda memiliki akses ke semua fungsi Flickr terkait dalam aplikasi baru Anda.

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

Untuk menyimpulkan

AngularJS dan jQuery bukan musuh. Ada kemungkinan untuk menggunakan jQuery dalam AngularJS dengan sangat baik. Jika Anda menggunakan AngularJS dengan baik (templates, data-binding, $ scope, directives, dll.), Anda akan menemukan bahwa Anda memerlukan banyak kurang jQuery daripada yang mungkin Anda butuhkan.

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

Pikirkan lebih sedikit tentang JavaScript yang tidak mengganggu, dan alih-alih berpikir dalam konteks ekstensi HTML.

Buku kecilku

Saya sangat bersemangat dengan AngularJS, saya menulis sebuah buku singkat tentangnya yang sangat Anda sukai untuk dibaca online http://nicholasjohnson.com/angular-book/. Saya harap ini bermanfaat.


184
2018-05-12 10:22



Bisakah Anda menggambarkan pergeseran paradigma yang diperlukan?

Imperatif vs Deklaratif

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

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

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

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

jQueryadalah perpustakaan

AngularJS adalah kerangka sisi klien yang cantik, 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 end-to-end), yang memfasilitasi pengembangan berbasis tes.

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

Apakah ada pertimbangan / pembatasan dari sisi server?

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

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


152
2018-02-21 04:29



Untuk mendeskripsikan "pergeseran paradigma", saya pikir jawaban singkat dapat mencukupi.

AngularJS mengubah cara Anda menemukan elemen

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

Di AngularJS, Kau gunakan arahan untuk menandai elemen secara langsung, untuk menghubungkannya:
<a ng-click="doStuff()">

AngularJS tidak perlu (atau ingin) Anda untuk menemukan elemen menggunakan pemilih - perbedaan utama antara AngularJS's jqLite versus full-blown jQuery Apakah itu jqLite tidak mendukung pemilih.

Jadi ketika orang mengatakan "jangan sertakan jQuery sama sekali", itu terutama karena mereka tidak ingin Anda menggunakan pemilih; mereka ingin Anda belajar menggunakan arahan sebagai gantinya. Langsung, jangan pilih!


84
2018-02-21 07:57



jQuery

jQuery membuat perintah JavaScript yang sangat panjang seperti getElementByHerpDerp lebih pendek dan lintas-browser.

AngularJS

AngularJS memungkinkan Anda membuat tag / atribut HTML 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 menurut saya di AngularJS?" seperti mengatakan "Saya memiliki latar belakang HTML bagaimana pendapat saya dalam JavaScript?" Fakta bahwa Anda mengajukan pertanyaan menunjukkan kemungkinan besar Anda tidak memahami tujuan dasar dari kedua sumber daya ini. Inilah sebabnya mengapa saya memilih untuk menjawab pertanyaan dengan hanya menunjukkan perbedaan mendasar daripada melalui daftar yang mengatakan "AngularJS menggunakan arahan sedangkan jQuery menggunakan pemilih CSS untuk membuat objek jQuery yang melakukan ini dan itu dll ...." . Pertanyaan ini tidak membutuhkan jawaban yang panjang.

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

AngularJS memperluas HTML, jadi Anda tidak perlu meletakkannya <div> seluruh tempat hanya untuk membuat aplikasi. Itu membuat HTML benar-benar bekerja untuk aplikasi daripada apa yang dirancang untuk, yang statis, halaman web pendidikan. Ini menyelesaikan ini secara tidak langsung menggunakan JavaScript, tetapi pada dasarnya itu adalah ekstensi dari HTML, bukan JavaScript.


69
2018-02-04 05:07



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

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

Misalnya, ketika Anda mendapatkan data dari server yang ingin Anda tampilkan dalam beberapa format di DOM, di jQuery, Anda harus '1. TEMUKAN 'di mana di DOM Anda ingin menempatkan data ini,' 2. PERBARUI / LAKUKAN 'di sana dengan membuat simpul baru atau hanya mengaturnya innerHTML. Kemudian ketika Anda ingin memperbarui tampilan ini, Anda kemudian '3. TEMUKAN 'lokasi dan' 4. MEMPERBARUI'. Siklus ini menemukan dan memperbarui semua dilakukan dalam konteks yang sama mendapatkan dan memformat data dari server hilang dalam AngularJS.

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

Untuk dimasukkan ke dalam cara lain, di jQuery, Anda perlu memikirkan pemilih CSS, yaitu, di mana div atau td yang memiliki kelas atau atribut, dll., sehingga saya bisa mendapatkan HTML atau warna atau nilainya, tetapi di AngularJS, Anda akan menemukan diri Anda berpikir seperti ini: model apa yang saya hadapi, saya akan menetapkan nilai model menjadi true. Anda tidak menyibukkan diri dari apakah pandangan yang mencerminkan nilai ini adalah kotak yang dicentang atau berada dalam a td elemen (detail yang sering Anda perlukan untuk dipikirkan 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 memanggil fungsi jQuery banyak, di AngularJS, AngularJS akan memanggil fungsi Anda, sehingga AngularJS akan 'memberi tahu Anda cara melakukan sesuatu', tetapi manfaatnya sepadan, jadi pelajari AngularJS biasanya berarti belajar 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 daripada perpustakaan.


61
2017-11-02 16:53



Itu adalah jawaban yang sangat bagus, tapi panjang.

Untuk merangkum 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 pengontrol, buat layanan atau pabrik - mereka adalah lajang yang dibagikan di seluruh aplikasi.
  4. Jika Anda membutuhkan widget HTML, buatlah arahan.
  5. Jika Anda memiliki beberapa data dan sekarang mencoba memperbarui HTML ... STOP! perbarui model, dan pastikan HTML Anda terikat ke model.

46
2018-05-16 21:50