javascript - jQuery geçmişim varsa “AngularJS’de Düşünmek”?

Varsayalım jQuery ile istemci tarafı uygulamalar geliştirmeye aşinayım, ama şimdi AngularJS kullanmaya başlamak istiyorum. Gerekli olan paradigma değişimini tarif edebilir misiniz? İşte cevabı çerçevelemenize yardımcı olabilecek birkaç soru:

  • Müşteri tarafı web uygulamalarını nasıl farklı şekilde tasarlar ve tasarlarım? En büyük fark nedir?
  • Ne yapmayı/kullanmayı bırakmalıyım; Bunun yerine ne yapmaya/kullanmaya başlamalıyım?
  • Sunucu tarafında herhangi bir düşünce/restriksiyon var mı?

jQuery ile AngularJS arasında detaylı bir karşılaştırma aramıyorum.

Cevap #1

1. Sayfanızı tasarlamayın ve sonra DOM manipülasyonlarıyla değiştirin

jQuery'de önce bir sayfa tasarlarsınız ve sonra onu dinamik hale getirirsiniz. Bunun nedeni jQuery'nin artırma için tasarlanmış olması ve bu basit öncülten inanılmaz bir şekilde büyümesidir.

Ama AngularJS'te, mimariniz aklınızda olarak baştan başlamak zorundasınız. "Bu DOM parçasına sahibim ve onun X yapmasını istiyorum" diye düşünerek başlamaktansa, neyi başarmak istediğinizle başlamalı, sonra uygulamanızı tasarlamalı ve en sonunda görünümünüzü tasarlamalısınız.

2. jQuery'yi AngularJS ile artırmayın

Benzer şekilde, jQuery’nin X, Y ve Z yaptığını düşünerek başlamayın ve bu yüzden modeller ve denetleyiciler için AngularJS’i onun üstüne ekleyeyim demeyin. Bu, özellikle yeni başlıyorsanız gerçekten cazip geliyor, bu yüzden ben her zaman yeni AngularJS geliştiricilerine jQuery’yi hiç kullanmamalarını, en azından işleri “Angular Yolu” ile yapmaya alışana kadar tavsiye ederim.

Burada ve mailing listesinde birçok geliştiricinin, ardından AngularJS içine bir dizi callback ve $apply ile yapıştırdıkları, kafa karıştırıcı ve karmaşık olan 150 veya 200 satırlık jQuery eklentileriyle bu ayrıntılı çözümleri oluşturduğunu gördüm; ama sonunda bunu çalıştırmayı başarıyorlar! Sorun şu ki, çoğu durumda o jQuery eklentisi AngularJS kullanılarak çok daha az kodla yeniden yazılabilir, böylece her şey birden anlaşılır ve basit hale gelir.

Özet şu: çözüm üretirken önce "AngularJS şeklinde düşünün"; bir çözüm bulamıyorsanız topluluğa sorun; tüm bunların ardından kolay bir çözüm yoksa, o zaman jQuery'ye başvurabilirsiniz. Ama jQuery'nin bir dayanak haline gelmesine izin vermeyin yoksa AngularJS'i asla tam olarak öğrenemezsiniz.

3. Her zaman mimari açısından düşünün

Öncelikle bilmelisiniz ki tek sayfa uygulamaları uygulamalardır. Onlar web sayfaları değildir. Bu yüzden, istemci tarafı geliştirici gibi düşünmenin yanı sıra sunucu tarafı geliştirici gibi de düşünmemiz gerekir. Uygulamamızı bireysel, genişletilebilir ve test edilebilir bileşenlere nasıl böleceğimizi düşünmeliyiz.

Peki o zaman bunu nasıl yapıyorsunuz? Nasıl "AngularJS'de düşünürsünüz"? İşte jQuery ile karşılaştırmalı bazı genel ilkeler.

Görünüm "resmî kayıt"tır

jQuery'de, görünümü programlı olarak değiştiririz. Bir açılır menümüzü şu şekilde bir ul olarak tanımlayabilirdik:

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

jQuery'de, uygulama mantığımızda, bunu şöyle bir şeyle etkinleştirirdik:

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

Sadece görünüme baktığımızda, burada herhangi bir işlevsellik olduğunu hemen fark etmek mümkün değildir. Küçük uygulamalar için bu sorun değildir. Ancak önemsiz olmayan uygulamalar için işler hızla karışır ve bakım yapmak zorlaşır.

Ancak AngularJS'de, görünüm, görünüm tabanlı işlevselliğin resmi kaydıdır. Bizim ul bildirimiz bunun yerine şöyle görünecektir:

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

Bu ikisi aynı şeyi yapar, ama AngularJS sürümünde şablona bakan herkes ne olması gerektiğini bilir. Geliştirme ekibine yeni bir üye katıldığında, buna bakabilir ve ardından üzerinde dropdownMenu adında bir direktifin çalıştığını bileceğini bilir; doğru cevabı sezmesine veya herhangi bir kodu incelemesine gerek yoktur. Görünüm bize ne olması gerektiğini söyledi. Çok daha temiz.

AngularJS'e yeni başlayan geliştiriciler genellikle şöyle bir soru sorar: Belirli türdeki tüm bağlantıları nasıl bulabilirim ve onlara bir yönerge (directive) ekleyebilirim? Geliştirici, bizim yanıtladığımızda her zaman şaşkına döner: Bunu yapmazsınız. Ama bunu yapmamanın nedeni, bunun yarı jQuery, yarı AngularJS gibi olması ve bunun iyi olmamasıdır. Buradaki sorun, geliştiricinin AngularJS bağlamında "jQuery yapmaya" çalışmasıdır. Bu asla iyi çalışmaz. Görünüm (view) resmî kayıttır. Bir yönerge dışında (bundan sonra detaylandırılacak), asla, asla, asla DOM'u değiştirmezsiniz. Ve yönergeler görünümde uygulanır, bu yüzden niyet nettir.

Unutmayın: önce tasarlayıp sonra işaretlemeyin. Önce mimariyi oluşturmalı, sonra tasarlamalısınız.

Veri bağlama

Bu, şüphesiz AngularJS'in en harika özelliklerinden biridir ve önceki bölümde bahsettiğim türdeki DOM manipülasyonlarını yapma gereksinimini büyük ölçüde ortadan kaldırır. AngularJS, görünümünüzü otomatik olarak güncelleyecektir, böylece sizin yapmanıza gerek kalmaz! jQuery'de, önce olaylara yanıt verir ve ardından içeriği güncelleriz. Şöyle bir şey:

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

Böyle görünen bir manzara için:

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

Kaygıları karıştırmanın yanı sıra, daha önce bahsettiğim niyeti ifade etme sorunlarıyla da karşı karşıyayız. Ama daha da önemlisi, bir DOM düğümüne manuel olarak başvurmak ve güncellemek zorundaydık. Ve bir kayıt girişini silmek istersek, bunun için de DOM ile kod yazmamız gerekiyor. Mantığı DOM'dan bağımsız olarak nasıl test ederiz? Ve ya sunumu değiştirmek istersek?

Bu biraz dağınık ve biraz narin. Ama AngularJS'te, bunu yapabiliriz:

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

Ve bizim görüşümüz bu şekilde görünebilir:

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

Ama bu konuda, görüşümüz şöyle görünebilir:

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

Ve şimdi sırasız bir liste kullanmak yerine, Bootstrap uyarı kutuları kullanıyoruz. Ve kontrolör kodunu hiç değiştirmemize gerek kalmadı! Ama daha da önemlisi, günlük nerede veya nasıl güncellenirse güncellensin, görünüm de değişecek. Otomatik olarak. Harika!

Burada göstermemiş olmama rağmen, veri bağlama çift yönlüdür. Yani bu günlük mesajları sadece şu şekilde yaparak görünümde de düzenlenebilir: <input ng-model="entry.msg" />. Ve büyük bir sevinç yaşandı.

Ayrı model katmanı

jQuery’de, DOM bir tür model gibidir. Ama AngularJS’de, görüntüden tamamen bağımsız olarak istediğimiz şekilde yönetebileceğimiz ayrı bir model katmanımız var. Bu, yukarıdaki veri bağlama için yardımcı olur, sorumlulukların ayrımını sürdürür ve çok daha yüksek test edilebilirlik sağlar. Diğer yanıtlar bu noktaya değindi, bu yüzden ben sadece bunu belirtmekle yetineceğim.

Sorunların ayrılması

Ve yukarıdakilerin tümü bu kapsamlı tema ile bağlantılıdır: endişelerinizi ayrı tutun. Görünümünüz, neyin olması gerektiğinin resmi kaydı olarak işlev görür (çoğunlukla); modeliniz verilerinizi temsil eder; yeniden kullanılabilir görevleri yerine getirmek için bir servis katmanınız vardır; DOM manipülasyonu yapar ve görünümünüzü direktiflerle zenginleştirirsiniz; ve bunların hepsini kontrolörlerle bir araya getirirsiniz. Bu, diğer yanıtlarda da belirtilmişti ve ekleyeceğim tek şey test edilebilirlik ile ilgilidir, bunu aşağıdaki başka bir bölümde tartışıyorum.

Bağımlılık enjeksiyonu

Ayrıştırma sorumluluklarına yardımcı olmak için bağımlılık enjeksiyonu (DI) vardır. Eğer sunucu tarafı bir dilden (Java’dan PHP’ye) geliyorsanız, muhtemelen zaten bu kavrama aşinasınızdır, ancak jQuery’den gelen bir istemci tarafı kişiyseniz, bu kavram saçma, gereksiz veya hipster gibi görünebilir. Ama öyle değildir. :-)

Geniş bir perspektiften bakıldığında, DI, bileşenleri çok özgür bir şekilde tanımlayabileceğiniz ve ardından herhangi bir diğer bileşenden sadece bir örneğini talep edebileceğiniz ve bunun size verileceği anlamına gelir. Yükleme sırası, dosya konumları veya buna benzer şeyleri bilmenize gerek yoktur. Güç hemen görünmeyebilir, ancak size sadece bir (yaygın) örnek vereceğim: test yapma.

Diyelim ki uygulamamızda, bir REST API üzerinden sunucu tarafı depolamayı uygulayan ve uygulama durumuna bağlı olarak yerel depolamayı da kullanan bir servise ihtiyaç duyuyoruz. Kontrollerimiz üzerinde testler çalıştırırken sunucu ile iletişim kurmak istemiyoruz - sonuçta kontrolcüyü test ediyoruz. Orijinal bileşenimizle aynı ada sahip bir sahte servis ekleyebiliriz ve enjekte edici, kontrolcümüzün sahte servisi otomatik olarak almasını sağlayacaktır - kontrolcümüz farkı bilmez ve bilmesine de gerek yoktur.

Testten bahsetmişken...

4. Test odaklı geliştirme - her zaman

Bu gerçekten mimari üzerine bölüm 3'ün bir parçası, ancak o kadar önemli ki onu kendi üst düzey bölümü olarak koyuyorum.

Gördüğünüz, kullandığınız veya yazdığınız birçok jQuery eklentisinin kaç tanesinin beraberinde bir test paketi vardı? Pek azı, çünkü jQuery bunu çok desteklemiyor. Ama AngularJS destekliyor.

jQuery'de, test etmenin tek yolu genellikle bileşeni bağımsız olarak, testlerimizin DOM manipülasyonu gerçekleştirebileceği bir örnek/demo sayfası ile oluşturmaktır. Dolayısıyla, bileşeni ayrı olarak geliştirmemiz ve sonra uygulamamıza entegre etmemiz gerekir. Ne kadar zahmetli! jQuery ile geliştirirken, çoğu zaman test odaklı geliştirme yerine yinelemeli geliştirmeyi tercih ediyoruz. Ve bizi kim suçlayabilir ki?

Ama endişelerin ayrımı olduğu için, AngularJS'te test odaklı geliştirmeyi yinelemeli olarak yapabiliriz! Örneğin, menümüzde mevcut rotamızı göstermek için süper basit bir yönerge istediğimizi varsayalım. Uygulamamızın görünümünde ne istediğimizi şu şekilde belirtebiliriz:

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

Tamam, şimdi var olmayan when-active yönergesi için bir test yazabiliriz:

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

Ve testimizi çalıştırdığımızda, başarısız olduğunu doğrulayabiliriz. Yalnızca şimdi yönergemizi oluşturmalıyız:

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

Testimiz şimdi geçiyor ve menümüz istenildiği gibi çalışıyor. Geliştirmemiz hem yinelemeli hem de test odaklı. Harika.

5. Kavramsal olarak, yönergeler paketlenmiş jQuery değildir

Sık sık "sadece bir direktifte DOM manipülasyonu yapın" duyarsınız. Bu bir gerekliliktir. Ona gerekli saygıyı gösterin!

Ama biraz daha derinlemesine bakalım...

Bazı yönergeler sadece görüntüde zaten olanı süsler (bkz. ngClass) ve bu nedenle bazen doğrudan DOM manipülasyonu yapar ve ardından temelde işlerini tamamlamış olurlar. Ancak bir yönerge bir "widget" gibiyse ve bir şablona sahipse, aynı zamanda endişelerin ayrımına da saygı göstermelidir. Yani, şablon da link ve controller fonksiyonlarındaki uygulamadan büyük ölçüde bağımsız kalmalıdır.

AngularJS, bunu çok kolay hale getirmek için tam bir araç seti ile geliyor; ngClass ile sınıfı dinamik olarak güncelleyebiliriz; ngModel iki yönlü veri bağlamaya izin verir; ngShow ve ngHide bir öğeyi programlı olarak gösterir veya gizler; ve kendimiz yazdıklarımız da dahil olmak üzere daha fazlası. Başka bir deyişle, DOM manipülasyonu yapmadan her türlü harikayı yapabiliriz. Ne kadar az DOM manipülasyonu olursa, direktifleri test etmek o kadar kolay olur, stil vermek o kadar kolay olur, gelecekte değiştirmek o kadar kolay olur ve o kadar yeniden kullanılabilir ve dağıtılabilir olur.

AngularJS'e yeni başlayan birçok geliştiricinin direktifleri bir sürü jQuery'yi atacakları yer olarak kullandığını görüyorum. Başka bir deyişle, "Kontrolörde DOM manipülasyonu yapamadığıma göre, o kodu alıp bir direktife koyacağım" diye düşünüyorlar. Bu kesinlikle çok daha iyi olsa da, genellikle hala yanlıştır.

Bölüm 3'te programladığımız kaydedici hakkında düşünün. Bunu bir yönergeye koysak bile, yine de bunu "Angular Yolu" ile yapmak istiyoruz. Hâlâ herhangi bir DOM manipülasyonu gerektirmiyor! DOM manipülasyonunun gerekli olduğu birçok durum vardır, ama düşündüğünüzden çok daha nadirdir! Uygulamanızın herhangi bir yerinde DOM manipülasyonu yapmadan önce, gerçekten buna ihtiyacınız olup olmadığını kendinize sorun. Daha iyi bir yol olabilir.

İşte en sık gördüğüm deseni gösteren hızlı bir örnek. Açılıp kapatılabilir bir buton istiyoruz. (Not: bu örnek biraz abartılı ve daha karmaşık durumları temsil etmek için biraz gereksiz uzun.)

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

Bununla ilgili birkaç yanlış var:

  1. Öncelikle, jQuery hiçbir zaman gerekli değildi. Burada yaptığımız hiçbir şey jQuery gerektirmiyordu!
  2. İkincisi, sayfamızda zaten jQuery bulunsa bile, burada kullanmamız için bir gerekçe yok; sadece angular.element kullanabiliriz ve bileşenimiz, jQuery olmayan bir projeye eklenmiş olsa bile çalışmaya devam edecektir.
  3. Üçüncüsü, bu direktifin çalışması için jQuery'nin gerekli olduğunu varsaysak bile, jqLite (angular.element) jQuery yüklüyse her zaman jQuery kullanacaktır! Bu yüzden $ kullanmamıza gerek yok - sadece angular.element kullanabiliriz.
  4. Dördüncü olarak, üçüncü ile yakından ilgili olarak, jqLite öğelerinin $ ile sarılmasına gerek yoktur - link fonksiyonuna geçirilen element zaten bir jQuery öğesi olacaktır!
  5. Ve beşinci olarak, daha önceki bölümlerde bahsettiğimiz gibi, neden şablon işleri mantığımıza karıştırıyoruz?

Bu yönerge (çok karmaşık durumlar için bile!) çok daha basit bir şekilde şöyle yeniden yazılabilir:

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

Yine, şablonla ilgili şeyler şablonda, bu yüzden siz (veya kullanıcılarınız) gerekli herhangi bir stile uyan bir şablonla kolayca değiştirebilirsiniz ve mantık asla dokunulmak zorunda kalmadı. Yeniden kullanılabilirlik - işte bu!

Ve hâlâ test etmek gibi tüm diğer faydalar da var - çok kolay! Şablonda ne olursa olsun, direktifin dahili API'sine asla dokunulmaz, bu yüzden refaktörleme kolaydır. Direktife dokunmadan şablonu istediğiniz kadar değiştirebilirsiniz. Ve ne değiştirirseniz değiştirin, testleriniz yine de geçer.

w00t!

Yani eğer direktifler sadece jQuery benzeri fonksiyon koleksiyonları değilse, o zaman nedirler? Direktifler aslında HTML'in uzantılarıdır. Eğer HTML'in yapmasını istediğiniz bir şeyi yapmıyorsa, bunu yapmak için bir direktif yazarsınız ve ardından onu HTML'in bir parçasıymış gibi kullanırsınız.

Başka bir deyişle, eğer AngularJS kutudan çıktığı gibi bir şeyi yapmıyorsa, ekibin bunu ngClick, ngClass vb. ile uyumlu hale getirmek için nasıl başaracağını düşünün.

Özet

jQuery bile kullanma. Hatta dahil etme. Seni geri tutar. Ve jQuery ile nasıl çözeceğini bildiğini düşündüğün bir sorunla karşılaştığında, $’a uzanmadan önce, bunu AngularJS sınırları içinde nasıl yapabileceğini düşünmeye çalış. Bilmiyorsan, sor! 20 sorundan 19’unda, bunu yapmanın en iyi yolu jQuery gerektirmez ve jQuery ile çözmeye çalışmak senin için daha fazla iş çıkarır.

Cevap #2

Emir kipi → bildirme kipi

jQuery'de, seçiciler DOM öğelerini bulmak ve onlara olay işleyicileri bağlamak/kaydettirmek için kullanılır. Bir olay tetiklendiğinde, o (emredici) kod DOM'u güncellemek/değiştirmek için çalışır.

AngularJS'te, DOM öğeleri yerine görünümler üzerine düşünmek istersiniz. Görünümler, AngularJS yönergeleri içeren (beyan edici) HTML'dir. Yönergeler, arka planda bizim için olay işleyicilerini ayarlar ve bize dinamik veri bağlama sağlar. Seçiciler nadiren kullanılır, bu yüzden ID'lere (ve bazı sınıf türlerine) olan ihtiyaç büyük ölçüde azalır. Görünümler, modeller ile ilişkilidir (scope'lar aracılığıyla). Görünümler modelin bir yansımasıdır. Olaylar modelleri (yani verileri, scope özelliklerini) değiştirir ve bu modelleri yansıtan görünümler "otomatik olarak" güncellenir.

AngularJS'de verilerinizi tutan jQuery ile seçilmiş DOM elemanları yerine modelleri düşünün. Görünümleri, kullanıcının gördüğünü manipüle etmek için geri çağrılar kaydetmek yerine, bu modellerin yansımaları olarak düşünün.

Sorunların ayrılması

jQuery, müdahaleci olmayan JavaScript kullanır - davranış (JavaScript) yapıdan (HTML) ayrılmıştır.

AngularJS, görünüm/yapıdan (HTML) davranışı kaldırmak için denetleyiciler ve yönergeler (her birinin kendi denetleyicisi ve/veya derleme ve bağlama işlevleri olabilir) kullanır. Angular ayrıca uygulamanızı ayırmanıza/düzenlemenize yardımcı olmak için servisler ve filtreler de sağlar.

Ayrıca bkz. https://stackoverflow.com/a/14346528/215945

Uygulama tasarımı

Bir AngularJS uygulaması tasarlamanın bir yaklaşımı:

  1. Modellerinizi düşünün. Bu modeller için hizmetler veya kendi JavaScript nesnelerinizi oluşturun.
  2. Modellerinizi yani görünümlerinizi nasıl sunmak istediğinizi düşünün. Her görünüm için HTML şablonları oluşturun ve dinamik veri bağlama elde etmek için gerekli yönergeleri kullanın.
  3. Her görünüme bir denetleyici ekleyin (ng-view ve yönlendirme veya ng-controller kullanarak). Denetleyicinin, görünümün işini yapması için sadece ihtiyaç duyduğu model verilerini bulmasını/almasını sağlayın. Denetleyicileri mümkün olduğunca ince yapın.

Prototipsel miras

JavaScript prototipal kalıtımın nasıl çalıştığını bilmeden jQuery ile birçok şey yapabilirsiniz. AngularJS uygulamaları geliştirirken, JavaScript kalıtımını iyi anlıyorsanız bazı yaygın tuzaklardan kaçınabilirsiniz. Önerilen okuma: AngularJS'de kapsamın prototipal/prototip kalıtımının incelikleri nelerdir?

Cevap #3

AngularJS ve jQuery

AngularJS ve jQuery çok farklı ideolojiler benimser. Eğer jQuery’den geliyorsanız, bazı farklılıklar sizi şaşırtabilir. Angular sizi sinirlendirebilir.

Bu normal, devam etmelisin. Angular buna değer.

Büyük fark (ÖZET)

jQuery, DOM'un rastgele parçalarını seçmek ve onlara geçici değişiklikler yapmak için size bir araç seti verir. Parça parça istediğiniz hemen her şeyi yapabilirsiniz.

AngularJS bunun yerine size bir derleyici sunar.

Bu, AngularJS'in tüm DOM'unuzu baştan sona okuduğu ve onu kod olarak, kelimenin tam anlamıyla derleyiciye verilen talimatlar olarak ele aldığı anlamına gelir. DOM'da ilerlerken, AngularJS derleyicisine nasıl davranacağını ve ne yapacağını söyleyen belirli dizinleri (derleyici direktifleri) arar. Direktifler, özelliklerle, etiketlerle, sınıflarla veya hatta yorumlarla eşleşebilen JavaScript dolu küçük nesnelerdir.

Angular derleyicisi, DOM'un bir parçasının belirli bir direktifle eşleştiğini belirlediğinde, direktif fonksiyonunu çağırır ve ona DOM öğesini, herhangi bir özniteliği, mevcut $scope'u (bu bir yerel değişken deposudur) ve bazı diğer faydalı parçaları geçirir. Bu öznitelikler, Direktif tarafından yorumlanabilecek ve nasıl render yapılacağını ve ne zaman kendini yeniden çizmesi gerektiğini söyleyen ifadeler içerebilir.

Yönergeler daha sonra denetleyiciler, servisler vb. gibi ek Angular bileşenlerini de çekebilir. Derleyicinin çıkışında tamamen oluşmuş, bağlantıları yapılmış ve çalışmaya hazır bir web uygulaması ortaya çıkar.

Bu, Angular'ın Şablon Tabanlı olduğu anlamına gelir. Şablonunuz JavaScript'i yönlendirir, tersi değil. Bu, rollerin köklü bir şekilde tersine çevrilmesidir ve son 10 yıl kadar yazdığımız rahatsız edici olmayan JavaScript'in tam tersidir. Buna alışmak zaman alabilir.

Eğer bu fazla kuralcı ve sınırlayıcı gibi geliyorsa, bundan daha uzağı olamaz. Çünkü AngularJS HTML'inizi kod olarak ele alır, web uygulamanızda HTML seviyesinde ayrıntı düzeyi elde edersiniz. Her şey mümkündür ve birkaç kavramsal adım attığınızda çoğu şey şaşırtıcı şekilde kolaydır.

Haydi ayrıntılara inelim.

İlk olarak, Angular jQuery'nin yerine geçmez

Angular ve jQuery farklı şeyler yapar. AngularJS, size web uygulamaları üretmek için bir araç seti sunar. jQuery ise çoğunlukla DOM'u değiştirmek için araçlar sağlar. Eğer sayfanızda jQuery mevcutsa, AngularJS onu otomatik olarak kullanır. Eğer mevcut değilse, AngularJS jQuery Lite ile birlikte gelir; bu, kısaltılmış ama hâlâ tamamen kullanılabilir bir jQuery sürümüdür.

Misko jQuery'yi sever ve sizin onu kullanmanıza itiraz etmez. Ancak ilerledikçe, işinizin neredeyse tamamını kapsam, şablonlar ve direktiflerin bir kombinasyonunu kullanarak yapabileceğinizi göreceksiniz ve mümkün olduğunda bu iş akışını tercih etmelisiniz çünkü kodunuz daha ayrık, daha yapılandırılabilir ve daha Angular olacaktır.

Eğer jQuery kullanıyorsanız, onu her yere serpmemelisiniz. AngularJS'te DOM manipülasyonu için doğru yer bir direktiftir. Bunlar hakkında daha sonra daha fazla bilgi verilecektir.

Seçicilerle Göze Batmayan JavaScript vs. Bildirimsel Şablonlar

jQuery genellikle göze batmadan uygulanır. JavaScript kodunuz başlıkta (veya alt bilgi bölümünde) bağlanır ve bahsedildiği tek yer burasıdır. Sayfanın parçalarını seçmek için seçiciler kullanır ve bu parçaları değiştirmek için eklentiler yazarız.

JavaScript kontrol altında. HTML tamamen bağımsız bir varlığa sahip. HTML'iniz JavaScript olmadan da anlamsal kalır. Onclick öznitelikleri çok kötü bir uygulamadır.

AngularJS hakkında fark edeceğiniz ilk şeylerden biri özel özniteliklerin her yerde olmasıdır. HTML'iniz, temelde güçlendirilmiş onClick öznitelikleri olan ng öznitelikleriyle dolup taşacak. Bunlar direktiflerdir (derleyici direktifleri) ve şablonun modele bağlanmasının başlıca yollarından biridir.

Bunu ilk gördüğünüzde, AngularJS'i eski moda müdahaleci JavaScript olarak görüp kenara bırakmaya teşebbüs edebilirsiniz (ben de ilk başta öyle yaptım). Aslında, AngularJS bu kurallara uymaz. AngularJS'te HTML5'iniz bir şablondur. Web sayfanızı üretmek için AngularJS tarafından derlenir.

Bu ilk büyük farktır. jQuery için web sayfanız, üzerinde işlem yapılacak bir DOM'dur. AngularJS için HTML'iniz derlenecek bir koddur. AngularJS, tüm web sayfanızı okur ve yerleşik derleyicisini kullanarak onu kelimenin tam anlamıyla yeni bir web sayfasına derler.

Şablonunuz bildirgesel olmalıdır; anlamı sadece okuyarak anlaşılabilir olmalıdır. Anlamlı isimlere sahip özel öznitelikler kullanırız. Yine anlamlı isimlere sahip yeni HTML elemanları uydururuz. Minimal HTML bilgisine sahip ve hiç kodlama becerisi olmayan bir tasarımcı, AngularJS şablonunuzu okuyabilir ve ne yaptığını anlayabilir. Değişiklik yapabilir. Bu Angular yoludur.

Şablon direksiyonun başında.

AngularJS'e başlarken ve eğitimleri takip ederken kendime sorduğum ilk sorulardan biri "Benim kodum nerede?" idi. Hiç JavaScript yazmamış olmama rağmen tüm bu davranışlara sahibim. Cevap açık. AngularJS DOM'u derlediği için, AngularJS HTML'inizi kod olarak işliyor. Birçok basit durumda, sadece bir şablon yazmak ve AngularJS'in bunu sizin için bir uygulamaya dönüştürmesini sağlamak genellikle yeterlidir.

Şablonunuz uygulamanızı yönlendirir. DSL olarak ele alınır. AngularJS bileşenleri yazarsınız ve AngularJS, bunları şablonunuzun yapısına göre doğru zamanda çekip kullanılabilir hale getirmekle ilgilenir. Bu, şablonun sadece çıktı için olduğu standart bir MVC deseninden çok farklıdır.

Örneğin, Ruby on Rails'ten ziyade XSLT'ye daha çok benziyor.

Bu, alışması biraz zaman alan radikal bir kontrol tersine çevirmesidir.

JavaScript'inizden uygulamanızı çalıştırmaya çalışmayı bırakın. Uygulamanın şablon tarafından çalıştırılmasına izin verin ve bileşenleri birbirine bağlamayı AngularJS'in halletmesine izin verin. Bu aynı zamanda Angular’ın yoludur.

Semantik HTML ve Semantik Modeller

jQuery ile HTML sayfanız, anlamsal olarak anlamlı içerik içermelidir. JavaScript kapalıysa (bir kullanıcı veya arama motoru tarafından) içeriğiniz erişilebilir olmaya devam eder.

Çünkü AngularJS, HTML sayfanızı bir şablon olarak ele alır. Şablonun semantik olması gerekmez çünkü içeriğiniz genellikle API'nizden gelen modelinizde depolanır. AngularJS, semantik bir web sayfası üretmek için DOM'unuzu modelle derler.

HTML kaynağınız artık semantik değil, bunun yerine API'niz ve derlenmiş DOM'unuz semantiktir.

AngularJS'te anlam modelde yaşar, HTML sadece bir şablondur, yalnızca görüntüleme için.

Bu noktada muhtemelen SEO ve erişilebilirlikle ilgili her türlü soruya sahipsiniz ve bu oldukça doğal. Burada çözülmemiş bazı sorunlar var. Çoğu ekran okuyucu artık JavaScript'i analiz edebiliyor. Arama motorları da AJAX ile yüklenen içeriği dizine ekleyebilir. Yine de, pushstate URL'lerini kullandığınızdan ve düzgün bir site haritanızın olduğundan emin olmak isteyeceksiniz. Konuyla ilgili tartışma için buraya bakın: https://stackoverflow.com/a/23245379/687677

Endişelerin ayrılması (SOC) vs. MVC

Ayrımcılık (SOC), SEO, erişilebilirlik ve tarayıcı uyumsuzluğu da dahil olmak üzere çeşitli nedenlerden dolayı yıllar süren web geliştirme süreci boyunca gelişen bir desendir. Şöyle görünür:

  1. HTML - Anlamsal anlam. HTML bağımsız olmalıdır.
  2. CSS - Stil verme, CSS olmadan sayfa yine de okunabilir.
  3. JavaScript - Davranış, script olmadan içerik kalır.

Yine, AngularJS onların kurallarına göre oynamaz. Bir darbe ile, AngularJS on yıllık kabul edilmiş bilgeliği ortadan kaldırır ve bunun yerine şablonun artık en azından biraz bile semantik olmadığı bir MVC desenini uygular.

Böyle görünüyor:

  1. Model - modelleriniz semantik verilerinizi içerir. Modeller genellikle JSON nesneleridir. Modeller, $scope adlı bir nesnenin öznitelikleri olarak bulunur. Ayrıca, şablonlarınızın erişebileceği kullanışlı yardımcı işlevleri $scope üzerinde de depolayabilirsiniz.
  2. Görünüm - Görünümleriniz HTML ile yazılır. Görünüm genellikle semantik değildir çünkü verileriniz modelde bulunur.
  3. Kontrolcü - Kontrolcünüz, görünümü modele bağlayan bir JavaScript fonksiyonudur. Fonksiyonu, $scope'u başlatmaktır. Uygulamanıza bağlı olarak, bir kontrolcü oluşturmanız gerekebilir veya gerekmez. Bir sayfada birden fazla kontrolcüye sahip olabilirsiniz.

MVC ve SOC aynı ölçeğin karşı uçlarında değildir, tamamen farklı eksenler üzerindedirler. SOC, AngularJS bağlamında hiçbir anlam ifade etmez. Onu unutmak ve devam etmek zorundasınız.

Eğer benim gibi tarayıcı savaşlarını yaşadıysanız, bu fikir size oldukça saldırgan gelebilir. Üzülmeyin, buna değer, söz veriyorum.

Eklentiler ve Yönergeler

Eklentiler jQuery'yi genişletir. AngularJS Direktifleri tarayıcınızın yeteneklerini genişletir.

jQuery'de eklentileri, jQuery.prototype'a fonksiyonlar ekleyerek tanımlarız. Daha sonra bunları, elementleri seçip eklentiyi sonuç üzerinde çağırarak DOM'a bağlarız. Amaç, jQuery'nin yeteneklerini genişletmektir.

Örneğin, sayfanızda bir karusel istiyorsanız, muhtemelen bir nav öğesiyle sarılmış resimlerden oluşan sırasız bir liste tanımlayabilirsiniz. Daha sonra sayfadaki listeyi seçmek ve kaydırma animasyonunu yapmak için zaman aşımı ile birlikte bir galeri olarak yeniden stil vermek üzere bazı jQuery yazabilirsiniz.

AngularJS'te, direktifler tanımlarız. Bir direktif, bir JSON nesnesi döndüren bir fonksiyondur. Bu nesne, AngularJS'e hangi DOM öğelerini araması gerektiğini ve bunlarda hangi değişiklikleri yapması gerektiğini söyler. Direktifler, ya sizin yarattığınız öznitelikler ya da öğeler kullanılarak şablona bağlanır. Amaç, HTML'in yeteneklerini yeni öznitelikler ve öğelerle genişletmektir.

AngularJS yöntemi, yerel görünümlü HTML'nin yeteneklerini genişletmektir. HTML gibi görünen, özel öznitelikler ve öğelerle genişletilmiş HTML yazmalısınız.

Eğer bir karusel istiyorsanız, sadece bir <carousel /> öğesi kullanın, sonra bir şablon çekmek için bir yönerge tanımlayın ve onu çalıştırın.

Küçük birçok yönerge vs. yapılandırma anahtarlı büyük eklentiler

jQuery ile eğilim, ardından birçok değer ve seçenek geçirerek yapılandırdığımız lightbox gibi büyük eklentiler yazmaktır.

Bu, AngularJS'te bir hatadır.

Bir açılır menü örneğini ele alın. Bir açılır menü eklentisi yazarken, tıklama işleyicileri kodlamaya, belki yukarı veya aşağı olan bir oka ekleme yapacak bir fonksiyon yazmaya, belki açılmış öğenin sınıfını değiştirmeye, menüyü gösterip gizlemeye teşebbüs edebilirsiniz; bunların hepsi faydalı şeylerdir.

Küçük bir değişiklik yapmak isteyene kadar.

Diyelim ki üzerine gelindiğinde açılmasını istediğiniz bir menünüz var. Şimdi bir sorunla karşı karşıyayız. Eklentimiz tıklama işleyicimizi bizim için bağladı, bu özel durumda farklı davranmasını sağlamak için bir yapılandırma seçeneği eklememiz gerekecek.

AngularJS'te daha küçük direktifler yazarız. Bizim açılır menü direktifimiz çok küçük olurdu. Katlanmış durumu koruyabilir ve fold(), unfold() veya toggle() metodlarını sağlayabilirdi. Bu metodlar basitçe durumu tutan boolean olan $scope.menu.visible değerini güncellerdi.

Şimdi şablonumuzda bunu bağlayabiliriz:

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

Fare üzerine gelindiğinde güncelleme gerekir mi?

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

Şablon uygulamayı yönlendirir, bu yüzden HTML düzeyinde ayrıntı elde ederiz. Duruma göre istisnalar yapmak istersek, şablon bunu kolaylaştırır.

Closure ve $scope

JQuery eklentileri bir kapsama içinde oluşturulur. Gizlilik bu kapsama içinde korunur. Bu kapsama içinde kapsam zincirinizi sürdürmek size bağlıdır. Aslında sadece jQuery tarafından eklentiye geçirilen DOM düğümleri setine, kapsama içinde tanımlanan yerel değişkenlere ve tanımladığınız global değişkenlere erişiminiz vardır. Bu, eklentilerin oldukça kendi kendine yeterli olduğu anlamına gelir. Bu iyi bir şeydir, ancak tüm bir uygulama oluştururken kısıtlayıcı olabilir. Dinamik bir sayfanın bölümleri arasında veri aktarmaya çalışmak zahmetli hale gelir.

AngularJS'in $scope nesneleri vardır. Bunlar, modelinizi sakladığınız, AngularJS tarafından oluşturulan ve yönetilen özel nesnelerdir. Bazı direktifler yeni bir $scope oluşturur ve varsayılan olarak bunu saran $scope'ten JavaScript prototip tabanlı kalıtım ile miras alır. $scope nesnesine denetleyici ve görünümde erişilebilir.

Burası zekice olan kısım. Çünkü $scope miras yapısı kabaca DOM yapısını takip eder, elemanlar kendi kapsamlarına ve içeren diğer tüm kapsamlarına sorunsuz bir şekilde, en üstteki global $scope'a kadar (ki bu küresel kapsam ile aynı değildir) erişebilirler.

Bu, verileri taşımayı ve verileri uygun bir seviyede depolamayı çok daha kolay hale getirir. Eğer bir açılır menü açılırsa, sadece açılır menünün $scope'u bunun hakkında bilgi sahibi olmalıdır. Eğer kullanıcı tercihlerini güncellerse, küresel $scope'u güncellemek isteyebilirsiniz ve kullanıcı tercihlerini dinleyen tüm iç içe $scope'lar otomatik olarak uyarılacaktır.

Bu kulağa karmaşık gelebilir, aslında bir kez rahatladığınızda, uçmak gibi. $scope nesnesini oluşturmanıza gerek yok, AngularJS onu sizin için doğru ve uygun şekilde, şablon hiyerarşinize göre başlatır ve yapılandırır. AngularJS daha sonra onu bağımlılık enjeksiyonunun sihri sayesinde bileşeniniz için kullanılabilir hale getirir (bununla ilgili daha sonra daha fazla bilgi vereceğiz).

Manuel DOM değişiklikleri vs. Veri Bağlama

jQuery'de tüm DOM değişikliklerinizi elle yaparsınız. Yeni DOM öğelerini programlı olarak oluşturursunuz. Eğer bir JSON diziniz varsa ve bunu DOM'a koymak istiyorsanız, HTML'yi oluşturmak ve eklemek için bir fonksiyon yazmanız gerekir.

AngularJS'te bunu da yapabilirsiniz, ancak veri bağlamayı kullanmanız teşvik edilir. Modelinizi değiştirin ve DOM buna bir şablon aracılığıyla bağlı olduğundan, DOM'unuz otomatik olarak güncellenecektir, herhangi bir müdahale gerekmemektedir.

Veri bağlama şablondan yapıldığı için, ya bir öznitelik kullanarak ya da süslü parantez sözdizimini kullanarak, yapmak süper kolaydır. Bununla ilişkili çok az bilişsel yük vardır, bu yüzden kendinizi bunu sürekli yaparken bulacaksınız.

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

Girdi öğesini $scope.user.name ile bağlar. Girdiyi güncellemek, mevcut kapsamınızdaki değeri güncelleyecek ve tersi de geçerlidir.

Aynı şekilde:

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

Kullanıcı adını bir paragrafta çıkaracaktır. Bu canlı bir bağlamdır, bu nedenle $scope.user.name değeri güncellenirse, şablon da güncellenecektir.

Her zaman Ajax

jQuery'de bir Ajax çağrısı yapmak oldukça basittir, ancak yine de iki kez düşünülebilecek bir şeydir. Düşünülmesi gereken ek bir karmaşıklık vardır ve bakımı yapılması gereken hatırı sayılır bir script kısmı vardır.

AngularJS'te, Ajax varsayılan başvuru çözümünüzdür ve bu neredeyse farkında olmadan sürekli olarak gerçekleşir. Şablonları ng-include ile dahil edebilirsiniz. En basit özel yönerge ile bir şablon uygulayabilirsiniz. Bir Ajax çağrısını bir serviste sarmalayabilir ve kendinize bir GitHub servisi veya bir Flickr servisi oluşturabilirsiniz, bunlara şaşırtıcı bir kolaylıkla erişebilirsiniz.

Servis Nesneleri vs Yardımcı Fonksiyonlar

jQuery'de, bir API'den bir besleme çekmek gibi küçük, DOM ile ilgili olmayan bir görevi gerçekleştirmek istiyorsak, bunu kaplamamızda yapmak için küçük bir fonksiyon yazabiliriz. Bu geçerli bir çözümdür, ancak o beslemeye sık sık erişmek istersek ne olur? Ya da o kodu başka bir uygulamada yeniden kullanmak istersek ne olur?

AngularJS bize servis nesneleri verir.

Servisler, fonksiyonlar ve veriler içeren basit nesnelerdir. Her zaman singletondırlar, yani birden fazlası olamaz. Diyelim ki Stack Overflow API'sine erişmek istiyoruz, bu durumda bunun için yöntemler tanımlayan bir StackOverflowService yazabiliriz.

Diyelim ki bir alışveriş sepetimiz var. Sepetimizi yöneten ve öğe ekleme ve çıkarma yöntemlerini içeren bir ShoppingCartService tanımlayabiliriz. Servis bir singleton olduğu ve diğer tüm bileşenlerle paylaşıldığı için, ihtiyacı olan her nesne alışveriş sepetine yazabilir ve verilerini çekebilir. Her zaman aynı sepet vardır.

Servis nesneleri, ihtiyacımız doğrultusunda kullanabileceğimiz ve yeniden kullanabileceğimiz kendi kendine yeten AngularJS bileşenleridir. Fonksiyonlar ve veriler içeren basit JSON nesneleridir. Her zaman tekil (singleton) olduklarından, bir yerde bir serviste veri saklarsanız, aynı servisi talep ederek başka bir yerde bu veriyi alabilirsiniz.

Bağımlılık enjeksiyonu (DI) vs. Örnekleme - diğer adıyla spagettiyi çözme

AngularJS, bağımlılıklarınızı sizin için yönetir. Eğer bir nesne istiyorsanız, sadece ona başvurun ve AngularJS sizin için onu alacaktır.

Bunu kullanmaya başlayana kadar, bunun ne kadar büyük bir zaman kazancı olduğunu açıklamak zor. jQuery içinde AngularJS DI gibi bir şey yok.

DI, uygulamanızı yazmak ve birlikte bağlamak yerine, her biri bir dize ile tanımlanan bir bileşen kütüphanesi tanımladığınız anlamına gelir.

Diyelim ki 'FlickrService' adında, Flickr'dan JSON beslemeleri çekmek için yöntemler tanımlayan bir bileşenim var. Şimdi, Flickr'a erişebilen bir denetleyici yazmak istiyorsam, denetleyiciyi tanımladığımda sadece 'FlickrService'ye isimle atıfta bulunmam yeterli. AngularJS, bileşeni örneklemeyi ve denetleyicime kullanılabilir hale getirmeyi halledecektir.

Örneğin, burada bir servis tanımlıyorum:

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

Şimdi bu hizmeti kullanmak istediğimde, ona sadece bu şekilde isimle atıfta bulunuyorum:

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

AngularJS, bir denetleyiciyi başlatmak için bir FlickrService nesnesine ihtiyaç duyulduğunu fark edecek ve bizim için bir tane sağlayacaktır.

Bu, şeyleri birbirine bağlamayı çok kolay hale getirir ve spagettileşme eğilimini neredeyse ortadan kaldırır. Bileşenlerin düz bir listesine sahibiz ve AngularJS onları ihtiyaç duyduğumuz şekilde teker teker bize verir.

Modüler hizmet mimarisi

jQuery, kodunuzu nasıl organize etmeniz gerektiği hakkında çok az şey söyler. AngularJS'in fikirleri vardır.

AngularJS, kodunuzu yerleştirebileceğiniz modüller sağlar. Örneğin, Flickr ile konuşan bir betik yazıyorsanız, tüm Flickr ile ilgili işlevlerinizi sarmak için bir Flickr modülü oluşturmak isteyebilirsiniz. Modüller diğer modülleri içerebilir (DI). Ana uygulamanız genellikle bir modüldür ve bu modül, uygulamanızın bağımlı olacağı tüm diğer modülleri içermelidir.

Basit kod tekrar kullanımı elde edersiniz, eğer Flickr tabanlı başka bir uygulama yazmak isterseniz, yalnızca Flickr modülünü dahil edebilirsiniz ve işte, yeni uygulamanızda tüm Flickr ile ilgili işlevlerinize erişiminiz olur.

Modüller AngularJS bileşenlerini içerir. Bir modülü dahil ettiğimizde, o modüldeki tüm bileşenler benzersiz stringleri ile tanımlanan basit bir liste olarak kullanılabilir hale gelir. Daha sonra bu bileşenleri AngularJS'in bağımlılık enjeksiyonu mekanizmasını kullanarak birbirlerine enjekte edebiliriz.

Özetlemek gerekirse

AngularJS ve jQuery düşman değildir. jQuery'yi AngularJS içinde çok güzel bir şekilde kullanmak mümkündür. AngularJS'i iyi şekilde kullanıyorsanız (şablonlar, veri bağlama, $scope, direktifler vb.) normalde ihtiyaç duyabileceğinizden çok daha az jQuery'ye ihtiyaç duyduğunuzu göreceksiniz.

Asıl fark etmeniz gereken şey, şablonunuzun uygulamanızı yönlendirdiğidir. Her şeyi yapan büyük eklentiler yazmaya çalışmayı bırakın. Bunun yerine, bir işi yapan küçük yönergeler yazın, sonra bunları bir araya getirmek için basit bir şablon yazın.

Göze batmayan JavaScript hakkında daha az düşünün ve onun yerine HTML uzantıları açısından düşünün.

Benim küçük kitabım

AngularJS hakkında o kadar heyecanlandım ki, hakkında kısa bir kitap yazdım, çevrimiçi olarak okumak için çok davetlisiniz http://nicholasjohnson.com/angular-book/. Umarım faydalı olur.

Cevap #4

Gerekli olan paradigma değişimini tanımlayabilir misiniz?

Emir Kipi vs Bildirim Kipi

jQuery ile DOM'a neler olacağını adım adım söylersiniz. AngularJS ile ise hangi sonuçları istediğinizi anlatırsınız ama bunu nasıl yapacağınızı değil. Bununla ilgili daha fazla bilgiye buradan ulaşabilirsiniz. Ayrıca, Mark Rajcok'un cevabına da göz atın.

İstemci tarafı web uygulamalarını nasıl farklı bir şekilde tasarlar ve mimarilerini oluştururum?

AngularJS, MVC modelini kullanan tam bir istemci tarafı çerçevedir (grafiksel gösterimlerine göz atın). Büyük ölçüde sorumlulukların ayrılmasına odaklanır.

En büyük fark nedir? Ne yapmayı/kullanmamayı bırakmalıyım; onun yerine ne yapmaya/kullanmaya başlamalıyım?

jQuery bir kütüphanedir

AngularJS, MVC, bağımlılık enjeksiyonu, veri bağlama ve çok daha fazlası gibi tonlarca harika şeyi birleştiren, son derece test edilebilir güzel bir istemci tarafı çerçevesidir.

Bu, test odaklı geliştirmeyi kolaylaştıran endişelerin ayrılmasına ve test etmeye (birim testi ve uçtan uca test) odaklanır.

Başlamanın en iyi yolu, onların harika eğitim kılavuzunu incelemektir. Adımlardan birkaç saat içinde geçebilirsiniz; ancak, perde arkasındaki kavramları tamamen öğrenmek isterseniz, daha fazla okuma için çok sayıda referans da dahil etmişlerdir.

Sunucu tarafında herhangi bir düşünce/restriksiyon var mı?

Bunu zaten saf jQuery kullandığınız mevcut uygulamalarda kullanabilirsiniz. Ancak, AngularJS özelliklerinden tam olarak yararlanmak istiyorsanız, sunucu tarafını RESTful bir yaklaşım kullanarak kodlamayı düşünebilirsiniz.

Bunu yapmak, sunucu tarafı RESTful API'nizin bir soyutlamasını oluşturan kaynak fabrikalarını kullanmanıza ve sunucu tarafı çağrılarını (al, kaydet, sil, vb.) inanılmaz derecede kolay hale getirmenize olanak tanır.

Cevap #5

"Paradigma değişimini" tanımlamak için, bence kısa bir cevap yeterli olabilir.

AngularJS, öğeleri bulma şeklinizi değiştirir

jQuery'de, genellikle seçiciler kullanarak öğeleri bulur ve sonra onları bağlarsınız:
$ ('#id .class').click(doStuff);

AngularJS içinde, yönergeleri doğrudan öğeleri işaretlemek ve onları bağlamak için kullanırsınız:
<a ng-click="doStuff()">

AngularJS, öğeleri seçiciler kullanarak bulmanızı gerekmez (ve istemez) - AngularJS'in jqLite ile tam kapsamlı jQuery arasındaki temel fark, jqLite'in seçicileri desteklememesidir.

Yani insanlar 'hiç jQuery eklemeyin' dediğinde, bunun nedeni genellikle seçicileri kullanmanı istememeleridir; bunun yerine yönergeleri kullanmayı öğrenmeni istiyorlar. Seçme değil, doğrudan!

Cevap #6

jQuery

jQuery, getElementByHerpDerp gibi saçma uzun JavaScript komutlarını daha kısa ve tarayıcılar arası uyumlu hale getirir.

AngularJS

AngularJS, kendi HTML etiketlerinizi/özelliklerinizi oluşturmanıza olanak tanır; bu etiketler dinamik web uygulamaları ile iyi çalışan işlevler yapar (çünkü HTML statik sayfalar için tasarlanmıştır).

Düzenle :

"'jQuery geçmişim var, AngularJS'te nasıl düşünürüm?' demek, 'HTML geçmişim var, JavaScript'te nasıl düşünürüm?' demeye benzer. Bu soruyu soruyor olmanız, büyük olasılıkla bu iki kaynağın temel amaçlarını anlamadığınızı gösteriyor. Bu yüzden soruyu cevaplamayı, 'AngularJS yönergeleri kullanır, jQuery ise bir jQuery nesnesi oluşturmak için CSS seçicilerini kullanır, bu da şunu veya bunu yapar...' gibi bir listeyle anlatmak yerine, temel farkı işaret ederek yapmayı tercih ettim. Bu soru uzun bir cevabı gerektirmez.

jQuery, tarayıcıda JavaScript programlamayı kolaylaştırmanın bir yoludur. Daha kısa, tarayıcılar arası komutlar vb.

AngularJS, HTML'i genişletir, böylece bir uygulama yapmak için her yerde <div> kullanmak zorunda kalmazsınız. HTML'in aslında statik, eğitim amaçlı web sayfaları için tasarlanmış olmasından ziyade uygulamalar için çalışmasını sağlar. Bunu dolaylı bir şekilde JavaScript kullanarak yapar, ancak temelde HTML'in, JavaScript değil, bir uzantısıdır.

Cevap #7

jQuery: DOM öğeleri için 'DOM'u SORGULAmayı' ve bir şeyler yapmayı çok düşünüyorsun.

AngularJS: MODEL gerçektir ve siz her zaman o AÇIDAN düşünürsünüz.

Örneğin, DOM'da belirli bir formatta göstermek için sunucudan veri aldığınızda, jQuery'de bu veriyi yerleştirmek istediğiniz DOM konumunu '1. BULmanız', ardından oraya yeni bir düğüm oluşturarak veya sadece innerHTML'i ayarlayarak '2. GÜNCELLEME/EKLEME' yapmanız gerekir. Daha sonra bu görünümü güncellemek istediğinizde, konumu '3. BUL'up '4. GÜNCELLE'meniz gerekir. Sunucudan veri alma ve formatlama bağlamında yapılan bul ve güncelle döngüsü AngularJS'te yoktur.

AngularJS ile modeliniz (zaten alışık olduğunuz JavaScript nesneleri) vardır ve modelin değeri size model hakkında (açıkçası) ve görünüm hakkında bilgi verir, ve model üzerinde yapılan bir işlem otomatik olarak görünüme yansır, bu yüzden bunun hakkında düşünmek zorunda değilsiniz. AngularJS ile kendinizi artık DOM'da bir şeyler aramazken bulacaksınız.

Başka bir deyişle, jQuery'de CSS seçicilerini düşünmeniz gerekir; yani hangi div veya td sınıfa veya özelliğe sahip, vb., böylece onların HTML'sini, rengini veya değerini alabilirim, ancak AngularJS'de kendinizi şöyle düşünürken bulacaksınız: hangi modelle ilgileniyorum, modelin değerini true olarak ayarlayacağım. Bu değeri yansıtan görünümün işaretlenmiş bir kutu mu yoksa bir td elemanında mı olduğunu düşünmekle uğraşmazsınız (jQuery'de sık sık düşünmeniz gereken detaylar).

Ve AngularJS'de DOM manipülasyonu ile, kendinizi yönergeler ve filtreler eklerken bulursunuz; bunları geçerli HTML uzantıları olarak düşünebilirsiniz.

AngularJS'te deneyimleyeceğiniz bir şey daha var: jQuery'de jQuery fonksiyonlarını çokça çağırırsınız, AngularJS'te ise AngularJS sizin fonksiyonlarınızı çağırır, yani AngularJS size 'işleri nasıl yapacağınızı' söylemez, ama faydaları buna değer, bu yüzden AngularJS öğrenmek genellikle AngularJS'in ne istediğini veya fonksiyonlarınızı nasıl sunmanız gerektiğini öğrenmek anlamına gelir ve AngularJS buna göre çağırır. Bu, AngularJS'i bir kütüphaneden çok bir framework yapan şeylerden biridir.

Cevap #8

Bunlar bazı çok güzel, ama uzun yanıtlar.

Deneyimlerimi özetlemek gerekirse:

  1. Kontroller ve sağlayıcılar (servisler, fabrikalar vb.) veri modelini değiştirmek içindir, HTML değil.
  2. HTML ve yönergeler, düzeni ve modele bağlamayı tanımlar.
  3. Eğer kontrolcüler arasında veri paylaşmanız gerekiyorsa, bir servis veya fabrika oluşturun - bunlar uygulama genelinde paylaşılan tekil (singleton) nesnelerdir.
  4. Bir HTML widget'ına ihtiyacınız varsa, bir yönerge oluşturun.
  5. Eğer elinizde bazı veriler varsa ve şimdi HTML'i güncellemeye çalışıyorsanız... DURUN! Modeli güncelleyin ve HTML'inizin modele bağlı olduğundan emin olun.

Cevap #9

jQuery bir DOM manipülasyon kütüphanesidir.

AngularJS bir MV* çerçevesidir.

Aslında, AngularJS, nadir JavaScript MV* çerçevelerinden biridir (birçok JavaScript MVC aracı hâlâ kütüphane kategorisine girmektedir).

Bir çerçeve olarak, kodunuzu barındırır ve ne zaman ve neyi çağıracağına dair kararların sorumluluğunu üstlenir!

AngularJS'in kendisi içinde bir jQuery-lite sürümü içerir. Bu nedenle bazı temel DOM seçimi/manipülasyonu için gerçekten jQuery kütüphanesini dahil etmenize gerek yoktur (bu, ağ üzerinden çalışırken birçok bayt tasarrufu sağlar).

AngularJS, DOM manipülasyonu ve yeniden kullanılabilir kullanıcı arayüzü bileşenleri tasarlamak için "Yönergeler" kavramına sahiptir, bu nedenle DOM manipülasyonu ile ilgili bir şeyler yapma ihtiyacı hissettiğinizde bunu kullanmalısınız (AngularJS kullanırken jQuery kodunu yazmanız gereken tek yer yönergelerdir).

AngularJS biraz öğrenme eğrisi içerir (jQuery'den daha fazla :-).

-->jQuery geçmişine sahip herhangi bir geliştirici için, ilk tavsiyem şudur: "AngularJS gibi zengin bir çerçeveye atlamadan önce JavaScript'i birinci sınıf bir dil olarak öğrenin!" Yukarıdaki gerçeği ben zor yoldan öğrendim.

İyi şanslar.

Cevap #10

Onlar elma ve portakal. Onları karşılaştırmak istemezsiniz. İkisi farklı şeylerdir. AngularJs zaten jQuery lite'ı içinde barındırıyor, bu da tam jQuery sürümünü dahil etmeden temel DOM manipülasyonu yapmanıza olanak tanıyor.

jQuery tamamen DOM manipülasyonu ile ilgilidir. Aksi takdirde uğraşmak zorunda kalacağınız tüm tarayıcılar arası sorunları çözer, ancak AngularJS gibi uygulamanızı bileşenlere ayırmanıza izin veren bir çerçeve değildir.

AngularJs hakkında güzel bir şey, DOM manipülasyonunu direktiflerde ayırmanıza/izole etmenize izin vermesidir. Kullanmanız için hazır yerleşik direktifler vardır, örneğin ng-click. Tüm görünüm mantığınızı veya DOM manipülasyonunuzu içerecek kendi özel direktiflerinizi oluşturabilirsiniz, böylece işletme mantığıyla ilgilenmesi gereken kontrolörlerde veya servislerde DOM manipülasyon kodunu karıştırmamış olursunuz.

Angular uygulamanızı - Kontrolcüler - Servisler - Görünümler - vb. - bölümlere ayırır.

ve bir şey daha var, o da direktif. Bu, herhangi bir DOM öğesine ekleyebileceğiniz bir özniteliktir ve içinde jQuery ile deli gibi şeyler yapabilirsiniz, jQuery'nin AngularJs bileşenleriyle çakışmasından veya mimarisini bozmasından endişe etmenize gerek yok.

Katıldığım bir meetup'tan duydum, Angular'ın kurucularından biri, DOM manipülasyonunu ayırmak için gerçekten çok çalıştıklarını söyledi, bu yüzden onları tekrar dahil etmeye çalışmayın.

Cevap #11

Orijinal AngularJS yaratıcıları Misko Hevery ve Igor Minar'ın yer aldığı JavaScript Jabber: Bölüm #32 podcast'ini dinleyin. Özellikle jQuery olmak üzere diğer JavaScript geçmişlerinden AngularJS'e gelmenin nasıl bir şey olduğunu çok fazla konuşuyorlar.

Podcast'te yapılan noktalardan biri, sorunuzla ilgili olarak birçok şeyin benim için oturmasını sağladı:

MISKO: [...] Angular'da çok düşündüğümüz şeylerden biri, size çok sayıda çıkış yolu sağlamak, yani buradan bir yol bulup çıkabilmenizi nasıl sağlarız, oldu. Bizim için cevabı "Yönergeler" olarak adlandırılan şeydir. Ve yönergelerle, temelde normal küçük bir jQuery JavaScript'i gibi olursunuz, ne yapmak isterseniz yapabilirsiniz.

IGOR: Direktifi, derleyiciye, şablonda bu belirli öğe veya CSS ile karşılaştığında, bu tür kodu saklamasını söyleyen bir talimat olarak düşün ve bu kod, öğeden ve DOM ağacındaki o öğenin altındaki her şeyden sorumludur.

Tüm bölümün dökümü yukarıda verilen bağlantıda mevcuttur.

Yani, sorunuza doğrudan cevap vermek gerekirse: AngularJS -çok- fikir sahibidir ve gerçek bir MV* çerçevesidir. Ancak, direktiflerin içinde jQuery ile bildiğiniz ve sevdiğiniz tüm harika şeyleri hâlâ yapabilirsiniz. Sorun "jQuery’de yaptığım şeyi AngularJS’de nasıl yaparım?" değil, daha çok "jQuery’de yaptığım tüm şeyleri AngularJS ile nasıl tamamlarım?" meselesidir.

Aslında bunlar gerçekten iki çok farklı ruh hali.

Cevap #12

Bu soruyu ilginç buluyorum, çünkü JavaScript programlamasıyla ilk ciddi karşılaşmam Node.js ve AngularJS ile oldu. jQuery hiç öğrenmedim ve sanırım bu iyi bir şey, çünkü hiçbir şeyi unutmam gerekmiyor. Aslında, problemlerime jQuery çözümlerinden aktif olarak kaçınıyorum ve bunun yerine, onları çözmek için tamamen bir "AngularJS yolu" arıyorum. Bu yüzden, sanırım bu soruya cevabım temelde, "jQuery öğrenmemiş biri gibi düşünmek" ve jQuery'yi doğrudan dahil etme cazibesinden kaçınmak olurdu (açıkçası AngularJS, sahne arkasında bir dereceye kadar kullanıyor).

Cevap #13

AngularJS ve jQuery:

AngularJs ve JQuery, JQLite işlevselliği dışında her düzeyde tamamen farklıdır ve AngularJs temel özelliklerini öğrenmeye başladığınızda bunu göreceksiniz (aşağıda açıkladım).

AngularJs, bağımsız istemci tarafı uygulamalar geliştirmeyi sunan istemci tarafı bir çerçevedir. JQuery, DOM ile oynamak için kullanılan istemci tarafı bir kütüphanedir.

AngularJs Havalı Prensibi - UI'nizde bazı değişiklikler yapmak istiyorsanız, bunu model verisi değişikliği perspektifinden düşünün. Verinizi değiştirin ve UI kendini yeniden render edecektir. DOM ile her seferinde uğraşmanıza gerek yoktur, ta ki gerçekten gerekli olana kadar ve bu da Angular Direktifleri aracılığıyla yönetilmelidir.

Bu soruyu yanıtlamak için, AngularJS ile yaptığım ilk kurumsal uygulama deneyimimi paylaşmak istiyorum. İşte Angular'ın sağladığı en harika özellikler; bunlar sayesinde jQuery zihniyetimizi değiştirmeye başlıyoruz ve Angular'ı bir kütüphane olarak değil, bir çerçeve olarak görüyoruz.

İki yönlü veri bağlama harika: Tüm işlevselliğe sahip bir tablom vardı: GÜNCELLE, SİL, EKLE. Tablo modelini ng-repeat kullanarak bağlayan bir veri nesnem var. Sadece silme ve ekleme için tek satır basit JavaScript kodu yazmanız yeterli ve hepsi bu. Tablo modeli değiştiğinde tablo otomatik olarak anında güncellenir. Güncelleme işlevi gerçek zamanlıdır, bunun için kod yazmaya gerek yok. Harika hissediyorsunuz!!!

Yeniden kullanılabilir yönergeler süperdir: Yönergeleri bir yerde yazın ve uygulama genelinde kullanın. Aman Tanrım!!! Bu yönergeyi sayfalama, regex, doğrulamalar vb. için kullandım. Gerçekten harika!

Yönlendirme güçlüdür: Bunu nasıl kullanmak istediğiniz sizin uygulamanıza bağlıdır, ancak isteği belirli HTML ve kontrolöre (JavaScript) yönlendirmek için çok az kod satırı gerekir

Kontrolörler harikadır: Kontrolörler kendi HTML’lerinden sorumludur, ancak bu ayrım yaygın işlevsellik için de iyi çalışır. Eğer ana HTML’de bir düğmeye tıklanıldığında aynı işlevi çağırmak istiyorsanız, sadece her kontrolörde aynı işlev adını yazın ve bireysel kodları yazın.

Eklentiler: Uygulamanızda bir üst üste bindirme (overlay) göstermek gibi birçok benzer özellik vardır. Bunun için kod yazmanıza gerek yok, sadece wc-overlay olarak mevcut bir overlay eklentisini kullanın, bu otomatik olarak tüm XMLHttpRequest (XHR) isteklerini halledecektir.

RESTful mimari için idealdir: Tam bir framework olması AngularJS'i RESTful mimari ile çalışmak için harika yapar. REST CRUD API'lerini çağırmak çok daha kolaydır ve

Hizmetler: Servisleri kullanarak ortak kodları yazın ve denetleyicilerde daha az kod kullanın. Servisler, denetleyiciler arasında ortak işlevsellikleri paylaşmak için kullanılabilir.

Genişletilebilirlik: Angular, HTML yönergelerini Angular yönergeleri kullanarak genişletti. HTML içinde ifadeler yazın ve bunları çalışma zamanında değerlendirin. Kendi yönergelerinizi ve servislerinizi oluşturun ve bunları başka bir projede herhangi bir ek çaba harcamadan kullanın.

Cevap #14

Bir JavaScript MV* acemisi olarak ve tamamen uygulama mimarisine odaklanarak (sunucu/istemci tarafı konularını değil), kesinlikle aşağıdaki kaynağı tavsiye ederim (henüz bahsedilmediğine şaşırdım): Addy Osmani tarafından yazılan JavaScript Tasarım Desenleri, farklı JavaScript Tasarım Desenlerine giriş olarak. Bu yanıtta kullanılan terimler yukarıda bağlantısı verilen belgelerden alınmıştır. Kabul edilen yanıtta çok iyi ifade edilenleri tekrarlamayacağım. Bunun yerine, bu yanıt AngularJS’i (ve diğer kütüphaneleri) güçlendiren teorik arka planlara geri bağlantı verir.

Benim gibi, AngularJS'in (veya Ember.js, Durandal ve diğer MV* çerçevelerinin) birçok farklı JavaScript tasarım desenini bir araya getiren karmaşık bir çerçeve olduğunu hızlıca fark edeceksiniz.

Ayrıca, bir global framework'e dalmadan önce, her bir kalıp için (1) yerel JavaScript kodunu ve (2) daha küçük kütüphaneleri ayrı ayrı test etmenin daha kolay olduğunu gördüm. Bu, bir framework'ün hangi kritik sorunlara çözüm sunduğunu daha iyi anlamamı sağladı (çünkü sorunla şahsen yüzleşiyorsunuz).

Örneğin:

  • JavaScript Nesne Yönelimli Programlama (bu bir Google arama bağlantısıdır). Bir kütüphane değildir, ancak kesinlikle herhangi bir uygulama programlaması için bir ön koşuldur. Bana prototype, constructor, singleton ve decorator desenlerinin yerel uygulamalarını öğretti
  • jQuery/ Underscore, fasad deseni için (DOM'u manipüle etmek için WYSIWYG'ler gibi)
  • Prototype.js için prototype/ constructor/ mixin deseni
  • RequireJS/ Curl.js için modül deseni/ AMD
  • KnockoutJS için observable, yayınla/abonelik deseni

Not: Bu liste tam değildir ve 'en iyi kütüphaneler' değildir; sadece benim kullandığım kütüphaneler bunlardır. Bu kütüphaneler ayrıca daha fazla desen içerir, burada bahsedilenler sadece ana odakları veya orijinal amaçlarıdır. Bu listede eksik olduğunu düşündüğünüz bir şey varsa, lütfen yorumlarda belirtin, memnuniyetle eklerim.

Cevap #15

Aslında, eğer AngularJS kullanıyorsanız, artık jQuery'ye ihtiyacınız yok. AngularJS'in kendisi, jQuery ile yapabileceğiniz çoğu şey için çok iyi bir "yerine geçme" olan bağlama ve yönergeye sahiptir.

Genellikle AngularJS ve Cordova kullanarak mobil uygulamalar geliştiriyorum. jQuery'den ihtiyaç duyduğum TEK şey Seçiciydi.

Google'da arayarak, bağımsız bir jQuery seçici modülünün olduğunu görüyorum. Bu, Sizzle'dır.

Ve AngularJS kullanarak bir web sitesine hızlıca başlamama yardımcı olacak, jQuery Selector'un gücünden (Sizzle kullanarak) faydalanan küçük bir kod parçası yapmaya karar verdim.

Kodumu burada paylaştım: https://github.com/huytd/Sizzular

İlgili makaleler