Soru JQuery arka planım varsa “AngularJS'de Düşünmek” [kapalı]


İstemci tarafında uygulama geliştirmeye aşina olduğumu varsayalım. jQueryama şimdi kullanmaya başlamak istiyorum angularjs. Gerekli olan paradigma kaymasını tarif edebilir misiniz? İşte bir cevabı belirlemenize yardımcı olabilecek birkaç soru:

  • İstemci tarafı web uygulamalarını nasıl farklı şekilde tasarlarım 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?
  • Herhangi bir sunucu tarafı ile ilgili değerlendirme / kısıtlama var mı?

Aralarında detaylı bir karşılaştırma yapmıyorum jQuery ve AngularJS.


4525
2018-02-21 04:09


Menşei


"ASP.NET MVC" veya "RoR" ile aşina olanlar için - sadece "istemci tarafı MVC" olarak Açısal düşünün ve bu kadar. - Serge Shultz


Cevaplar:


1. Sayfanızı tasarlamayın ve ardından ile değiştirin DOM manipülasyonlar

JQuery'de bir sayfa tasarlıyorsunuz ve sonra bunu dinamikleştiriyorsunuz. Bunun nedeni jQuery'nin büyütme için tasarlandı ve bu basit öncülden inanılmaz derecede büyüdü.

Ama AngularJS'de, zihninizden mimarinizle baştan başlamalısınız. “DOM'un bu parçasına sahibim ve onu X yapmak istiyorum” diye düşünerek başlamak yerine, başarmak istediğiniz şeylerle başlamak zorundasınız, sonra uygulamanızı tasarlamaya başlayın ve nihayet görüşünüzü tasarlamaya gidin.

2. AngularJS ile jQuery yapmayın

Benzer şekilde, jQuery'nin X, Y ve Z'yi yaptığı fikriyle başlamayın, bu yüzden model ve kontrolörler için bunun üstüne AngularJS ekleyeceğim. Bu Gerçekten mi Yeni başlayanlar için, her zaman yeni AngularJS geliştiricilerinin jQuery'yi hiç kullanmamalarını tavsiye ederim, en azından "Açısal Yol" gibi şeyler yapmaya alışıncaya kadar.

Burada birçok geliştirici gördüm ve posta listesi üzerinde 150 veya 200 satır kod jQuery eklentileri ile bu ayrıntılı çözümler oluşturmak ve daha sonra AngularJS bir geri aramalar koleksiyonu ile yapıştırmak ve $applykafa karıştırıcı ve kıvrık olan; ama sonunda işe yarıyorlar! Sorun şu ki çoğu jQuery eklentisi, AngularJS'de kodun bir kısmında yeniden yazılabilir, burada aniden her şey anlaşılır ve basit olur.

En alt satır şudur: çözüm yaparken, önce "AngularJS'de düşünün"; Bir çözüm düşünemiyorsanız, topluluğa sorun; tüm bunlardan sonra eğer kolay bir çözüm yoksa sonra jQuery için ulaşmak için çekinmeyin. Ama jQuery'nin bir koltuk değneği olmasına izin vermeyin ya da AngularJS'yi asla ustalaşmayacaksınız.

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

Önce bunu biliyorum tek sayfalık uygulamalar Hangi uygulamaları. Onlar konum değil internet sayfaları. Bu yüzden sunucu tarafı geliştirici gibi düşünmeliyiz ek olarak Bir istemci tarafı geliştiricisi gibi düşünmek. Uygulamamızı bireysel, genişletilebilir, test edilebilir bileşenlere nasıl böleceğimizi düşünmeliyiz.

E sonra Nasıl bunu yapar mısın AngularJS'de nasıl düşünüyorsunuz? İşte jQuery ile karşılaştırılan bazı genel ilkeler.

Görüş "resmi kayıt"

JQuery'de, görünümü değiştirerek programlı olarak değiştiririz. Olarak tanımlanmış bir açılır menümüz olabilir. ul öyle:

<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, aşağıdaki gibi bir şeyle etkinleştiririz:

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

Sadece manzaraya baktığımızda, burada herhangi bir işlevsellik olduğu hemen belli değil. Küçük uygulamalar için, bu iyi. Ancak önemsiz olmayan uygulamalar için, işler hızla kafa karıştırıcı ve bakımı zorlaşır.

AngularJS'de, görünüm, görünüm tabanlı işlevselliğin resmi kaydıdır. bizim ul Beyanname bunun yerine şöyle olurdu:

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

Bu ikisi de aynı şeyi yapar, ancak AngularJS sürümünde şablona bakan herkes ne olması gerektiğini bilir. Geliştirme ekibinin yeni üyesi ne zaman gelirse, o zaman ona bakabilir ve bilmek diye bir yönerge var dropdownMenu üzerinde çalışma; Doğru cevabı bulmasına ya da herhangi bir koddan geçmesine gerek yoktur. Görüş, ne olması gerektiğini anlattı. Çok temiz.

AngularJS'e yeni gelen geliştiriciler genellikle şöyle bir soru soruyor: Belirli bir türdeki tüm bağlantıları nasıl bulabilirim ve onlara bir yönerge eklerim. Cevap verdiğimizde geliştirici her zaman yanıltıcıdır: siz yapmazsınız. Ama bunu yapmamanın nedeni, bunun yarı-jQuery, yarı-AngularJS ve iyi değil. Buradaki problem, geliştiricinin AngularJS bağlamında "jQuery" yapmaya çalıştığıdır. Bu asla iyi çalışmayacak. Görünüm olduğu resmi kayıt. Bir direktifin dışında (aşağıda daha fazlası), asla, asla, asla DOM'yi değiştir. Ve direktifler uygulanır görünüşte, bu yüzden niyet açıktır.

Unutmayın: tasarlamayın ve sonra işaretleyin. Mimar olmalı ve sonra tasarla.

Bağlanma verileri

Bu, AngularJS'nin en müthiş özelliklerinden bir tanesidir ve bir önceki bölümde bahsettiğim DOM manipülasyonlarının çeşitlerini yapma gereğini ortadan kaldırır. AngularJS otomatik olarak görünümünüzü güncelleyecek, böylece yapmanız gerekmeyecek! JQuery'de, etkinliklere yanıt verir ve içeriği güncelleriz. Gibi bir şey:

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

Buna benzeyen bir görünüm için:

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

Endişeleri karıştırmanın yanı sıra, daha önce bahsettiğim niyetin aynı sorunlarına da sahibiz. Ancak daha önemlisi, bir DOM düğümünü manuel olarak referans ve güncellememiz gerekiyordu. Ve eğer bir günlük girişini silmek istiyorsak, bunun için DOM'a karşı da kodlamalıyız. Mantığı DOM'den ayrı olarak nasıl test ederiz? Peki ya sunumu değiştirmek istiyorsak?

Bu biraz dağınık ve önemsiz bir zayıflık. Ama AngularJS'de bunu yapabiliriz:

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

Ve bakış açımız şöyle görünebilir:

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

Fakat bu konuda görüşümüz şöyle olabilir:

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

Şimdi sıralanmamış bir liste kullanmak yerine Bootstrap uyarı kutularını kullanıyoruz. Ve biz asla kontrolör kodunu değiştirmemiz gerekmedi! Ama daha önemlisi, önemli değil nerede veya Nasıl günlüğü güncellenir, görünüm de değişir. Otomatik olarak. Temiz!

Buraya göstermeme rağmen, veri bağlantısı iki yönlü. Yani bu günlük mesajları, sadece bunu yaparak görünümde de düzenlenebilir: <input ng-model="entry.msg" />. Ve çok sevinçliydi.

Farklı model katmanı

JQuery'de DOM, modele benzer. Ama AngularJS'de, istediğimiz şekilde, tamamen bağımsız bir şekilde yönetebileceğimiz ayrı bir model katmanımız var. Bu yukarıdaki veri bağlama için yardımcı olur, korur endişelerin ayrılığıve çok daha büyük bir test edilebilirlik sunar. Diğer cevaplar bu noktadan bahsetti, o yüzden bunu sadece bırakacağım.

Endişelerin ayrılması

Ve yukarıdakilerin hepsi bu aşırı temalı temaya bağlanır: endişelerinizi ayrı tutun. Görüşünüz, gerçekleşmesi gereken resmi kayıt olarak hareket ediyor (çoğunlukla); Modeliniz verilerinizi temsil eder; Yeniden kullanılabilir görevleri gerçekleştirmek için bir servis katmanınız var; DOM manipülasyonu yapar ve görüşünüzü direktiflerle artırırsınız; ve kontrolörlerle birlikte yapıştırın. Bu, diğer cevaplarda da belirtildi ve ekleyebileceğim tek şey, aşağıda başka bir bölümde tartıştığım test edilebilirlik ile ilgilidir.

Bağımlı enjeksiyon

Endişelerin ayrılmasıyla bize yardımcı olmak için bağımlılık enjeksiyonu (Di). Sunucu tarafı dilinden geliyorsanız Java için PHP) Muhtemelen bu kavramı zaten biliyorsunuzdur, ama jQuery'den gelen müşteri tarafı bir adamsanız, bu konsept aptaldan gereksiz yere yenilikçi bir şey gibi görünebilir. Ama değil. :-)

Geniş bir bakış açısıyla DI, bileşenleri çok özgürce ve daha sonra başka herhangi bir bileşenden bildirebileceğiniz anlamına gelir, sadece bunun için bir örnek isteyin ve verilecektir. Yükleme emri, dosya konumları veya bunun gibi herhangi bir şey hakkında bilgi sahibi olmanız gerekmez. Güç hemen görünmeyebilir, ancak sadece bir (ortak) örnek vereceğim: test.

Uygulamamızda şunu söyleyelim, sunucu tarafındaki depolamayı DİNLENME API ve uygulama durumuna bağlı olarak yerel depolama alanı. Kontrolörlerimizde testler yaparken, sunucuyla iletişim kurmak istemiyoruz - test ediyoruz kontrolör, hepsinden sonra. Sadece orijinal bileşenimizle aynı adda bir alay hizmeti ekleyebiliriz ve enjektör, denetleyicimizin otomatik olarak sahte olanı almasını sağlar - denetleyicimiz fark etmez ve aradaki farkı bilmez.

Testten bahsetmişken ...

4. Test odaklı gelişim - her zaman

Bu, mimarinin 3. bölümünün gerçekten bir parçası, ama onu en üst düzey bölüm olarak koymam çok önemli.

Gördüğünüz, kullandığınız veya yazdığınız birçok jQuery eklentisinden, bunlardan kaç tanesinin bir test paketi vardı? Çok fazla değil çünkü jQuery buna çok uygun değil. Ama AngularJS öyle.

JQuery'de, sınamanın tek yolu, bileşenin DOM manipulasyonunu gerçekleştirebildiği bir örnek / demo sayfası ile bağımsız olarak bileşeni oluşturmaktır. Öyleyse bir bileşeni ayrı ayrı geliştirmek zorundayız. sonra onu uygulamamızla bütünleştirin. Ne kadar rahatsız edici! Zamanın çoğunda jQuery ile geliştirirken, test odaklı geliştirme yerine tekrarlamayı tercih ederiz. Ve kim bizi suçlayabilir?

Ancak endişelerin ayrılmasından dolayı, AngularJS'de test odaklı geliştirmeyi yinelemeli olarak yapabiliriz! Örneğin, menüde mevcut rotamızın ne olduğunu göstermek için süper basit bir direktif istiyoruz diyelim. Uygulamamızın görünümünde ne istediğimizi ilan edebiliriz:

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

Tamam, şimdi olmayanlar için bir test yazabiliriz 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();
}));

Ve testimizi yaptığımız zaman, başarısız olduğunu onaylayabiliriz. Sadece şimdi direktifimizi yaratmalı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çti ve menümüz istenildiği gibi gerçekleştirir. Bizim gelişim her ikisi de tekrarlayan ve Test güdümlü. Wicked-serin.

5. Kavramsal olarak direktifler değil paketlenmiş jQuery

Sıklıkla "sadece bir yönergede DOM manipülasyonu" duyarsınız. Bu bir zorunluluktur. Son derece uygun bir şekilde davranın!

Ama biraz daha derine inelim ...

Bazı direktifler, halihazırda neyin var olduğunu süslemektedir (düşün ngClass) ve bu nedenle bazen DOM manipülasyonunu hemen yapar ve sonra temelde yapılır. Ancak bir yönerge bir "widget" gibi ise ve bir şablona sahipse Ayrıca endişelerin ayrılmasına saygı duymak. Yani, şablon çok link ve kontrolör fonksiyonlarındaki uygulamalarından büyük ölçüde bağımsız kalmalıdır.

AngularJS bunu çok kolay hale getirmek için bir dizi araçla birlikte gelir; ile ngClass Sınıfı dinamik olarak güncelleyebiliriz; ngModel iki yönlü veri bağlama sağlar; ngShow ve ngHide bir öğeyi programlı olarak gösterme veya gizleme; ve çok daha fazlası - kendimizi yazdığımızlar da dahil. Diğer bir deyişle, her çeşit beceriklilik yapabiliriz olmadan DOM manipülasyonu. Daha az DOM manipülasyonu, daha kolay direktifler test etmektir, stilleri ne kadar kolay, gelecekte değişmesi kolaylaşır ve daha tekrar kullanılabilir ve dağıtılabilirdir.

Ben bir grup jQuery atmak için direktifleri kullanarak AngularJS için yeni geliştiriciler bir sürü görüyorum. Başka bir deyişle, "denetleyicide DOM manipulasyonunu yapamadığımdan, bu kodu bir direktifte alacağım" diye düşünüyorlar. Bu kesinlikle daha iyi olsa da, genellikle Hala yanlış.

Bölüm 3'te programladığımız kaydediciyi düşünün. Bunu bir direktifte koyarsak bile yine bunu "Açısal Yolu" yapmak istiyorum. O yine herhangi bir DOM manipülasyonu almaz! DOM manipülasyonu gerektiğinde birçok kez var, ama bu bir çok düşündüğünden daha nadir! DOM manipülasyonunu yapmadan önce herhangi bir yer uygulamanızda gerçekten ihtiyacınız varsa kendinize sorun. Daha iyi bir yol olabilir.

İşte en sık gördüğüm deseni gösteren hızlı bir örnek. Değiştirilebilir bir düğme istiyoruz. (Not: Bu örnek biraz karmaşıktır ve tam olarak aynı şekilde çözülmüş daha karmaşık vakaları temsil etmek için bir atmaca görevidir.)

.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 yanlış olan birkaç şey var:

  1. İlk olarak, jQuery asla gerekli değildi. Burada yaptığımız hiçbir şey yok jQuery hiç!
  2. İkincisi, sayfamızda zaten jQuery olsa bile, burada kullanmak için bir neden yok; sadece kullanabiliriz angular.element ve bileşenimiz jQuery olmayan bir projeye düştüğünde çalışmaya devam edecektir.
  3. Üçüncü olarak, jQuery'yi varsayarak bile oldu Bu direktifin çalışması için gerekli, jqLite (angular.element) irade her zaman yüklüyse jQuery'yi kullanın! Yani kullanmamıza gerek yok $ - sadece kullanabiliriz angular.element.
  4. Dördüncüsü, üçüncü ile yakından ilişkilidir, jLLite öğelerinin sarılması gerekmez $ - element bu geçer link işlev olurdu zaten jQuery öğesi!
  5. Önceki bölümlerde de belirttiğimiz beşinci bölümde, şablon parçalarını neden bizim mantığımıza karıştırıyoruz?

Bu yönerge yeniden yazılabilir (çok karmaşık durumlarda bile!).

.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, şablondaki öğeler şablondadır, böylece siz (veya kullanıcılarınız), gerekli herhangi bir stile uygun bir şekilde kolayca takas edebilirsiniz. mantık asla dokunulmamalıydı. Yeniden kullanılabilirlik - patlama!

Ve hala test gibi diğer tüm faydalar var - bu kolay! Şablonda ne olursa olsun, direktifin dahili API'sine asla dokunulmaz, bu nedenle yeniden düzenleme kolaydır. Şablonu, direktifine dokunmadan istediğiniz kadar değiştirebilirsiniz. Ve ne değiştiğin önemli değil, testlerin hala geçer.

w00t!

Yani direktifler sadece jQuery benzeri işlevlerin koleksiyonları değilse, bunlar nedir? Direktifler aslında HTML uzantıları. HTML yapmak için ihtiyacınız olan bir şey yapmazsa, sizin için bunu yapmak için bir yönerge yazıp, HTML'nin parçasıymış gibi kullanın.

Başka bir deyişle, eğer AngularJS kutunun dışında bir şey yapmazsa, ekibin bunu nasıl yerine getireceğini nasıl başaracağını düşünün. ngClick, ngClassve diğ.

özet

JQuery'yi kullanmayın. Onu dahil etme. Seni geri tutacak. Ve bir sorunla karşılaştığınızda, jQuery'de nasıl çözüleceğini bildiğinizi sandınız. $, AngularJS sınırları içinde nasıl yapıldığını düşünmeye çalışın. Eğer bilmiyorsan sor! 20'den 19 kez, bunu yapmanın en iyi yolu jQuery'ye ihtiyaç duymaz ve jQuery ile çözmeyi denemeniz sizin için daha fazla iş sonuçlarına neden olur.


7187
2018-02-21 21:26



Ben JQuery ile açısal bir uygulama içinde çalışmaya dahil etmek, yazılan tüm mevcut JQuery eklentileri nedeniyle önemli kullanım durumu olduğunu düşünüyorum. Ben saf bir Açısal uygulama tutmak için jQuery içinde FancyBox yeniden yazma değilim. - taudep
@taudep Düşündüğünüz kadar düşünmüyoruz. Çoğu jQuery eklentisi, ucuz bir şekilde AngularJS'de yeniden yazılabilir ve bu durumlarda bunu yapmalıyız. Eşdeğeri olmayan bir kompleks için, o zaman git. Bölüm 2'den alıntı yapmak için: 'En alt satır şudur: çözüm yaparken, ilk önce AngularJS'de düşünün; Bir çözüm düşünemiyorsanız, topluluğa sorun; Tüm bunlardan sonra kolay bir çözüm yoksa, jQuery'ye ulaşmaktan çekinmeyin.. Ama jQuery'nin bir koltuk değneği olmasına izin vermeyin ya da asla AngularJS'ye hakim olmazsınız. ' [vurgu eklendi] - Josh David Miller
Bir Çinli bu harika cevaba tercüme eder, yardımcı olur. hanzheng.github.io/tech/angularjs/2013/10/28/... - Han Zheng
@Benno "DOM manipulasyonu" ile ne demek, direktifteki kodunuzun doğrudan DOM manipülasyonlarını gerçekleştirmemesidir. Bu kod DOM hakkında hiçbir şey bilmiyor, sadece modelinizde js değişkenlerini değiştiriyor. Evet, sonuç olarak DOM değiştirilir, fakat yazdığımız kodun dışında değişkenlerimize göre değişen bağlayıcılar vardır, fakat yönergenin içinde DOM hakkında bir ayrım yapmadan, bu konuda hiçbir şey bilmiyoruz. iş mantığı. JQuery örneğinizde, "bu metni bu öğeye ekler" diyerek doğrudan DOM'ı değiştiriyorsunuz - wired_in
@trusktr Bir geliştirme, bir AngularJS uygulamasında jQuery kullanarak bir giriş öğesinin değerini ayarlarsa, bir ağır hata. Benim düşünebildiğim tek istisna türü, girişi otomatik olarak değiştiren bağlantı noktası çok zor olan varolan bir jQuery eklentisidir. Bu durumda, uygulama ile birlikte satır içi değişiklikleri getirmek için bir geri aramada veya saatin ayarlanması kesinlikle gereklidir. - Josh David Miller


Zorlayıcı → beyan

JQuery'de seçiciler bulmak için kullanılır DOM öğelerini ve ardından olay işleyicilerini onlara bağlar / kaydeder. Bir olay tetiklendiğinde, bu (zorunlu) kod, DOM'ı güncellemek / değiştirmek için çalışır.

AngularJS'de düşünmek istersiniz görünümler DOM öğeleri yerine. Görünümler AngularJS içeren (bildirici) HTML'dir direktifler. Yönergeler, bizim için sahne arkasında olay işleyicilerini oluşturdu ve bize dinamik veri bağlama olanağı verdi. Seçmenler nadiren kullanılır, bu nedenle kimliklere (ve bazı tür sınıflarına) duyulan ihtiyaç büyük ölçüde azalır. Görüntüleme bağlı modeller (üzerinden). Görüşler modelin bir izdüşümüdür. Olaylar modelleri (yani, veriler, kapsam özellikleri) ve bu modelleri yansıtan görünümlerin "otomatik olarak" güncellenmesine neden olur.

AngularJS'de, verilerinizi tutan jQuery tarafından seçilen DOM öğeleri yerine modelleri düşünün. Kullanıcıların gördüklerini değiştirmek için geri aramaları kaydetmek yerine, bu modellerin izdüşümleri olarak görüşleri düşünün.

Endişelerin ayrılması

jQuery kullanır göze batmayan JavaScript - davranış (JavaScript) yapıdan (HTML) ayrılır.

AngularJS kullanır kontrolörleri ve davranışları görünümden / yapıdan (HTML) kaldırmak için direktifler (her biri kendi denetleyicisine ve / veya derleme ve bağlantı işlevlerine sahip olabilir). Açısal da vardır Hizmetler ve filtreler Uygulamanızı ayırmanıza / düzenlemenize yardımcı olur.

Ayrıca bakınız https://stackoverflow.com/a/14346528/215945

Uygulama tasarımı

AngularJS uygulamasını tasarlamada bir yaklaşım:

  1. Modellerini düşün. Bu modeller için hizmetler veya kendi JavaScript nesnelerini oluşturun.
  2. Modellerinizi nasıl sunmak istediğinizi düşünün. Dinamik veri bağlama almak için gerekli yönergeleri kullanarak, her görünüm için HTML şablonları oluşturun.
  3. Her görünüme bir denetleyici takın (ng görünümü ve yönlendirme veya ng denetleyicisi kullanarak). Denetleyicinin, yalnızca görevin işini yapmak için ihtiyaç duyduğu model verilerini bulmasını / almasını sağlayın. Denetleyicileri olabildiğince ince hale getirin.

Prototip kalıtım

JavaScript prototip mirasının nasıl çalıştığını bilmeden jQuery ile çok şey yapabilirsiniz. AngularJS uygulamalarını geliştirirken, JavaScript devralma hakkında iyi bir anlayışa sahipseniz, bazı yaygın tuzaklardan kaçınacaksınız. Önerilen Kaynaklar: AngularJS'de kapsam prototip / prototipik mirasın nüansları nelerdir?


408
2018-02-21 04:09



pls olabilir misin Bir dom elementinin görüşten nasıl farklı olduğunu açıklar mı? - rajkamal
@rajkamal, bir DOM elementi (belli ki) tek bir elementtir ve jQuery'de sıklıkla / hedef / manipülasyon yaptığımız şeydir. Açısal görünüm, ilgili DOM öğelerinin bir koleksiyonu / şablonudır: menü görünümü, başlık görünümü, altbilgi görünümü, sağ kenar çubuğu görünümü, profil görünümü, belki birden çok ana içerik görünümü (ng görünümünde değiştirilebilir). Temel olarak, sayfalarınızı farklı görünümlere ayırmak istersiniz. Her görünümün kendi ilişkili denetleyicisi vardır. Her görünüm modelinizin (lerinizin) bir bölümünü yansıtır. - Mark Rajcok
jQuery DEĞİL zorunlu. on ve when jQuery toplama nesnesinin üyeleri üzerinde çalışan daha yüksek sıralı işlevlerdir. - Jack Viers
Dolayısıyla, geri aramada ne tür bir kod yürütülür on? Zorunlu. - cwharris
Bu zorunluluk ve deklarasyon gerçekten sadece soyutlama meselesidir. Sonunda, tüm deklarasyonlu kodlar (ne yapılmalı), bir altprogramda geliştirici tarafından daha düşük bir soyutlama düzeyinde, çerçeve veya derleyici / yorumlayıcı tarafından zorunlu olarak uygulanır (nasıl yapılır). Genel olarak "jQuery zorunludur" demek, özellikle "manuel" DOM-manipülasyonu açısından çok daha fazla bildirimsel bir API sağladığı göz önüne alındığında oldukça garip bir ifadedir. - Alex


AngularJS vs jQuery

AngularJS ve jQuery çok farklı ideolojileri benimsiyor. JQuery'den geliyorsanız, şaşırtıcı olan bazı farklılıkları bulabilirsiniz. Açısal sizi kızdırır.

Bu normal, sen geçmelisin. Açısal değer buna değer.

Büyük fark (TLDR)

jQuery, DOM'ın rasgele bitlerini seçmek ve bunlara geçici değişiklikler yapmak için bir araç takımı sunar. Parçala parçalanmasını istediğiniz her şeyi yapabilirsiniz.

AngularJS bunun yerine size bir derleyici.

Bunun anlamı AngularJS'nin tüm DOM'ınızı yukarıdan aşağıya okur ve derleyici olarak yönergeler olarak kod olarak davranır. DOM geçerken, belirli görünüyor direktifler AngularJS derleyicisine nasıl davranılacağını ve ne yapacağını söyleyen (derleyici yönergeleri). Yönergeler, özniteliklere, etiketlere, sınıflara ve hatta yorumlara karşılık gelen JavaScript'le dolu küçük nesnelerdir.

Açısal derleyici, DOM'ın bir parçasının belirli bir yönerge ile eşleştiğini belirlediğinde, DOM işlevini, herhangi bir özniteliği, geçerli $ kapsamını (yerel değişken deposu olan) ve diğer bazı yararlı bitleri ileterek yönerge işlevini çağırır. Bu nitelikler Direktif tarafından yorumlanabilen ve nasıl oluşturulacağını ve ne zaman yeniden çizileceğini anlatan ifadeler içerebilir.

Direktifler daha sonra kontrolörler, servisler, vb. Gibi ek açısal bileşenleri de çekebilir. Derleyicinin dibinde çıkan, tamamıyla oluşturulmuş bir web uygulamasıdır.

Bu, Açısal'nın Şablon Tahrik Edildiği anlamına gelir. Şablonunuz JavaScript'i yönlendirir, başka şekilde değil. Bu, rollerin radikal bir tersine çevrilmesi ve son 10 yıldır yazdığımız göze batmayan JavaScript'in tam karşıtıdır. Bu alışmak biraz zaman alabilir.

Bu, aşırı-kuralcı ve sınırlayıcı olabileceği gibi geliyorsa, gerçeklerden hiçbir şey daha uzak olamaz. AngularJS, HTML’nizi kod olarak kabul ettiğinden Web uygulamanızda HTML düzeyinde ayrıntı düzeyi. Her şey mümkün ve birkaç kavramsal sıçrama yaptıktan sonra çoğu şey şaşırtıcı derecede kolay.

En cesur cesurluğa inelim.

İlk yukarı, Açısal jQuery yerini alamaz

Açısal ve jQuery farklı şeyler yapar. AngularJS size web uygulamaları üretmek için bir dizi araç sunar. jQuery esas olarak DOM'ı değiştirmek için araçlar sunar. Sayfanızda jQuery varsa, AngularJS bunu otomatik olarak kullanır. Değilse, AngularJS jQuery Lite ile birlikte gönderilir, bu kesilmiş bir kısaltmadır, ancak jQuery'nin mükemmel bir şekilde kullanılabilir halidir.

Misko jQuery'yi seviyor ve bunu kullanarak size karşı itiraz etmiyor. Bununla birlikte, çalışmalarınızın tamamını kapsam, şablonlar ve direktiflerin bir kombinasyonu kullanılarak yapabildiğiniz kadar ilerlemenizi sağlayacak ve kodunuz daha ayrık, daha yapılandırılabilir ve daha fazlası olacağından bu iş akışını mümkün olan yerlerde tercih etmelisiniz. Açısal.

JQuery'yi kullanırsanız, her yere serpilmemelisiniz. AngularJS'deki DOM manipülasyonu için doğru yer bir direktifte. Daha sonra bunlar hakkında daha fazla.

Seçici ve Deklarasyon Şablonları ile Göze Çarpan JavaScript

jQuery, tipik olarak göze batmayan şekilde uygulanır. JavaScript kodunuz başlığa (veya altbilgiye) bağlanır ve bu, bahsedilen tek yerdir. Sayfaların bitlerini seçmek ve bu parçaları değiştirmek için eklentileri yazmak için seçiciler kullanırız.

JavaScript kontrol altında. HTML tamamen bağımsız bir varoluşa sahiptir. HTML'niz, JavaScript olmadan bile semantik kalır. Onclick özellikleri çok kötü bir uygulamadır.

AngularJS hakkında ilk fark edeceğiniz şeylerden biri, özel özellikler her yerdedir. HTML'niz, temelde Steroidler'deki onClick öznitelikleri olan ng özelliklerine sahip olacak. Bunlar direktiflerdir (derleyici direktifleri) ve şablonun modele bağlandığı ana yollardan biridir.

Bunu ilk gördüğünüzde, eski okul müdahaleci Javascript olarak AngularJS'i yazmaya başlayabilirsiniz (ilk yaptığım gibi). Aslında, AngularJS bu kurallarla oynamaz. AngularJS'de, HTML5'iniz bir şablondur. Web sayfanızı üretmek için AngularJS tarafından derlenmiştir.

Bu ilk büyük fark. JQuery'ye göre, web sayfanız manipüle edilecek bir DOM'dır. AngularJS'ye, HTML'iniz derlenecek koddur. AngularJS, tüm web sayfanızda okur ve yerleşik derleyicisini kullanarak yeni bir web sayfasına derler.

Şablonunuz bildirimsel olmalıdır; Anlamı sadece okunarak açık olmalıdır. Özel isimleri anlamlı isimlerle kullanıyoruz. Yine anlamlı isimlerle yeni HTML unsurları oluşturuyoruz. Minimum HTML bilgisi ve kodlama becerisi olmayan bir tasarımcı, AngularJS şablonunuzu okuyabilir ve ne yaptığını anlayabilir. Değişiklikler yapabilir. Bu Açısal yoldur.

Şablon sürüş koltuğunda.

AngularJS'i başlatırken ve derslerde çalışırken kendime sorduğum ilk sorulardan biri "Kodum nerede?". JavaScript yazdım ve henüz tüm bu davranışlarım var. Cevap açık. AngularJS DOM'ı derlediği için, AngularJS HTML'nizi kod olarak ele alır. Birçok basit durumda, sadece bir şablon yazmak ve AngularJS'i sizin için bir uygulamaya derlemek yeterlidir.

Şablonunuz uygulamanızı yönlendirir. Bu bir DSL. AngularJS bileşenlerini yazarsınız ve AngularJS, şablonunuzun yapısına bağlı olarak onları çekip doğru zamanda kullanıma hazır hale getirecektir. Bu bir standart için çok farklı MVC şablon, sadece çıktı için şablon.

Daha benzer XSLT göre raylar üzerinde yakut Örneğin.

Bu, alışılagelen alışkanlıkları kontrol eden radikal bir inversiyon.

Uygulamanızı JavaScript'inizden sürmeye çalışmayın. Şablonun uygulamayı sürmesine izin verin ve AngularJS'nin bileşenleri kablolamakla ilgilenmesine izin verin. Bu aynı zamanda Açısal yoldur.

Semantik HTML ve Anlamsal Modeller

JQuery ile HTML sayfanız anlamsal anlamlı içerik içermelidir. JavaScript kapalıysa (bir kullanıcı veya arama motoru tarafından) içeriğiniz erişilebilir kalır.

AngularJS, HTML sayfanızı şablon olarak ele aldığından. İçeriğinizin genellikle API'nızdan gelen modelinizde depolandığından şablonun anlamsal olmaması gerekir. AngularJS, DOM'ınızı semantik bir web sayfası oluşturmak için modeliyle derler.

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

AngularJS'de, modeldeki yaşamlar anlamında, HTML sadece görüntülenmek üzere sadece bir şablondur.

Bu noktada muhtemelen her türlü sorunuz var. SEO ve erişilebilirlik ve haklı olarak. Burada açık sorunlar var. Çoğu ekran okuyucu şimdi JavaScript'i ayrıştıracak. Arama motorları da endekslenebilir AJAXed içeriği. Yine de, pushstate URL'lerini kullandığınızdan ve iyi bir site haritasına sahip olduğunuzdan emin olmak istersiniz. Sorunun tartışması için buraya bakın: https://stackoverflow.com/a/23245379/687677

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

Endişelerin ayrılması (SOC), SEO, erişilebilirlik ve tarayıcı uyumsuzluğu dahil olmak üzere çeşitli nedenlerle uzun yıllar boyunca web geliştirme konusunda büyüyen bir modeldir. Şuna benziyor:

  1. HTML - Anlamsal anlam. HTML yalnız kalmalı.
  2. CSS - Styling, CSS olmadan sayfa hala okunabilir.
  3. JavaScript - Davranış, komut dosyası olmadan içerik kalır.

Yine, AngularJS kuralları gereği oynamaz. Bir inme, AngularJS, alınan on bir bilgelikle yok oldu ve bunun yerine şablonun artık anlam taşımadığı, hatta biraz da olsa bir MVC kalıbı uygular.

Şuna benziyor:

  1. Model - modelleriniz semantik verilerinizi içerir. Modeller genellikle JSON nesneler. Modeller, $ scope adlı bir nesnenin öznitelikleri olarak bulunur. Ayrıca, kullanışlı yardımcı program işlevlerini şablonlarınızın erişebileceği $ kapsamına da kaydedebilirsiniz.
  2. Görünüm - Görünümleriniz HTML’de yazılır. Görünüm genellikle semantik değildir, çünkü verileriniz modelde kalmaktadır.
  3. Denetleyici - Denetleyiciniz, modele olan görünümü çengelleyen bir JavaScript işlevidir. İşlevi $ kapsamını başlatmaktır. Uygulamanıza bağlı olarak, bir denetleyici oluşturmanız gerekebilir veya olmayabilir. Bir sayfada birçok denetleyiciniz olabilir.

MVC ve SOC aynı ölçekte zıt uçlarda değil, tamamen farklı eksenlerde. SOC, AngularJS bağlamında anlam ifade etmez. Onu unutup devam etmelisin.

Eğer benim gibi tarayıcı savaşlarında yaşadıysanız, bu fikri oldukça rahatsız edici bulabilirsiniz. Üstesinden gel, buna değecek, söz veriyorum.

Eklentiler ve Direktifler

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

JQuery'de jQuery.prototype işlevlerine işlev ekleyerek eklentileri tanımlarız. Daha sonra, öğeleri seçerek ve sonuçta eklentiyi çağırarak bunları DOM'a bağlarız. Fikir jQuery yeteneklerini genişletmektir.

Örneğin, sayfanızda bir karusel istiyorsanız, belki de bir nav elemanına sarılmış, sıralanmamış bir rakam listesi tanımlayabilirsiniz. Daha sonra sayfadaki listeyi seçmek için bir jQuery yazabilir ve kayan animasyonu yapmak için zaman aşımları olan bir galeri olarak yeniden düzenleyebilirsiniz.

AngularJS'de direktifleri tanımlarız. Bir yönerge, bir JSON nesnesini döndüren bir işlevdir. Bu nesne AngularJS'ye hangi DOM öğelerinin bakacağını ve bunlara yapılacak değişikliklerin ne olduğunu söyler. Yönergeler, icat ettiğiniz nitelikler veya öğeler kullanılarak şablona bağlanır. Buradaki fikir, HTML'nin yeteneklerini yeni öznitelikler ve öğelerle genişletmektir.

AngularJS yolu yerli görünümlü HTML yeteneklerini genişletmektir. Özel nitelikler ve öğelerle genişletilen HTML gibi görünen HTML yazmalısınız.

Bir atlıkarınca istiyorsanız, sadece <carousel /> öğeyi, sonra bir şablonu çekmek için bir yönerge tanımlayın ve bu enayi çalışmasını yapın.

Yapılandırma anahtarlı büyük eklentilere karşı çok sayıda küçük direktif

JQuery ile olan eğilim, daha sonra çok sayıda değer ve seçeneklerle geçerek yapılandırdığımız lightbox gibi büyük büyük eklentiler yazmaktır.

Bu AngularJS'de bir hatadır.

Bir açılır pencere örneğini alın. Bir açılır kapanış eklentisi yazarken, tıklama işleyicilerinde kod yazmak isteyebilirsiniz, belki de yukarı veya aşağı bir chevron eklemek için bir işlev, belki de açılmamış öğenin sınıfını değiştir, menüyü gizle, tüm yararlı şeyleri göster.

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

Vurgulu olarak açmak istediğiniz bir menünüz olduğunu varsayalım. Peki şimdi bir sorunumuz var. Eklentimiz, tıklama işleyicimizde bizim için kablolu, bu özel durumda farklı davranmasını sağlamak için bir yapılandırma seçeneği eklememiz gerekecek.

AngularJS'de daha küçük direktifler yazıyoruz. Bizim açılan yönergemiz gülünç derecede küçük olurdu. Katlanmış durumu koruyabilir ve katlama (), açma () veya geçiş () için yöntemler sağlayabilir. Bu yöntemler, eyaleti tutan bir boolean olan $ scope.menu.visible dosyasını basitçe günceller.

şimdi şablonumuzda Bunu bağlayabiliriz:

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

Mouseover güncellemek mi ihtiyacınız var?

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

Şablon uygulamayı çalıştırır, böylece HTML düzeyinde ayrıntı düzeyi elde ederiz. Durum istisnaları ile durum yapmak istiyorsak, şablon bunu kolaylaştırır.

Kapatma ve $ kapsamı

JQuery eklentileri bir kapatmada oluşturulur. Gizlilik bu kapanışın içinde tutulur. Kapsam zincirinizi bu kapatma içinde tutmak size kalmıştır. Eklentiye jQuery tarafından iletilen DOM düğümlerine, ayrıca kapıda ve tanımladığınız tüm globals'ta tanımlanan yerel değişkenlere gerçekten erişebilirsiniz. Bu, eklentilerin oldukça kendine yeten 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 bir angarya olur.

AngularJS $ kapsam nesnelerine sahiptir. Bunlar, modelinizi kaydettiğiniz AngularJS tarafından oluşturulmuş ve korunan özel nesnelerdir. Belirli direktifler, varsayılan olarak JavaScript prototipik mirasını kullanarak sarma kapsamından miras alan yeni bir kapsam oluşturur. $ Kapsam nesnesine denetleyicide ve görünümde erişilebilir.

Bu akıllı kısım. $ Kapsam kalıtımı yapısı kabaca DOM yapısını takip ettiğinden, öğelerin kendi kapsamlarına erişimi vardır ve herhangi bir kapsam kapsamı, global kapsamı (global kapsam ile aynı değildir) kadardır.

Bu, verileri aktarmayı ve verileri uygun bir seviyede depolamayı çok daha kolay hale getirir. Bir açılır liste açılırsa, yalnızca açılır $ kapsamının bunu bilmesi gerekir. Kullanıcı tercihlerini güncellerse, genel $ kapsamını güncellemek isteyebilirsiniz ve kullanıcı tercihlerini dinleyen iç içe geçmiş kapsamlar otomatik olarak uyarılır.

Bu karmaşık gelebilir, aslında, bir kez rahatladığınızda, uçmak gibidir. $ Kapsam nesnesini oluşturmanıza gerek yoktur, AngularJS sizin için şablon hiyerarşinize göre doğru ve uygun bir şekilde sizin için yapılandırır ve yapılandırır. AngularJS daha sonra, bağımlılık enjeksiyonunun büyüsünü kullanarak bileşeninize sunar (daha sonra bunun üzerine).

Manuel DOM ile Veri Bağlama arasında değişiklik

JQuery'de tüm DOM değişikliklerinizi elle yapın. Yeni DOM öğelerini programatik olarak oluşturursunuz. Bir JSON diziniz varsa ve bunu DOM'a koymak istiyorsanız, HTML'yi oluşturmak ve eklemek için bir işlev yazmanız gerekir.

AngularJS'de bunu da yapabilirsiniz, ancak veri bağlamayı kullanmaya teşvik edildiniz. Modelinizi değiştirin ve DOM bir şablon aracılığıyla ona bağlı olduğundan DOM'nız otomatik olarak güncellenir, hiçbir müdahale gerekmez.

Veri bağlama, şablondan, bir özellik veya küme ayracı sözdizimi kullanılarak yapıldığı için, yapılması çok kolay. Onunla ilişkili küçük bir bilişsel yük vardır, böylece kendini her zaman yapıyorsunuz.

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

Giriş öğesini $scope.user.name. Girişi güncellemek, geçerli kapsamınızdaki değeri günceller ve bunun tersi de geçerlidir.

Aynı şekilde:

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

kullanıcı adını bir paragrafta gönderir. Bu canlı bir ciltleme, yani eğer $scope.user.name değer güncellenir, şablon da güncellenir.

Ajax her zaman

JQuery'de Ajax araması yapmak oldukça basittir, ancak yine de iki kez düşünebileceğiniz bir şeydir. Düşünmek için ek karmaşıklık ve devam etmek için senaryoların adil bir parçası var.

AngularJS'de, Ajax varsayılan go-to çözümünüzdür ve her zaman, neredeyse fark etmeden gerçekleşir. Ng içeren şablonlar ekleyebilirsiniz. En basit özel yönergeye sahip bir şablon uygulayabilirsiniz. Bir Ajax çağrısını bir servise sarmak ve kendiniz bir GitHub hizmet veya Flickr Şaşırtıcı kolaylıkla erişebileceğiniz servis.

Hizmet nesneleri vs yardımcı işlevler

JQuery'de, bir API'den bir özet akışını çekmek gibi dom olmayan küçük bir görev gerçekleştirmek istiyorsak, bunu kapatma işlemimizde yapmak için küçük bir işlev yazabiliriz. Bu geçerli bir çözümdür, ancak bu yayına sıklıkla erişmek istiyorsak ne olur? Bu kodu başka bir uygulamada tekrar kullanmak istersek ne olur?

AngularJS bize servis nesneleri verir.

Hizmetler, işlevler ve veriler içeren basit nesnelerdir. Onlar her zaman bekardırlar, yani hiçbir zaman birden fazla olamazlar. Yığın Taşması API'sine erişmek istediğimizi varsayalım, StackOverflowService Bunu yapmak için yöntemleri tanımlar.

Diyelim ki bir alışveriş sepetimiz var. Sepetimizi koruyan ve ürün ekleme ve çıkarma yöntemleri içeren bir ShoppingCartService tanımlayabiliriz. Hizmet tekil olduğundan ve diğer tüm bileşenler tarafından paylaşıldığı için, alışveriş sepetine yazması gereken ve ondan veri alabilen herhangi bir nesne. Her zaman aynı araba.

Hizmet nesneleri, uygun gördüğümüz şekilde kullanabileceğimiz ve yeniden kullanabileceğimiz bağımsız bir AngularJS bileşenidir. Bunlar, fonksiyonları ve Verileri içeren basit JSON nesneleridir. Her zaman bekarlar, bu nedenle verileri bir hizmette tek bir yerde depolarsanız, aynı hizmeti talep ederek bu verileri başka bir yerden alabilirsiniz.

Bağımlı enjeksiyon (DI) vs Instatiation - aka de-spaghettifikasyon

AngularJS sizin için bağımlılıklarınızı yönetir. Bir nesneyi isterseniz, sadece ona başvurun ve AngularJS sizin için alır.

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

DI, uygulamanızı yazmak ve bir araya getirmek yerine, her biri bir dizeyle tanımlanan bileşen kitaplığını tanımlamanız anlamına gelir.

Flickr'dan JSON beslemelerini çekme yöntemlerini tanımlayan 'FlickrService' adlı bir bileşenim olduğunu varsayalım. Şimdi, Flickr'a erişebilen bir denetleyici yazmak istersem, denetleyiciyi bildirdiğimde sadece 'FlickrService' ismine başvurmam gerek. AngularJS, bileşenin başlatılması ve denetleyicime sunulması ile ilgilenir.

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

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

Şimdi bu hizmeti kullanmak istediğimde, sadece şu şekilde adlandırıyorum:

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

AngularJS, denetleyiciyi başlatmak için bir FlickrService nesnesinin gerekli olduğunu ve bizim için bir tane sağlayacağını kabul edecektir.

Bu, kablolama işlerini bir araya getirmeyi çok kolaylaştırır ve hemen hemen her yönüyle spagetlemeye olan eğilimi ortadan kaldırır. Düz bir bileşenler listesi var, ve AngularJS onlara ihtiyaç duyduğumuzda teker teker veriyor.

Modüler servis mimarisi

jQuery, kodunuzu nasıl düzenleyeceğiniz konusunda çok az şey söylüyor. AngularJS'nin görüşleri vardır.

AngularJS, kodunuzu yerleştirebileceğiniz modüller sunar. Örneğin, Flickr ile görüşen bir senaryo 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 (DI) içerebilir. Ana uygulamanız genellikle bir modüldür ve bu, uygulamanızın bağlı olacağı tüm diğer modülleri içermelidir.

Flickr'a dayalı başka bir uygulama yazmak istiyorsanız, basit bir kod yeniden kullanırsınız, sadece Flickr modülünü ve voila'yı ekleyebilir, yeni uygulamanızda tüm Flickr ile ilgili işlevlere erişebilirsiniz.

Modüller AngularJS bileşenleri içerir. Bir modül eklediğimizde, bu modüldeki tüm bileşenler benzersiz dizeleriyle tanımlanan basit bir liste olarak bize ulaşır.. Daha sonra bu bileşenleri AngularJS'nin bağımlılık enjeksiyon mekanizmasını kullanarak enjekte edebiliriz.

Sonuç olarak

AngularJS ve jQuery düşman değildir. AngularJS içinde jQuery'yi çok güzel kullanmak mümkündür. AngularJS yi (şablonlar, veri bağlama, $ kapsam, yönergeler vb.) Kullanıyorsanız, bir çok Aksi takdirde gerekenden daha az jQuery.

Anlaşılması gereken en önemli şey, şablonunuzun uygulamanızı yönlendirmesidir. Her şeyi yapan büyük eklentileri yazmaya çalışmayı bırak. Bunun yerine, bir şeyi yapan küçük yönergeler yazın, sonra bunları birbirine bağlamak için basit bir şablon yazın.

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

Benim küçük kitabım

AngularJS hakkında çok heyecanlandım, internette okumayı çok sevdiğiniz kısa bir kitap yazdım. http://nicholasjohnson.com/angular-book/. Umarım yardımcı olur.


184
2018-05-12 10:22



"Endişelerin Ayrılması" nın "MVC (Model, Görünüm, Kontrolör)" den farklı olduğu fikri tamamen sahte. Ayırt edici endişelerin web dilleri modeli (HTML, CSS ve JS), insanların bir web sayfasına (biçimlendirme / HTML) nasıl göründüğüne bakmadan (stil / düzen / CSS) veya ne yaptığını anlamamasına izin vererek yapar. (DOM etkinlikleri / AJAX / JavaScript). MVC de endişeleri ayırır. MVC modelindeki her "katman" ın farklı bir rolü vardır: veri, yönlendirme / mantık veya oluşturma. Katmanlar geri aramalar, yollar ve model bağlamaları ile birleştirilir. Teoride, bir kişi her bir durumda uzmanlaşabilir, ki bu çoğu zaman geçerlidir. - Alexander Pritchard
Sıkı bir SOC geçmişinden gelen ve tarayıcı savaşlarına dayanan web standartları için uzun zamandır savunan bir savunucu olarak, başlangıçta Angular'ın semantik olmayan, geçerliliği olmayan şablonları zahmetli buldum. Ben sadece Angular yazmak için SOC genel olarak uygulandığı gibi bırakmak için gerekli olduğunu açık yapmak istedim. Bu zor bir geçiş olabilir. - superluminary
Haklısın. SOC geniş bir terimdir, ancak web dünyasında SOC çok spesifik bir anlama sahiptir: ya da anlamsal HTML, davranışsal CSS ve JavaScript. Kitlem hakkında belki de makul olmayan bazı varsayımlar yapıyorum, bu yüzden de özür dilemeliyim. - superluminary
Cevabınızı en açık ve aydınlatıcı buluyorum. Burada oldukça yeni bir insansım, eğer mevcut bir sayfayı değiştirmek için bir uzantım varsa (ki ben kontrol etmiyorum), JQuery'yi o zaman tutmalı mıyım? - Daniel Möller


Gerekli olan paradigma kaymasını tarif edebilir misiniz?

Engelleyici ve Deklarasyon

İle jQuery DOM'a ne yapılması gerektiğini adım adım anlatıyorsunuz. İle angularjs Hangi sonuçları istediğinizi açıklar ama nasıl yapacağınızı değil. Daha fazlası İşte. Ayrıca, Mark Rajcok'un cevabını kontrol edin.

İstemci tarafı web uygulamalarını nasıl farklı şekilde tasarlarım ve tasarlarım?

AngularJS, kullanan tüm istemci tarafı bir çerçevedir. MVC desen (onların kontrol edin grafiksel gösterim). Bu kaygıların ayrılmasına büyük ölçüde odaklanır.

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

jQuerykütüphane

angularjs MVC gibi havalı tonlarca ürünü bir araya getiren güzel bir istemci tarafı çerçevesidir. bağımlılık enjeksiyonu, veri bağlama ve çok daha fazlası.

Üzerinde duruluyor endişelerin ayrılığı ve test etmebirim testi ve test odaklı gelişmeyi kolaylaştıran uçtan uca test).

Başlamak için en iyi yol geçiyor onların harika öğretici. Birkaç saat içinde adımlardan geçebilirsiniz; Ancak, sahnelerin arkasındaki kavramlara hakim olmak istiyorsanız, daha fazla okuma için sayısız referans içerir.

Herhangi bir sunucu tarafı ile ilgili değerlendirme / kısıtlama var mı?

Saf jQuery'yi zaten kullandığınız varolan uygulamalarda kullanabilirsiniz. Ancak, AngularJS özelliklerinden tam olarak yararlanmak istiyorsanız, sunucu tarafını kullanarak kodlamayı düşünebilirsiniz. RESTful yaklaşım.

Bunu yapmak, onların kaynak fabrikasısunucu tarafınızın bir özetini oluşturan RESTful API ve sunucu taraflı çağrıları (almak, kaydetmek, silmek, vb) inanılmaz derecede kolay hale getirir.


152
2018-02-21 04:29



Ben jQuery bir "kütüphane" ve Açısal bir "çerçeve" olduğunu söyleyerek suları muddying düşünüyorum ... bir şey için, jQuery tartışmak mümkün olduğunu düşünüyorum olduğu Bir çerçeve ... DOM manipülasyon ve olay işleme bir soyutlama var. Angular'ın aynı türden bir çerçevesi için bir çerçeve olmayabilir, ama bu soru-cevaplayıcının içinde bulunduğu ikilemdir: Angular ve jQuery arasındaki farkı gerçekten bilmezler ve tüm soruları için jQuery bilir. olduğu İstemci-ağır web siteleri oluşturmak için bir çerçeve. Yani terminoloji hakkında tartışmak bir şeyleri açıklığa kavuşturmaz. - Zando
Kafan karışan kişi sizsiniz. Bu soru tam olarak bunu ele alıyor stackoverflow.com/questions/7062775. Ayrıca, bu cevap bir çerçeve ve kütüphane arasındaki farkın netleşmesine yardımcı olabilir: stackoverflow.com/a/148759/620448 - Ulises
Bir kütüphane, işlevlerin toplanması özellikle yararlı veya büyük olduğu için bir "çerçeve" haline gelmez. Bir çerçeve sizin için kararlar verir. AngularJS'yi kullanmaya başladığınızda, doğası gereği ona bağlı olacaksınız. (Örn: Sadece DOM'u direktiflerde güncellemeniz gerekir, aksi takdirde bir şey berbat olur.) Çünkü AngularJS bir çerçevedir. JQuery'yi kullandığınızda, araçları minimum karmaşa riskiyle nispeten kolayca karıştırabilir ve eşleştirebilirsiniz. Çünkü jQuery bir kütüphanedir ve en azından yarı-iyi olanıdır. - Alexander Pritchard
bir kütüphane aradığınız koddur. bir iskelet kodunuzu çağıran koddur. Bu tanım ile Angular bir çerçevedir. Bileşenlerle beslersiniz ve Açısal, bileşenlerin ihtiyaç duydukları bağımlılıklar ile eşleştirildiğini görür. - superluminary


“Paradigma değişimini” tanımlamak için, kısa bir cevabın yeterli olabileceğini düşünüyorum.

AngularJS sizin tarzınızı değiştirir bulmak elementler

İçinde jQuery, genellikle kullanıyorsun seçiciler öğelerini bulmak ve daha sonra bunları bağlamak için:
$('#id .class').click(doStuff);

İçinde angularjs, kullan direktifler Öğeleri doğrudan işaretlemek için, onları kablolamak için:
<a ng-click="doStuff()">

AngularJS, seçiciyi kullanan öğeleri bulmaya (veya istemeye) gerek yok - AngularJS'ler arasındaki birincil fark jqLite tam darbeye karşı jQuery bu mu jqLite seçicileri desteklemiyor.

Yani insanlar "jQuery'yi hiç dahil etmeyin" dediğinde, esas olarak seçmenleri kullanmanı istemedikleri için; Bunun yerine direktifleri kullanmayı öğrenmenizi istiyorlar. Doğrudan, seçilmez!


84
2018-02-21 07:57



Sadece bir feragatname gibi, Açısal ve jQuery arasında daha büyük farklılıklar vardır. Fakat eleman bulma en büyük düşünce değişimini gerektiren şey. - Scott Rippey
Yanlış mıyım diye beni affet, ama bir elementin DOM öğesini bulmak için kullandığınız şey olduğunu mu düşündüm? Yeni yüklenen UI'nizin her bir parçasını referans olarak kullanmak yerine, bir kullanıcının seçtiği bir veya iki unsuru seçerek değil, bir seçici kullanarak mı kullanmayı tercih edersiniz? bana daha sert geliyor - RozzA
@AlexanderPritchard Açısal noktası, JavaScript'iniz arasından seçim yapmaz, şablonunuzdan yönlendirirsiniz. Gücü, tasarımcının eline geçiren bir kontrolün tersine çevrilmesi. Bu kasıtlı bir tasarım ilkesidir. Gerçekten almak Köşenizi bu şekilde yuvarlak olarak düşünmeniz gerekiyor. Bunu yapmak zor bir vardiya. - superluminary
@superluminary Ne harika bir teklif! "Seçme, doğrudan!" Cidden, onu kullanacağım. - Scott Rippey
Bu AngularJS hakkında en sevdiğim şeylerden biridir. UX ekibinin işlevselliğimi bozması veya stillerini kırmam konusunda endişelenmem gerekmiyor. Sınıfları kullanırlar, direktifler kullanırım, dönem. Seçmenleri bir kenara kaçırmıyorum. - adam0101


jQuery

jQuery gibi gülünç uzun JavaScript komutları yapar getElementByHerpDerp daha kısa ve çapraz tarayıcı.

angularjs

AngularJS, dinamik web uygulamaları ile iyi çalışan şeyleri (HTML statik sayfalar için tasarlanmış olduğundan) yapan kendi HTML etiketlerinizi / niteliklerinizi oluşturmanızı sağlar.

Düzenle:

"JQuery arka planım var AngularJS'de nasıl düşünebilirim?" "HTML arka planım var, JavaScript’te nasıl düşünebilirim?" Soruyu sormanız gerçeği büyük olasılıkla bu iki kaynağın temel amaçlarını anlamıyor. Bu yüzden bu soruya cevap vermek istedim: “AngularJS yönergeleri kullanır, jQuery ise CSS seçicilerini kullanarak jQuery nesnesini kullanır ve bu da böyle yapar. . Bu soru uzun bir cevap gerektirmez.

jQuery, tarayıcıda JavaScript’i programlama işlemini kolaylaştırmanın bir yoludur. Daha kısa, çapraz tarayıcı komutları vb.

AngularJS HTML'yi genişletir, böylece koymanız gerekmez <div> her yerde sadece bir uygulama yapmak için. HTML'nin aslında tasarlandığı şeyden ziyade, statik, eğitim web sayfaları olan uygulamalar için çalışmasını sağlar. JavaScript kullanarak dolambaçlı bir şekilde bunu başarır, ancak temel olarak JavaScript değil, HTML'nin bir uzantısıdır.


69
2018-02-04 05:07



@Robert ne yaptığınıza bağlı. $(".myclass") Son derece yaygındır ve jQuery'de PO-Javascript'ten biraz daha kolaydır. - Robert Grant


jQuery: 'QUERYing hakkında çok fazla şey düşünüyorsunuz DOM'DOM elemanları için ve bir şeyler yapıyor.

AngularJS: Model gerçektir ve hep bu ANGLE'den düşünürsünüz.

Örneğin DOM'ta bir biçimde görüntülemeyi düşündüğünüz sunucudan veri aldığınızda, jQuery'de '1'e ihtiyacınız vardır. DOM'ta, bu verileri yerleştirmek istediğiniz yeri seçin, '2. Yeni bir düğüm oluşturarak veya sadece kendi innerHTML. Ardından bu görünümü güncellemek istediğinizde '3. 'Konumu ve' 4'ü bul. GÜNCELLEŞTİRME'. Sunucudan veri alma ve biçimlendirme aynı bağlamda yapılan bu bulma ve güncelleme döngüsü, AngularJS'de gider.

AngularJS ile modelinize sahipsiniz (zaten kullandığınız JavaScript nesneleri) ve modelin değeri size model hakkında (açıkça) ve görünüm hakkında bilgi verir ve modeldeki bir işlem otomatik olarak görüntüye yayılır. Bunu düşünmek zorundayım. Artık kendinizi DOM'ta bir şey bulamayan AngularJS'de bulacaksınız.

Başka bir şekilde söylemek gerekirse, jQuery'de, CSS seçicilerini düşünmeniz gerekir. div veya td HTML veya renk veya değerlerini alabilmem için bir sınıf veya öznitelik, vb. var, ama AngularJS'de kendinizi şöyle düşünebilirsiniz: Ben hangi modelle uğraşıyorum, modelin değerini doğruya ayarlayacağım. Bu değeri yansıtan görünümün işaretli bir kutu olup olmadığını veya bir td element (jQuery'de düşünmek için sıklıkla ihtiyaç duyduğunuz ayrıntılar).

Ve AngularJS'deki DOM manipülasyonu ile kendinizin geçerli HTML uzantıları olarak düşünebileceğiniz yönergeler ve filtreler ekleyerek kendinizi bulabilirsiniz.

AngularJS'de yaşayacağınız bir şey daha: jQuery'de jQuery işlevlerini çok anlıyorsunuz, AngularJS'de, AngularJS sizin fonksiyonlarınızı arayacaktır, bu yüzden AngularJS size 'nasıl şeyler yapacağınızı' söyleyecektir, fakat faydalar buna değecektir, böylece AngularJS'yi öğreneceksiniz. genellikle AngularJS'nin ne istediğini veya AngularJS'nin işlevlerinizi sunmanızı gerektirdiğini öğrenmek anlamına gelir ve buna göre buna göre çağrı yapılır. Bu, AngularJS'i bir kitaplıktan ziyade bir çerçeve yapan şeylerden biridir.


61
2017-11-02 16:53