15 Soru: Eğer bir jQuery geçmişim varsa “AngularJS'de Düşünmek”? [kapalı]

tarafından oluşturulan soru Fri, Nov 2, 2018 12:00 AM

jQuery 'de müşteri tarafı uygulamalar geliştirmeye aşina olduğumu varsayalım, ancak şimdi kullanmaya başlamak istiyorum AngularJS . Gerekli olan paradigma değişimini tarif edebilir misiniz? İşte bir yanıtı çerçevelemenize yardımcı olabilecek birkaç soru:

  • İstemci tarafı web uygulamalarını farklı şekilde nasıl 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ı düşüncesi /kısıtlaması var mı?

jQuery ve AngularJS arasında ayrıntılı bir karşılaştırma aramıyorum.

    
4520
  1. "ASP.NET MVC" veya "RoR" hakkında bilgi sahibi olanlar için - "Müşteri tarafı MVC" olarak yalnızca Açısal'ı ve bu kadarını düşünün.
    2015-05-27 21: 29: 18Z
15 Yanıtlar                              15                         

1. Sayfanızı tasarlamayın ve ardından DOM manipülasyonları

ile değiştirin

jQuery'de bir sayfa tasarlar ve sonra onu dinamik yaparsınız. Bunun nedeni, jQuery’nin büyütme işlemi için tasarlandığı ve bu basit öncülden inanılmaz bir şekilde büyüdüğüdür.

Fakat AngularJS'de, mimarlığınızı düşünerek sıfırdan başlamalısınız. "DOM'nin bu parçasına sahibim ve bunu X yapmak istiyorum" düşünerek başlamak yerine, başarmak istediklerinizle başlamalısınız, ardından uygulamanızı tasarlamaya ve sonra da nihayet görüşünüzü tasarlamaya devam etmelisiniz.

2. JQuery'yi AngularJS ile büyütme

Benzer şekilde, jQuery'nin X, Y ve Z yaptığı düşüncesiyle başlama, bu yüzden sadece modeller ve denetleyiciler için bunun üzerine AngularJS ekleyeceğim. Yeni başladığınızda bu gerçekten caziptir, bu yüzden her zaman yeni AngularJS geliştiricilerinin jQuery kullanmamasını tavsiye ederim, en azından "Açısal Yol yapmaya alışıncaya kadar" ".

Burada ve e-posta listesinde birçok geliştirici gördüm, bu karmaşık çözümleri 150 veya 200 satırlık kod satırı jQuery eklentileriyle oluşturdular ve daha sonra geri zekalı ve kıvrımlı olan $apply s ile AngularJS'e yapıştırdılar; ama sonunda işe yarıyorlar! Sorun, çoğu durumda, jQuery eklentisinin AngularJS'de kodun bir kısmıyla yeniden yazılabileceği, aniden her şeyin anlaşılır ve anlaşılır hale geldiğidir.

Alt satır şudur: Çözümlerken, önce "AngularJS'de düşün"; Bir çözüm düşünemiyorsanız, topluluğa sorun; Tüm bunlardan sonra kolay bir çözüm yoksa, o zaman jQuery'e ulaşmaktan çekinmeyin. Ancak jQuery'nin bir koltuk değneği olmasına izin vermeyin, yoksa asla AngularJS'de ustalaşmazsınız.

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

İlk önce tek sayfalı uygulamalar olduğunu uygulamalar öğrenin . Web sayfaları değil . Bu nedenle, bir istemci tarafı geliştiricisi gibi düşünmek için ek olarak bir sunucu tarafı geliştiricisi gibi düşünmemiz gerekir. Uygulamamızı bireysel, genişletilebilir, test edilebilir bileşenlere nasıl ayıracağımızı düşünmeliyiz.

Öyleyse bunu nasıl yapıyorsunuz? "AngularJS'de nasıl düşünürsün?" İşte jQuery ile zıt bazı genel prensipler.

Manzara, "resmi kayıt" dır

jQuery'de görünümü programlı olarak değiştiririz. Bunun gibi ul olarak tanımlanan bir açılır menümüz olabilir:

 
<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, onu şöyle bir şeyle etkinleştiririz:

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

Görünüme yalnızca baktığımızda, burada herhangi bir işlev olduğu hemen belli değil. Küçük uygulamalar için sorun değil. Ancak önemsiz olmayan uygulamalar için işler çabucak kafa karıştırıcı ve bakımı zorlaşıyor.

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

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

Bu ikisi aynı şeyi yapar, ancak AngularJS sürümünde şablona bakan herhangi birisinin ne olması gerektiğini bilir. Geliştirme ekibine yeni bir üye geldiğinde, şuna bakabilir ve daha sonra bildiği direktif cal olduğunuled üzerinde çalışan dropdownMenu; doğru cevabı vermesi ya da herhangi bir kod yazması gerekmiyor. Görüş bize ne olması gerektiğini anlattı. Çok daha temiz.

AngularJS’e yeni gelen geliştiriciler genellikle şu soruları sorar: Belirli bir türdeki tüm bağlantıları nasıl bulurum ve bunlara bir yönerge eklerim. Geliştirici biz cevaplarken her zaman flabbergasted olduğunu: sen yapmazsın. Ama bunu yapmamanın nedeni, bunun yarı jQuery, yarı-AngularJS gibi olması ve hiç iyi olmamasıdır. Buradaki sorun, geliştiricinin AngularJS bağlamında "jQuery" yapmaya çalıştığıdır. Bu asla işe yaramayacak. Görüntü resmi kayıttır. Bir direktifin dışında (aşağıda daha fazlası olacak), DOM'yi asla, asla, asla değiştiremezsiniz. Ve direktifler görünümünde uygulanır, bu nedenle niyet açıktır.

Unutma: tasarlamayın ve işaretleyin. Mimar olmalı ve sonra tasarlamalısınız.

Veri bağlama

Bu, AngularJS'in en harika özelliklerinden biridir ve önceki bölümde bahsettiğim DOM manipülasyon türlerini yapma ihtiyacını büyük ölçüde azaltır. AngularJS görünümünüzü otomatik olarak günceller, böylece zorunda kalmazsınız! JQuery'de olaylara cevap veriyoruz ve ardından içeriği güncelliyoruz. Gibi bir şey:

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

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

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

Endişelerin karıştırılmasının yanı sıra, daha önce bahsettiğim niyet belirtmekle de aynı sorunları yaşıyoruz. Fakat daha da önemlisi, bir DOM düğümüne manuel olarak referans vermek ve güncellemek zorunda kaldık. Bir günlük girişini silmek istiyorsak, bunun için DOM'a da kod yazmamız gerekir. Mantığı DOM'dan ayrı nasıl test ederiz? Peki ya sunumu değiştirmek istiyorsak?

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

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

Görüşümüz şu şekilde görünebilir:

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

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

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

Ve şimdi sıralanmamış bir liste kullanmak yerine, Bootstrap uyarı kutularını kullanıyoruz. Ve asla denetleyici kodunu değiştirmek zorunda kalmadık! Ancak, daha önemlisi, günlük nerede veya nasıl olursa olsun, görünüm de değişecektir. Otomatik olarak. Temiz!

Burada göstermedim, veri bağlama iki yönlü. Böylece, bu günlük mesajları görünümünde sadece şu şekilde düzenlenebilir: <input ng-model="entry.msg" />. Ve çok sevindirici oldu.

Farklı model katmanı

jQuery'de DOM, modeldeki gibidir. Ancak AngularJS'de istediğimiz şekilde yönetebildiğimiz ayrı bir model katmanına sahibiz, tamamen bakış açısından. Bu, yukarıdaki veri bağlama için yardımcı olur, endişelerin ayrılmasını sağlar ve çok daha fazla test edilebilirlik sağlar. Bu noktadan bahseden diğer cevaplar, bu yüzden onu sadece bırakacağım.

Endişelerin ayrılması

Yukarıdakilerin hepsi bu aşırı temalı temaya bağlanır: endişelerinizi ayrı tutun. Görüşünüz, olması gerekenlerin resmi kaydı olarak hareket eder (ç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 yaparsınız ve görüşlerinizi direktiflerle güçlendirirsiniz; ve hepsini kontrol cihazlarıyla birleştiriyorsun. Bu, diğer cevaplarda da belirtilmiştir ve ekleyeceğim tek şey, aşağıda başka bir bölümde tartıştığım test edilebilirlikle ilgilidir.

Bağımlılık enjeksiyonu

Kaygıların ayrılmasında bize yardımcı olmak için bağımlılık enjeksiyonu (DI). Bir sunucu tarafı dilinden geliyorsanız ( Java 'dan PHP ) zaten bu konsepte aşinasınızdır, ancak jQuery'den gelen müşteri tarafı bir adamsanız , bu kavram aptaldan gereksize ve yenileşmeye kadar her şey gibi görünebilir. Ama değil. : -)

Geniş bir perspektiften DI, bileşenleri çok serbest ve daha sonra diğer bileşenlerden açıklayabileceğiniz anlamına gelir, bunun bir örneğini isteyin ve verilecektir. Yükleme sırasını, dosya konumlarını veya buna benzer şeyleri bilmek zorunda değilsin. Güç hemen görünmeyebilir, ancak yalnızca bir (genel) örnek vereceğim: test etme.

Diyelim ki uygulamamızda, sunucu tarafında depolamayı bir REST aracılığıyla uygulayan bir hizmete ihtiyacımız var. > API ve uygulama durumuna bağlı olarak yerel depolama da. Denetleyicilerimizde testler yaparken, sunucu ile iletişim kurmak istemiyoruz - sonuçta denetleyiciyi test ediyoruz. Orijinal bileşenimizle aynı adda bir sahte hizmet ekleyebiliriz ve enjektör, denetleyicimizin sahte olanı otomatik olarak almasını sağlar - denetleyicimiz farkı görmez ve bilmez.

Testten bahsetmişken ...

4. Test odaklı geliştirme - her zaman

Bu gerçekten mimarlığın 3. bölümünün bir parçası, ancak onu kendi üst düzey bölümü olarak koymak çok önemli.

Gördüğünüz, kullandığınız veya yazdığınız birçok jQuery eklentisinin dışında, bunlardan kaç tanesinde eşlik eden bir test paketi vardı? Çok fazla değil, çünkü jQuery buna pek uygun değil. Ancak AngularJS'dir.

JQuery'de test etmenin tek yolu, genellikle testlerimizin DOM manipülasyonu gerçekleştirebileceği bir örnek /demo sayfasıyla bileşeni bağımsız olarak oluşturmaktır. O zaman ayrı bir bileşen geliştirmeliyiz ve sonra uygulamamıza dahil edelim. Ne kadar rahatsız edici! Çoğu zaman, jQuery ile geliştirirken, test odaklı geliştirme yerine yinelemeyi tercih ediyoruz. Ve bizi kim suçlayabilir?

Ancak endişelerden ayrıldığımız için, AngularJS'de yinelemeli bir şekilde test odaklı geliştirme yapabiliriz! Mesela, mönüsümüzde mevcut rotanızın ne olduğunu belirten çok basit bir yönerge istediğimizi varsayalım. Başvurumuz ışığında ne istediğimizi ilan edebiliriz:

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

Testimizi yaptığımızda, başarısız olduğunu onaylayabiliriz. Direktifi ancak şimdi 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çti ve menümüz talep edildiği gibi gerçekleşti. Geliştirmemiz hem yinelemeli hem de test odaklı. Wicked-serin.

5. Kavramsal olarak, direktifler değil paketlenmiş jQuery

şeklindedir.

Sık sık "yalnızca bir yönergede DOM manipülasyonu yapar" ifadesini duyarsınız. Bu bir zorunluluktur. Buna çok değer verin!

Ama biraz daha derine dalalım ...

Bazı direktifler görünümde zaten olanı dekore eder (düşün ngClass) ve bu nedenle bazen DOM manipülasyonunu hemen yapar ve temel olarak yapılır. Ancak bir direktif bir "widget" gibiyse ve bir şablona sahipse, endişelerin ayrılığına da saygı göstermelidir. Diğer bir deyişle, de şablonu, bağlantı ve denetleyici işlevlerinde uygulanmasından büyük ölçüde bağımsız kalmalıdır.

AngularJS bunu kolaylaştırmak için bir dizi araçla birlikte gelir; ngClass ile sınıfı dinamik olarak güncelleyebiliriz; ngModel, iki yönlü veri bağlamaya izin verir; ngShow ve ngHide programlı olarak bir elemanı gösterir veya gizler; ve daha pek çoğu - kendimizi yazdıklarımız dahil. Başka bir deyişle, DOM manipülasyonu olmadan her türlü tuhaflığı yapabiliriz. DOM manipülasyonu ne kadar az olursa, yönergeler o kadar kolay test edilir, stillendirmeleri kolaylaşır, gelecekte daha kolay değiştirilirler ve yeniden kullanılabilir ve dağıtılabilir olurlar.

AngularJS için birçok geliştiriciyi bir sürü jQuery atmak için yönergeler olarak kullanarak görüyorum. Başka bir deyişle, "denetleyicide DOM manipülasyonu yapamadığım için o kodu bir yönergeye koyacağım" diye düşünüyorlar. Bu kesinlikle çok daha iyi olsa da, genellikle hala yanlış .

3. bölümde programladığımız kaydediciyi düşünün. Bunu bir yönergeye koysak bile, hala bunu "Açısal Yol" yapmak istiyoruz. Hala DOM manipülasyonu yapmıyor! DOM manipülasyonunun gerekli olduğu birçok zaman vardır, ancak düşündüğünüzden çok daha nadir! Uygulamanızda her yerde DOM manipülasyonu yapmadan önce gerçekten 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. Değiştirilebilir bir düğme istiyoruz. (Not: bu örnek biraz tartışmalı ve aynı şekilde çözülmüş daha karmaşık vakaları temsil eden bir skosh).)

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

Bunda yanlış olan birkaç şey var:

  1. İlk önce, jQuery hiçbir zaman gerekli olmadı. Burada yaptığımız hiçbir şey yok, jQuery'e ihtiyaç var!
  2. İkincisi, sayfamızda zaten jQuery olsa bile, onu burada kullanmak için hiçbir neden yoktur; angular.element'u kullanabiliriz ve bileşenimiz jQuery olmayan bir projeye girdiğinde çalışmaya devam edecek.
  3. Üçüncüsü, çalışma yönergesi için jQuery 'in gerekli olduğunu varsayarsak, jqLite (angular.element) yüklüyse jQuery'yi her zaman kullanır! Bu yüzden $'u kullanmamız gerekmiyor - sadece angular.element'u kullanabiliriz.
  4. Dördüncüsü, üçüncü ile yakından ilişkili, jqLite öğelerinin $'a sarılması gerekmediğidir - element işlevine geçirilen link, zaten bir jQuery öğesi olacaktır!
  5. Ve önceki bölümlerde bahsettiğimiz beşincisi, neden şablon olaylarını mantığımıza karıştırıyoruz?

Bu yönerge çok daha basit bir şekilde yeniden yazılabilir (çok karmaşık durumlar için 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 şablon şablonu şablondadır, bu nedenle siz (veya kullanıcılarınız) gerekli herhangi bir stile uyan bir kişi için kolayca değiştirebilirsiniz ve mantığa hiç dokunulmaması gerekiyordu. Yeniden kullanılabilirlik - bom!

Test yapmak gibi diğer tüm avantajlar hala varsy! Şablonda ne olursa olsun, direktifin iç API'sine hiçbir zaman dokunulmaz, bu nedenle yeniden düzenleme kolaydır. Yönetmeliğe dokunmadan şablonu istediğiniz kadar değiştirebilirsiniz. Ve neyi değiştirdiğiniz önemli değil, testleriniz yine de başarılı.

w00t!

Öyleyse eğer direktifler sadece jQuery benzeri fonksiyonların koleksiyonları değilse, bunlar nedir? Direktifler aslında HTML’nin uzantısıdır . HTML yapmanız gereken bir şeyi yapmazsa, sizin için yapması için bir yönerge yazarsınız ve sonra da HTML'nin bir parçasıymış gibi kullanırsınız.

Başka bir deyişle, AngularJS kutudan bir şey yapmazsa, ekibin ngClick, ngClass ve diğerleri ile tam olarak uymasını sağladığını düşünün.

Özet

JQuery bile kullanmayın. Onu bile ekleme. Seni geri tutacak. Ve jQuery'de nasıl çözeceğinizi bildiğinizi düşündüğünüz bir problemle karşılaştığınızda, $'a ulaşmadan önce, bunu AngularJS'nin sınırları içinde nasıl yapacağınızı düşünmeye çalışın. Bilmiyorsan sor! 20'den 19 kez, bunu yapmanın en iyi yolu jQuery'e ihtiyaç duymaz ve jQuery ile çözmeyi denemek sizin için daha fazla çalışmayla sonuçlanır.

    
7183
2015-04-17 20: 38: 02Z
  1. JQuery ile çalışmayı açısal bir uygulamada birleştirmenin, tüm mevcut JQuery eklentileri nedeniyle önemli bir kullanım olduğunu düşünüyorum. FancyBox'ı jQuery'de saf bir Angular uygulamasını tutmak için yeniden yazmıyorum.
    2013-02-26 21: 53: 14Z
  2. @ taudep Sandığınız kadar aynı fikirde olduğumuzu sanmıyorum. Çoğu jQuery eklentisi AngularJS'de ucuza yazılabilir ve bu durumlarda bunu yapmalıyız. Eşdeğeri olmayan karmaşık bir şey için, onun için gidin. Bölüm 2'den alıntı yapmak: 'Sonuç olarak bu: çözerken ilk önce "AngularJS'de düşün"; Bir çözüm düşünemiyorsanız, topluluğa sorun; Tüm bunlardan sonra kolay bir çözüm yoksa, jQuery için ulaşmaktan çekinmeyin . Ancak jQuery'nin bir koltuk değneği olmasına izin vermeyin, yoksa asla AngularJS'de ustalaşamazsınız. ' [vurgu eklendi]
    2013-02-26 22: 39: 08Z
  3. bir Çince bu harika cevaba çevirdi, yardımcı olabilir. hanzheng.github.io/tech/angularjs/2013/10/28/…
    2013-10-28 14: 00: 00Z
  4. @ Benno "DOM işlem yok" derken, yönergedeki kodunuzun doğrudan DOM işlemlerini gerçekleştirmediği anlamına gelir. Bu kod DOM hakkında hiçbir şey bilmiyor, sadece modelinizdeki js değişkenlerini değiştiriyor. Evet, sonuç şu ki DOM değiştirilmiş, ancak bunun nedeni yazdığımız kodun dışında değişkenlerimize değişen değişkenler olduğu için bağlar var, ancak direktifin içinde bunun hakkında hiçbir şey bilmiyoruz, DOM manipülasyonu ile temiz bir ayrılık yapıyoruz. iş mantığı. JQuery örneğinizde, "Bu metni bu öğeye ekle"
    diyerek doğrudan DOM'yi değiştiriyorsunuz.
    2014-03-02 06: 06: 38Z
  5. @ trusktr Eğer bir geliştirme, bir AngularJS uygulamasında jQuery kullanarak bir girdi öğesinin değerini belirlerse, ağır bir hata yapar. Düşünebileceğim tek istisna türü, bir girişi otomatik olarak değiştiren bağlantı noktasını zorlaştıran bir jQuery eklentisidir; bu durumda bir geri aramaya çağıran veya bir saat ayarının, değişiklikleri uygulama ile aynı çizgiye getirmek için kesinlikle zorunludur.
    2014-04-01 05: 04: 10Z

Zorunlu → bildirimsel

jQuery'de seçicileri , DOM öğelerini bulmak için kullanılır ve sonra olay işleyicilerini onlara bağlayın /kaydedin. Bir etkinlik tetiklendiğinde, bu (zorunlu) kod DOM'yi güncellemek /değiştirmek için yürütülür.

AngularJS’de, DOM öğeleri yerine görünümler hakkında düşünmek istersiniz. Görünümler, AngularJS direktifleri içeren (bildirimsel) HTML'dir. Direktifler etkinliği ayarladıBizim için perde arkasındaki işleyiciler ve bize dinamik veri tabanı oluşturuyorlar. Seçiciler nadiren kullanılır, bu yüzden kimliklere (ve bazı sınıf türlerine) duyulan ihtiyaç büyük ölçüde azalır. Görünümler modellere bağlıdır (kapsamlar aracılığıyla). Görünümler modelin bir yansımasıdır. Olaylar modelleri değiştirir (yani veriler, kapsam özellikleri) ve bu modelleri yansıtan görünümler "otomatik olarak" güncellenir.

AngularJS'de, verilerinizi tutan jQuery-select DOM öğeleri yerine modeller hakkında düşünün. Kullanıcıların gördüklerini değiştirmek için geri aramaları kaydetmek yerine, bu modellerin projeksiyonları olarak görmeyi düşünün.

Endişelerin ayrılması

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

AngularJS, davranışı görünüm /yapıdan (HTML) kaldırmak için denetleyicileri ve yönergeleri (her biri kendi denetleyicisine sahip olabilir ve /veya derleme ve bağlama işlevlerini) kullanır. Angular, uygulamanızı ayırmanıza /düzenlemenize yardımcı olmak için hizmetler ve filtreler de içerir.

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

Uygulama tasarımı

AngularJS uygulaması tasarlamada bir yaklaşım:

  1. Modellerinizi düşünün. Bu modeller için hizmetler veya kendi JavaScript nesnelerinizi oluşturun.
  2. Modellerinizi nasıl sunmak istediğinizi düşünün - görüşlerinizi. Dinamik veri bağlama 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önlendirmeyi veya ng denetleyicisini kullanarak). Denetleyiciye, görünümün işini yapması için gereken her veri modelini bulmasını /almasını sağlayın. Denetleyicileri mümkün olduğu kadar ince yapın.

Prototip devralma

JavaScript prototip kalıtımının nasıl çalıştığını bilmeden jQuery ile çok şey yapabilirsiniz. AngularJS uygulamalarını geliştirirken, JavaScript'i devralma konusunda iyi bir anlayışınız varsa, bazı yaygın tuzaklardan kaçınacaksınız. Tavsiye edilen okuma: Kapsamlı prototiplerin nüansları nelerdir? /AngularJS'de prototipik miras mı?

    
408
2017-05-23 11: 47: 31Z
  1. pls yapabilir misiniz? Bir dom öğesinin görünümden ne kadar farklı olduğunu açıklayabilir misiniz?
    2013-02-27 01: 06: 48Z
  2. @ rajkamal, bir DOM öğesi (açıkçası) tek bir öğedir ve jQuery'de genellikle /hedeflediğimiz /manipüle ettiğimiz şey budur. Açısal görünüm ilgili DOM öğelerinin bir koleksiyon /şablonudur: 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-view yoluyla değiştirilebilir). Temel olarak, sayfalarınızı farklı görünümlere bölmek istersiniz. Her görünümün kendi ilişkili denetleyicisi vardır. Her görünüm modelinizin bir bölümünü yansıtır.
    2013-02-27 03: 46: 00Z
  3. jQuery, NOT zorunludur. on ve when, bir jQuery koleksiyonu nesnesinin üyeleri üzerinde çalışan daha üst düzey işlevlerdir.
    2013-07-25 18: 28: 48Z
  4. Peki, on için geri aramada ne tür bir kod yürütülür? Zorunluluk.
    2013-08-05 17: 10: 06Z
  5. Bu zorunlu ve bildirmeli, gerçekten sadece bir soyutlama meselesidir. Sonunda, tüm bildirim kodu (ne yapmalı) zorunlu olarak (nasıl yapmalı) geliştirici tarafından alt rutin olarak alt soyutlama seviyesinde, çerçeve veya bir derleyici /yorumlayıcı tarafından uygulanır. Genel olarak "jQuery'nin zorunlu olduğunu" söylemek, özellikle "el ile" DOM-manipülasyonu ile ilgili olarak gerçekten çok daha fazla beyan edici bir API sağladığı göz önüne alındığında oldukça tuhaf bir ifadedir.
    2014-11-08 04: 05: 40Z

AngularJS vs. jQuery

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

Bu normaldir, itmelisin. Açısal buna değer.

Büyük fark (TLDR)

jQuery, DOM’in isteğe bağlı bitlerini seçmek ve bunlara geçici değişiklikler yapmak için bir araç takımı sunar. Tek tek sevdiğiniz her şeyi parça parça yapabilirsiniz.

AngularJS bunun yerine size bir derleyici verir.

Bunun anlamı, AngularJS'nin DOM'unuzun tamamını yukarıdan aşağıya okur ve tam anlamıyla derleyicinin talimatı olarak kod olarak kabul etmesidir. DOM'yi geçerken, AngularJS derleyicisine nasıl davranacağını ve ne yapacağını söyleyen belirli yönergeleri (derleyici yönergelerini) arar. Yönergeler, niteliklerle, etiketlerle, sınıflarla ve hatta yorumlarla eşleşebilecek küçük JavaScript nesneleridir.

Angular derleyicisi bir DOM parçasının belirli bir yönerge ile eşleştiğini belirlediğinde, yönerge işlevini çağırır, onu DOM öğesi, herhangi bir öznitelik, geçerli $kapsamı (yerel değişken deposu) ve diğer bazı yararlı bitler. Bu nitelikler, Yönerge tarafından yorumlanabilen, nasıl yapılacağını ve ne zaman yeniden çizilmesi gerektiğini söyleyen ifadeler içerebilir.

Direktifler daha sonra denetleyiciler, hizmetler vb. gibi ek Açısal bileşenleri çekebilir. Derleyicinin altından çıkan, kablolu ve kullanıma hazır, tam olarak oluşturulmuş bir web uygulamasıdır.

Bu, Açısal'ın Şablonla Sürüklendiği anlamına gelir . Şablonunuz JavaScript'i kullanıyor, tam tersi değil. Bu, rollerin köklü bir tersine çevrilmesi ve son 10 yıldır yazdığımız göze çarpmayan JavaScript'in tam tersi. Bu alışmak biraz zaman alabilir.

Bu, kulağa aşırı reçeteli ve sınırlayıcı gibi geliyorsa, hiçbir şey gerçeklerden daha uzak olamaz. AngularJS, HTML’nizi kod olarak kabul ettiğinden, web uygulamanızda HTML düzeyinde ayrıntı düzeyi elde edersiniz. Her şey mümkün ve birkaç kavramsal adım attığınızda çoğu şey şaşırtıcı derecede kolaydır.

Nitty cesaretine inelim.

İlk önce, Angular jQuery'nin yerini almaz

Açısal ve jQuery farklı şeyler yapar. AngularJS size web uygulamaları üretmek için bir dizi araç sunar. jQuery temel olarak size DOM'yi değiştirmek için araçlar sunar. Sayfanızda jQuery varsa, AngularJS bunu otomatik olarak kullanır. Değilse, AngularJS, kesilmiş, ancak hala mükemmel bir jQuery sürümü olan jQuery Lite ile birlikte gelir.

Misko, jQuery'yi sever ve onu kullanmanıza itiraz etmez. Bununla birlikte, ilerledikçe kapsamınızın, şablonların ve yönergelerin bir birleşimini kullanarak yaptığınız işin neredeyse tamamını elde edebileceğinizi göreceksiniz ve mümkün olduğunda bu iş akışını tercih etmelisiniz, çünkü kodunuz daha ayrıntılı, daha yapılandırılabilir ve daha fazlası olacaktır. Eğik.

jQuery kullanıyorsanız, her yere serpmemelisiniz. AngularJS'de DOM manipülasyonu için doğru yer bir yönergededir. Bunlarla ilgili daha sonra.

Seçicilere Karşı Bilgilendirici Şablonlar ve Beyanname Şablonları

jQuery genellikle göze çarpmayan şekilde uygulanır. JavaScript kodunuz üstbilgiye (veya altbilgiye) bağlıdır ve bu belirtildiği tek yer burasıdır. Sayfanın parçalarını seçmek için seçiciler kullanıyoruz ve bu parçaları değiştirmek için eklentiler yazıyoruz.

JavaScript kontrol altında. HTML'nin tamamen bağımsız bir varlığı vardır. HTML'niz, JavaScript olmadan bile anlamsal kalır. Onclick özellikleri çok kötü bir uygulamadır.

AngularJS ile ilgili farkedeceğiniz ilk şeylerden biri, özel niteliklerin her yerde olduğu . HTML’niz, esasen steroidler üzerindeClick öznitelikleri olan ng öznitelikleriyle doludur. Bunlar direktiflerdir (derleyici direktifleri) ve şablonun modele bağlı olduğu ana yollardan biridir.

Bunu ilk gördüğünüzde, AngularJS'i eski okul müdahaleci JavaScript'i (başlangıçta yaptığım gibi) kapalı olarak yazmanız istenebilir. Aslında, AngularJS bu kurallara uymuyor. AngularJS'de HTML5'iniz bir şablondur. Web sayfanızı oluşturmak için AngularJS tarafından derlenmiştir.

Bu ilk büyük fark. JQuery için web sayfanız manipüle edilecek bir DOM. AngularJS'e göre, HTML kodunuz derlenecek koddur. AngularJS tüm web sayfanızı okur ve kelimenin tam anlamıyla yerleşik derleyicisini kullanarak yeni bir web sayfasına derler.

Şablonunuz bildirici olmalıdır; anlamı basitçe onu okuyarak net olmalıdır. Anlamlı adları olan özel özellikler kullanıyoruz. Yine anlamlı isimlerle yeni HTML elemanları oluşturduk. Minimum HTML bilgisine sahip ve kodlama yeteneği olmayan bir tasarımcı AngularJS şablonunuzu okuyabilir ve ne yaptığını anlayabilir. Değişiklik yapabilir. Bu Açısal yoldur.

Şablon sürüş koltuğundadır.

AngularJS ve r'yi başlatırken kendime sorduğum ilk sorulardan biri.eğitimler arasında dolaşmak "Kodum nerede?" şeklindedir. JavaScript yazmadım, ama yine de bu davranışa sahibim. Cevap açıktır. AngularJS DOM'yi derlediğinden, AngularJS HTML'nizi kod olarak değerlendirir. Birçok basit durum için, sadece bir şablon yazmak ve AngularJS'nin sizin için bir uygulamada derlemesine izin vermek çoğu zaman yeterlidir.

Şablonunuz uygulamanızı yönetir. Bir DSL olarak değerlendirilir. AngularJS bileşenlerini yazarsınız ve AngularJS şablonunuzu yapısına bağlı olarak bunları doğru şekilde çekip doğru zamanda hazır bulundurmaya özen gösterir. Bu, standart bir MVC 'den çok farklı şablonun yalnızca çıktı için olduğu desen.

XSLT 'a Örneğin Ruby on Rails .

Bu, alışması gereken radikal bir kontrol inversiyonu.

Başvurunuzu JavaScript’inizden sürmeye çalışmayı bırakın. Şablonun uygulamayı sürmesine izin verin ve AngularJS'nin bileşenlerin birbirine bağlanması ile ilgilenmesine izin verin. Bu aynı zamanda Açısal yoldur.

Semantik HTML vs. Semantik Modeller

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

Çünkü AngularJS, HTML sayfanızı bir şablon olarak kabul eder. Şablonun, içeriğinizin tipik olarak API’nizden gelen modelinde saklanması nedeniyle anlamsal olması gerekmiyor. AngularJS, DOM'unuzu semantik bir web sayfası oluşturmak için modelle derler.

HTML kaynağınız artık anlamsız değil, API ve derlenmiş DOM’niz anlamlıdır.

AngularJS’de, modeldeki anlamlar anlamındadır, HTML yalnızca görüntülenmesi için yalnızca bir şablondur.

Bu noktada, muhtemelen SEO ve erişilebilirlikle ilgili tüm sorulara sahip olabilirsiniz ve haklı olarak yani. Burada açık sorunlar var. Çoğu ekran okuyucu şimdi JavaScript'i ayrıştırır. Arama motorları ayrıca AJAXed içeriğini endeksleyebilir. Bununla birlikte, pushstate URL'leri kullandığınızdan ve iyi bir site haritanız olduğundan emin olmak isteyeceksiniz. Sorunun tartışılması için buraya bakın: https://stackoverflow.com/a/23245379/687677

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

Endişelerin ayrılması (SOC), yıllarca web üzerinden gelişen bir kalıptır SEO, erişilebilirlik ve tarayıcı uyumsuzluğu gibi çeşitli nedenlerle geliştirme. Şuna benziyor:

  1. HTML - Anlamsal anlam. HTML tek başına durmalı.
  2. CSS - Styling, CSS olmadan sayfa hala okunabilir.
  3. JavaScript - Davranış, içerik olmadan kalan komut dosyası olmadan.

Yine, AngularJS kurallarına göre oynamaz. Bir vuruşta, AngularJS, on yıllık bir bilgeliği ortadan kaldırır ve bunun yerine, şablonun artık bir anlam ifade etmeyen, hatta biraz değil, bir MVC deseni uygular.

Şuna benziyor:

  1. Model - Modelleriniz semantik verilerinizi içerir. Modeller genellikle JSON nesneleridir. Modeller $kapsam denilen bir nesnenin öznitelikleri olarak var. Ayrıca kullanışlı yardımcı program işlevlerini, şablonlarınızın erişebileceği $kapsamı üzerinde de saklayabilirsiniz.
  2. Görünüm - Görünümleriniz HTML ile yazılmıştır. Veriler modelde bulunduğundan görünüm genellikle anlamsal değildir.
  3. Denetleyici - Denetleyiciniz, görünümü modele bağlayan bir JavaScript işlevidir. İşlev $$. Uygulamanıza bağlı olarak, bir denetleyici oluşturmanız gerekebilir veya gerekmeyebilir. Bir sayfada birçok denetleyiciniz olabilir.

MVC ve SOC aynı ölçeğin zıt uçlarında değil, tamamen farklı eksenlerde. SOC, AngularJS bağlamında bir anlam ifade etmiyor. Onu unutup devam etmelisin.

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

Eklentiler ve Yönergeler

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

jQuery'de, eklentileri jQuery.prototype işlevlerini ekleyerek tanımlarız. Daha sonra elementleri seçerek ve sonuçtaki eklentiyi çağırarak bunları DOM'ye bağlarız. Fikir benjQuery'nin yeteneklerini genişletmek için s.

Örneğin, sayfanızda bir atlıkarınca istiyorsanız, belki de bir nav öğesine sarılmış sıralanmamış bir rakam listesi tanımlayabilirsiniz. Sayfadaki listeyi seçmek için biraz jQuery yazabilir ve sürgülü animasyonu yapmak için zaman aşımına uğrayan bir galeri olarak gösterebilirsiniz.

AngularJS'de yönergeleri tanımlarız. Yönerge, bir JSON nesnesi döndüren bir işlevdir. Bu nesne, AngularJS'e hangi DOM öğelerini arayacağını ve bunlarda ne gibi değişiklikler yapacağını söyler. Yönergeler, icat ettiğiniz nitelik veya unsurları kullanarak şablona bağlanır. Buradaki fikir, HTML'in yeteneklerini yeni özellikler ve öğelerle genişletmektir.

AngularJS yöntemi, yerel görünümlü HTML’nin özelliklerini genişletmektir. HTML’ye benzeyen, özel niteliklere ve öğelere sahip HTML’yi yazmalısınız.

Bir atlıkarınca istiyorsanız, yalnızca <carousel /> öğeyi kullanın, ardından bir şablon çekmek için bir direktif tanımlayın ve bu enayi çalışmasını sağlayın.

Yapılandırma anahtarlarına sahip büyük eklentilere karşı çok sayıda küçük yönergeler

jQuery'deki eğilim, lightbox gibi büyük ve büyük sayısız değer ve seçeneklerden geçerek yapılandırdığımız büyük eklentiler yazmaktır.

Bu, AngularJS’de bir hatadır.

Bir açılan örnek alın. Bir açılır eklenti yazarken, tıklama işleyicilerinde kodlamaya istekli olabilirsiniz, belki de yukarı veya aşağı olan bir chevron eklemek için bir işlev, belki de katlanmamış öğenin sınıfını değiştirmek, menüyü gizlemek, tüm yararlı şeyleri göstermek. p>

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

Gezinmek için açmak istediğiniz bir menünüz olduğunu söyleyin. Şimdi bir sorunumuz var. Eklentimiz, tıklama işleyicimiz için bize bağlandı, bu durumda farklı davranması için bir yapılandırma seçeneği eklememiz gerekecek.

AngularJS'de daha küçük yönergeler yazıyoruz. Açılan yönergemiz gülünç derecede küçük olurdu. Katlanmış durumu koruyabilir ve katlama (), açılma () veya değiştirme () yöntemlerini sağlayabilir. Bu yöntemler, devleti elinde tutan bir boolean olan $kapsam.menu.visible dosyasını güncellerdi.

Şimdi şablonumuzda bunu bağlayabiliriz:

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

Mouseover güncellemeniz mi gerekiyor?

 
<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ı alanı elde edilir. Durum istisnalarına göre vaka yapmak istiyorsak, şablon bunu kolaylaştırır.

Kapanış - $kapsam

JQuery eklentileri bir kapanışta oluşturulur. Mahremiyet içinde gizlilik korunmaktadır. Bu zincirde kapsam zincirinizi korumak size kalmış. Sadece jQuery tarafından eklentiye iletilen DOM düğümleri kümesine, ayrıca kapanışta tanımlanan herhangi bir yerel değişkene ve tanımladığınız tüm kürelere erişebiliyorsunuz. Bu, eklentilerin tamamen kendi kendine yettiği anlamına gelir. Bu iyi bir şeydir, ancak tam bir uygulama oluştururken kısıtlayıcı olabilir. Dinamik bir sayfanın bölümleri arasında veri iletmeye çalışmak bir angarya haline gelir.

AngularJS, $kapsamı nesnesine sahiptir. Bunlar, modelinizi sakladığınız AngularJS tarafından oluşturulan ve bakımı yapılan özel nesnelerdir. Bazı direktifler, varsayılan olarak JavaScript prototipik mirasını kullanarak varsayılan $kapsamını devralan yeni bir $kapsamı üretecektir. $Kapsamı nesnesine denetleyicide ve görünümde erişilebilir.

Bu akıllıca bir bölüm. $Kapsamı devralma yapısı DOM'nin yapısını kabaca takip ettiğinden, öğeler genel kapsam kapsamına kadar olan (genel kapsam ile aynı olmayan) kendi kapsamlarına ve tüm kapsamları sorunsuz bir şekilde izler.

Bu, etrafta veri aktarılmasını ve verileri uygun bir seviyede saklamayı çok daha kolaylaştırır. Bir açılır listenin açılması durumunda, yalnızca $dropdown kapsamı bunu bilmesi gerekir. Kullanıcı tercihlerini güncellerse, global $kapsamını güncellemek isteyebilirsiniz ve kullanıcı tercihlerini dinleyen iç içe kapsamlar otomatik olarak uyarılır.

Bu karmaşık görünebilir, aslında, içine bir kez rahatladığınızda uçmak gibi. $Kapsamı nesnesini oluşturmanıza gerek yok, AngularJS şablon hiyerarşinize göre onu doğru ve uygun şekilde başlatır ve yapılandırır. Ardından AngularJS, bağımlılık enjeksiyonunun büyüsünü kullanarak bileşeniniz için kullanılabilir kılar (bundan daha fazlası için).

El İle DOM değişiklikleri ve Veri Bağlama

jQuery'de tüm DOM değişikliklerinizi elle yaparsınız. Programlama yoluyla yeni DOM öğelerini oluşturuyorsunuz. Bir JSON diziniz varsa ve onu DOM'ye koymak istiyorsanız, HTML'yi oluşturmak ve eklemek için bir işlev yazmalısınız.

AngularJS'de bunu da yapabilirsiniz, ancak veri bağlamadan yararlanmanız önerilir. Modelinizi değiştirin ve DOM, DOM'nuzun otomatik olarak güncelleyeceği bir şablon aracılığıyla bağlı olduğu için müdahale gerektirmez.

Veri bağlama şablondan yapıldığı için, bir öznitelik veya küme ayracı sözdizimi kullanılarak yapıldığından, yapılması çok kolaydır. Bununla ilgili küçük bilişsel ek yükler var.Kendini her zaman yaparken bulursun.

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

Giriş öğesini $scope.user.name'a bağlar. Girdiyi 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 çıkarır. Bu canlı bir bağlayıcıdır, bu nedenle $scope.user.name değeri güncellendiğinde şablon da güncellenir.

Her zaman Ajax

JQuery'de Ajax araması yapmak oldukça basittir, ancak yine de iki kez düşünebileceğiniz bir şey. Düşünmek için ek bir karmaşıklık ve sürdürülmesi gereken bir senaryo parçası var.

AngularJS'de, Ajax varsayılan çözümünüzdür ve neredeyse hiç farketmeden, her zaman olur. Ng-include ile şablonlar ekleyebilirsiniz. En basit özel yönergeye sahip bir şablon uygulayabilirsiniz. Bir Ajax aramasını bir servise sarabilir ve kendinize bir GitHub servisi veya Flickr hizmeti, şaşırtıcı bir kolaylıkla erişebilirsiniz.

Hizmet Nesneleri ve Yardımcı İşlevler

jQuery'de, bir API'den bir yayın çekmek gibi dom ile ilgili olmayan küçük bir görevi başarmak istiyorsak, kapanışımızda bunun için küçük bir işlev yazabiliriz. Bu geçerli bir çözüm, ancak ya bu beslemeye sık sık erişmek istiyorsak? Ya bu kodu başka bir uygulamada tekrar kullanmak istiyorsak?

AngularJS bize hizmet nesneleri verir.

Hizmetler, işlevler ve veriler içeren basit nesnelerdir. Onlar her zaman tekildirler, yani hiçbir zaman onlardan daha fazlası olamaz. Yığın Taşması API'sine erişmek istediğimizi varsayalım, bunu yapmak için yöntemleri tanımlayan bir StackOverflowService yazabiliriz.

Diyelim ki bir alışveriş sepetimiz var. Alışveriş sepetimizi tutan ve eşya ekleme ve çıkarma yöntemleri içeren bir ShoppingCartService tanımlayabiliriz. Hizmet bir singleton olduğundan ve diğer tüm bileşenler tarafından paylaşıldığından, alışveriş sepetine yazması ve veri alması gereken tüm nesneler tarafından paylaşılması gerekir. Her zaman aynı alışveriş sepeti.

Servis nesneleri, uygun gördükçe kullanabileceğimiz ve yeniden kullanabileceğimiz bağımsız AngularJS bileşenleridir. İşlev ve Veri içeren basit JSON nesneleridir. Her zaman tekildirler, bu nedenle bir servisteki verileri bir yerde saklarsanız, aynı servisi talep ederek bu verileri başka bir yerde alabilirsiniz.

Bağımlılık enjeksiyonu (DI) ve Oluşum - aka de-spaghettification

AngularJS bağımlılıklarınızı sizin için yönetir. Bir nesne istiyorsanız, sadece ona bakın ve AngularJS onu sizin için alacaktır.

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

DI, uygulamanızı yazmak ve birlikte kablolamak yerine, her biri bir dize ile tanımlanan bir bileşen kitaplığı tanımladığınız anlamına gelir.

JSON yayınlarını Flickr'dan çekme yöntemlerini tanımlayan 'FlickrService' adlı bir bileşenim olduğunu söyleyin. Şimdi, Flickr'a erişebilecek bir denetleyici yazmak istersem, denetleyiciyi bildirirken yalnızca adıyla 'FlickrService'e başvurmam gerekir. AngularJS, bileşeni başlatmaya ve kontrol cihazım için uygun duruma getirmeye özen gösterecek.

Örneğin, burada bir hizmet tanımlarım:

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

Şimdi, bu servisi kullanmak istediğimde, sadece buna benzer bir adla başvuruyorum:

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

AngularJS, denetleyiciyi başlatmak için bir FlickrService nesnesinin gerekli olduğunu anlayacak ve bizim için bir tane sağlayacaktır.

Bu, işleri bir araya getirmeyi çok kolay hale getirir ve yayılma riskini ortadan kaldırır. Düz bir bileşen listemiz var ve AngularJS bunları ihtiyaç duyduğumuzda bize tek tek veriyor.

Modüler servis mimarisi

jQuery, kodunuzu nasıl düzenlemeniz gerektiği hakkında çok az şey söylüyor. AngularJS'nin görüşleri var.

AngularJS size kodunuzu yerleştirebileceğiniz modüller verir. Örneğin, Flickr ile konuşan bir senaryo yazıyorsanız, Flickr ile ilgili tüm işlevlerinizi içine 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 uygulamanızın bağlı olacağı diğer tüm modülleri içermelidir.

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

Modüller AngularJS bileşenlerini içerir. Bir modül eklediğimizde, bu modüldeki tüm bileşenler benzersiz dizeleriyle tanımlanan basit bir liste olarak kullanılabilir hale gelir . Ardından, AngularJS'in bağımlılık enjeksiyon mekanizmasını kullanarak bu bileşenleri birbirine enjekte edebiliriz.

Özetlemek için

AngularJS ve jQuery düşman değils. JQuery'i AngularJS içinde çok iyi kullanmak mümkündür. AngularJS kuyu kullanıyorsanız (şablonlar, veri bağlama, $kapsamı, direktifler vb.), Aksi takdirde gerekenden daha az jQuery'ye ihtiyacınız olduğunu göreceksiniz.

Gerçekleşmesi gereken ana şey, şablonunuzun uygulamanızı sürdüğüdür. Her şeyi yapan büyük eklentiler yazmaya çalışmayı bırak. Bunun yerine, tek bir şey yapan küçük yönergeler yazın, sonra bunları bir araya getirmek için basit bir şablon yazın.

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

Küçük kitabım

AngularJS için çok heyecanlandım, çevrimiçi olarak okumak için çok hoş geldiniz diye kısa bir kitap yazdım http://nicholasjohnson.com/angular-book/. Umarım yardımcı olur.

    
184
2017-05-23 12: 26: 38Z
  1. "Endişelerin Ayrılması" nın "MVC (Model, View, Controller)" den farklı olduğu fikri tamamen sahtedir. Endişeleri ayırmanın web dilleri modeli (HTML, CSS ve JS), insanların nasıl göründüğüne (stil /düzen /CSS) veya "ne yaptığına" dikkat etmeden bir web sayfasına (biçimlendirme /HTML) bir şeyler koymalarına izin verir. (DOM etkinlikleri /AJAX /JavaScript). MVC ayrıca endişeleri ayırır. MVC düzenindeki her "katman", veri, yönlendirme /mantık veya görüntü oluşturma gibi farklı bir role sahiptir. Katmanlar geri çağrılar, yollar ve model bağlamalarıyla birleştirilir. Teoride, kişi her katmanda uzmanlaşabilir, ki bu genellikle böyledir.
    2014-09-22 00: 08: 37Z
  2. Sıkı bir SOC arkaplanından gelen biri olarak ve tarayıcı savaşlarına dayanan web standartlarının uzun süredir savunucusu olarak, başlangıçta Angular’ın anlamsal olmayan, geçerliliği olmayan sıkıntılı şablonları. Sadece açısal yazmanın, SOC'yi genel olarak uygulandığı gibi bırakması gerektiğini açıkça belirtmek istedim. Bu zor bir geçiş olabilir.
    2014-09-22 18: 02: 09Z
  3. Haklısın. SOC geniş bir terimdir, ancak web dünyasında SOC'nin çok belirgin bir anlamı vardır (ya da muhtemelen vardır): Anlamsal HTML, davranışsal CSS ve JavaScript. İzleyicilerim hakkında belki de makul olmayan bazı varsayımlar yapıyorum, bu yüzden de özür dilemeliyim.
    2015-01-02 19: 50: 25Z
  4. Yanıtınızı en net ve aydınlatıcı buluyorum. Ben burada oldukça acemiyim, bu yüzden mevcut bir sayfayı değiştirecek bir uzantım varsa (kontrol etmiyorum), JQuery'i o zaman tutmalı mıyım?
    2015-06-24 15: 33: 45Z
  

Gereken paradigma değişikliğini açıklayabilir misiniz?

Zorunluluk Karşılığına Karşı Yasal Uyarı

jQuery ile DOM'a ne olması gerektiğini, adım adım söyleyin. AngularJS ile hangi sonuçları istediğinizi ancak nasıl yapacağınızı tanımlamazsınız. o. Bu konuda daha fazla bilgi buradaki . Ayrıca, Mark Rajcok'un cevabını kontrol edin.

  

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

AngularJS, MVC deseni ( grafik gösterimlerini ) inceleyin. Büyük ölçüde endişelerin ayrılmasına odaklanır.

  

En büyük fark nedir? Yapmayı /kullanmayı bırakmalı mıyım; Bunun yerine ne yapmaya /kullanmaya başlamalıyım?

jQuery bir kütüphanedir

AngularJS , MVC, bağımlılık enjeksiyonu , veri bağlama ve daha fazlası.

üzerinde dururendişelerin ayrılması ve test etme ( ünite testi ve uçtan uca test) , test odaklı geliştirmeyi kolaylaştırır.

Başlamanın en iyi yolu müthiş öğreticilerinden geçmektir. Birkaç saat içinde basamaklardan geçebilirsiniz; ancak, sahnelerin arkasındaki konseptlerde uzmanlaşmak istemeniz durumunda, daha fazla okuma için sayısız referans içerirler.

  

Herhangi bir sunucu tarafı ile ilgili görüş veya kısıtlama var mı?

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

Bunu yapmak, oluşturdukları kaynak fabrikasını kullanmanıza izin verecektir. sunucu tarafınızın soyutlanması RESTful API ve sunucu tarafı çağrıları yapar (al, kaydet, sil, vb.) inanılmaz derecede kolay.

    
152
2017-05-23 12: 02: 47Z
  1. Bence jQuery'nin bir "kütüphane" ve "Köşeli" nin bir "çerçeve" olduğunu söyleyerek suları karıştırıyorsunuz. jQuery'nin bir çerçeve olduğunu iddia etmek mümkündür ... DOM manipülasyonu ve olay işleme özeti. Bu, Angular'ın olduğu gibi bir şey için bir çerçeve olmayabilir, ancak soru sorucunun içinde bulunduğu ikilem budur: onlar gerçekten, Angular ve jQuery arasındaki farkı bilmezler ve tüm sorgulayanlar için, jQuery , istemci ağırlıklı web siteleri oluşturmak için bir çerçevedir. Bu yüzden terminoloji hakkında tartışmak işleri netleştirmeyecek.
    2013-07-25 16: 08: 43Z
  2. Kafan karışan sizsiniz. Bu soru tam olarak bu stackoverflow.com/questions/7062775 adresini ele alıyor. Ayrıca, bu cevap çerçeve ile kütüphane arasındaki farkın netleşmesine yardımcı olabilir: stackoverflow.com/a/148759/620448
    2013-07-25 17: 18: 07Z
  3. Bir kütüphane, işlev koleksiyonu özellikle yararlı veya büyük olduğu için bir "çerçeve" haline gelmez. Bir çerçeve sizin için kararlar alır. AngularJS'i kullanmaya başladığınızda, doğası gereği buna bağlı kalabilirsiniz. (Örn: DOM’i yalnızca yönergelerde güncellemelisiniz, aksi takdirde bir şeyler karışır.) Bunun nedeni AngularJS’in bir çerçeve olmasıdır. JQuery kullandığınızda, araçları en az çatışma riskiyle nispeten kolayca karıştırabilir ve eşleştirebilirsiniz. Bunun nedeni, jQuery'nin bir kütüphane ve en azından yarı iyi bir kütüphanesi olmasıdır.
    2014-09-22 00: 17: 38Z
  4. Bir kütüphane aradığınız koddur. Bir çerçeve kodunuzu çağıran koddur. Bu tanım gereği, Açısal bir çerçevedir. Bileşenleri sağladın ve Angular, bileşenlerinin ihtiyaç duydukları bağımlılıklarla somutlaştığını görüyor.
    2014-09-29 15: 38: 38Z

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

AngularJS, bulma şeklinizi değiştirir elemanları

jQuery 'de, öğeleri bulmak için genellikle seçiciler kullanır ve sonra bunları birleştirirsiniz:
$('#id .class').click(doStuff);

AngularJS 'de, öğeleri doğrudan işaretlemek, bir araya getirmek için direktifleri kullanırsınız:
<a ng-click="doStuff()">

AngularJS, seçicileri kullanarak öğeleri bulmanıza gerek duymaz (veya istemez) - AngularJS'nin jqLite 'ı ile tam gelişmiş jQuery arasındaki ana fark, jqLite seçicileri desteklemiyor .

Böylece insanlar "söylediğindejQuery'yi hiçbir şekilde dahil etmiyoruz ", çünkü esas olarak seçicileri kullanmanızı istemiyorlar; bunun yerine yönergeleri kullanmayı öğrenmenizi istiyorlar. Doğrudan, seçmeyin!

    
84
2014-11-29 08: 46: 50Z
  1. Aynı feragatname olarak, Angular ve jQuery arasında ÇOK daha büyük farklılıklar var. Ancak öğeleri bulma en büyük düşünce değişikliğini gerektiren olanıdır.
    2014-02-21 08: 00: 57Z
  2. hatalıysam beni affet, ama DOM öğesini bulmak için kullandığın bir seçicinin olduğunu düşündüm? Yeni yüklenen UI'nizin her bir parçasını referansta tutmayı tercih edersiniz, sadece bir kullanıcının seçebileceği bir aracı kullanarak tıklayabileceği bir veya 2 öğeyi seçmek yerine? bana daha zor geliyor ..
    2014-05-21 22: 22: 55Z
  3. @ AlexanderPritchard Angular'in amacı, JavaScript'inizden seçmemeniz, doğrudan şablonunuzdan seçmenizdir. Tasarımcının eline güç veren kontrolün tersine çevrilmesi. Bu bilinçli bir tasarım prensibidir. Gerçekten almak Açısal için kodunuzu bu şekilde düşünmeniz gerekir. Yapması zor bir değişim.
    2014-09-23 18: 43: 58Z
  4. @ superluminary Ne harika bir teklif! "seçmeyin; doğrudan!" Cidden, bunu kullanacağım.
    2014-09-24 18: 47: 49Z
  5. Bu AngularJS hakkında en sevdiğim şeylerden biri. UX ekibinin fonksiyonelliğimi kırdığı için ya da tarzlarını kırdığı için endişelenmek zorunda değilim. Sınıfları kullanıyorlar, direktifleri kullanıyorum, dönem. Seçicileri bir bit özlemiyorum.
    2014-10-07 22: 04: 35Z

jQuery

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

angularjs

AngularJS (HTML statik sayfalar için tasarlandığından beri) dinamik web uygulamalarıyla iyi sonuç veren şeyleri yapan kendi HTML etiketlerinizi /niteliklerinizi yapmanızı sağlar.

Düzenleme:

"Bir jQuery geçmişim var, AngularJS'de nasıl düşünürüm?" "HTML geçmişim var, JavaScript’te nasıl düşünürüm?" Soruyu sorduğunuz gerçeği, muhtemelen bu iki kaynağın temel amaçlarını anlamadığınızı göstermektedir. Bu yüzden soruyu cevaplamayı seçtim, "AngularJS yönergeleri kullanıyor, jQuery ise CSS seçicileri kullanarak bunu yapan bir jQuery nesnesi yapmak için CSS seçicilerini kullanıyor." . Bu soru uzun bir cevap gerektirmez.

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

AngularJS, HTML'yi genişlettiğinden, yalnızca bir uygulama yapmak için <div>'u her yere koymanız gerekmez. HTML'yi aslında tasarlandığı şeyden ziyade uygulamalar için çalışır hale getirir, bu statik, eğitimsel web sayfalarıdır. Bunu JavaScript kullanarak dolambaçlı bir şekilde gerçekleştirir, ancak temel olarak JavaScript'in değil, HTML'in bir uzantısıdır.

    
69
2015-06-09 02: 08: 25Z
  1. @ Robert ne yaptığınıza bağlıdır. $(".myclass"), son derece yaygındır ve jQuery'de PO-Javascript'ten biraz daha kolaydır.
    2015-01-02 14: 48: 16Z

jQuery: DOM öğeleri için ' DOM ' u QUERYing ile ilgili çok şey düşünüyorsunuz ve .

AngularJS: Model gerçek, ve siz her zaman bu AÇI'dan düşünüyorsunuz.

Örneğin, DOM’de bir formatta görüntülemek istediğiniz THE sunucusundan veri aldığınızda,jQuery, '1 gerekir. BUL: 'DOM'da bu verileri yerleştirmek istediğiniz' 2. GÜNCELLEME /EKLE yeni bir düğüm oluşturarak ya da sadece innerHTML 'ini ayarlayarak buraya ekleyin. Sonra bu görünümü güncellemek istediğinizde, o zaman '3. 'Yer ve' 4 BUL. GÜNCELLEŞTİRME'. Sunucudan veri alma ve biçimlendirme bağlamında yapılan tüm bu bulma ve güncelleme döngüsü AngularJS'de yapıldı.

AngularJS ile modelinize sahipsiniz (zaten kullandığınız JavaScript nesneleri) ve modelin değeri size modelden (açıkça) ve görünümden bahseder ve modeldeki bir işlem otomatik olarak görünüme geçer. düşünmene gerek yok. Kendinizi AngularJS'te bulacaksınız, DOM'da artık bir şey bulamıyorsunuz.

Başka bir deyişle, jQuery'de, CSS seçicileri hakkında düşünmelisiniz, yani, HTML veya renk veya değerlerini alabilmem için div veya td'un bir sınıfa veya niteliğe sahip olduğu vb. , fakat AngularJS'de kendinizi böyle düşünerek bulacaksınız: hangi modelle uğraşıyorum, modelin değerini true olarak ayarlayacağım. Bu değeri yansıtan görünümün işaretli bir kutu olup olmadığını ya da td öğesinde bulunduğunu düşünmüyorsunuz (jQuery'de sıkça düşünmeniz gereken detaylar).

Ve AngularJS’de DOM manipülasyonuyla, kendinize geçerli HTML uzantıları olarak düşünebileceğiniz yönergeler ve filtreler eklersiniz.

AngularJS'de deneyimleyeceğiniz bir şey daha: jQuery'de jQuery işlevlerini çok çağırıyorsunuz, AngularJS'de AngularJS işlevlerinizi arayacak, böylece AngularJS 'size nasıl bir şey yapılacağını söyleyecektir', ancak faydaları buna değer, Bu yüzden, AngularJS öğrenmek genellikle AngularJS'nin ne istediğini veya AngularJS'nin işlevlerinizi sunmanızı istediği şekilde öğrenmek anlamına gelir ve buna göre bunu arayacaktır. Bu, AngularJS'i bir kütüphaneden ziyade bir çerçeve yapan şeylerden biridir.

    
61
2014-01-15 19: 08: 09Z

Bunlar çok güzel ama uzun cevaplar.

Deneyimlerimi özetlemek için:

  1. Denetleyiciler ve sağlayıcılar (hizmetler, fabrikalar vb.) HTML'yi değil veri modelini değiştirmek içindir.
  2. HTML ve yönergeler, düzeni ve modele bağlamayı tanımlar.
  3. Denetleyiciler arasında veri paylaşmanız gerekirse, bir hizmet veya fabrika oluşturun - bunlar uygulama genelinde paylaşılan tektonlardır.
  4. Bir HTML widget’ına ihtiyacınız varsa, bir yönerge oluşturun.
  5. Bazı verileriniz varsa ve şimdi HTML’yi güncellemeye çalışıyorsanız ... DUR! modeli güncelle ve HTML’nin modele bağlı olduğundan emin ol.
46
2014-08-11 20: 14: 48Z

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

AngularJS bir MV * çerçevesidir.

Aslında, AngularJS az sayıda JavaScript MV * çerçevesinden biridir (çoğu JavaScript MVC aracı hala kategori kitaplığının altındadır).

Çerçeve olmak, kodunuzu barındırır ve ne ve ne zaman arayacağınızla ilgili kararların sahibi olur!

AngularJS'in kendisi içinde bir jQuery-lite sürümü bulunur. Bu nedenle, bazı temel DOM seçim /manipülasyonları için, gerçekten jQuery kütüphanesini dahil etmek zorunda değilsiniz (ağ üzerinde çalışmak için birçok bayt kaydeder.)

AngularJS, DOM manipülasyonu ve yeniden kullanılabilir UI bileşenlerini tasarlamak için "Yönergeler" kavramına sahiptir, bu nedenle DOM manipülasyonuyla ilgili şeyler yapma ihtiyacı duyduğunuzda onu kullanmanız gerekir (yönergeler, yalnızca AngularJS kullanırken jQuery kodunu yazmanız gereken yerdir ).

AngularJS bazı öğrenme eğrileri içerir (jQuery :-) 'den daha fazlası.

- > jQuery arkaplanından gelen herhangi bir geliştirici için ilk tavsiyem "JavaScript'i AngularJS gibi zengin bir çerçeveye geçmeden önce birinci sınıf bir dil olarak öğrenmek!" Yukarıdaki gerçeği zor yoldan öğrendim.

İyi şanslar.

    
45
2014-01-15 19: 11: 39Z

Onlar elma ve portakal. Onları karşılaştırmak istemezsin. Onlar iki farklı şey. AngularJs zaten yerleşik olan tüm JQuery lite, tam DOM bile dahil olmadan temel DOM manipülasyon gerçekleştirmek için izin verirkendi jQuery sürümü.

jQuery, DOM manipülasyonuyla ilgilidir. Tüm çapraz tarayıcı ağrısını çözer, aksi takdirde uğraşmanız gerekir, ancak uygulamanızı AngularJS gibi bileşenlere bölmenize izin veren bir çerçeve değildir.

AngularJs ile ilgili hoş bir şey, direktiflerdeki DOM manipülasyonunu ayırmanıza /yalıtmanıza izin vermesidir. Ng-click gibi kullanmaya hazır dahili yönergeler vardır. Tüm görünüm mantığınızı veya DOM manipülasyonunuzu içerecek kendi özel yönergelerinizi oluşturabilirsiniz, böylece DOM mantık kodunu iş mantığına dikkat etmesi gereken denetleyicilerde veya hizmetlerde karıştırmazsınız.

Angular uygulamanızı içine bölüyor - Kontrolörler - Hizmetler - Görüşler - vb.

ve bir şey daha var, direktif bu. Herhangi bir DOM öğesine ekleyebileceğiniz bir özelliktir ve jQuery'nizin AngularJs bileşenleriyle çakıştığı veya mimarisiyle uğraştığı için endişelenmeden jQuery ile çılgına dönebilirsiniz.

Katıldığım bir buluşmadan 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 etmeyi denemeyin.

    
34
2013-08-14 14: 19: 07Z

podcast'ini dinleyin JavaScript Jabber: Bölüm # 32 AngularJS'nin orijinal yaratıcıları: Misko Hevery & Igor Minar. AngularJS'ye diğer JavaScript arkaplanlarından, özellikle jQuery'den gelmenin nasıl bir şey olduğunu çok konuşurlar.

Podcast'te yayınlanan noktalardan biri, sorunuzla ilgili olarak benim için çok şey tıklattı:

  

MISKO : [...] Angular’da çok zor düşündüğümüz şeylerden biri, nasıl çıkabileceğinizi ve temelde bir yolunu bulabilmeniz için birçok kaçış kapağını nasıl sağlıyoruz? bunun dışında. Yani bizim için cevap, “Direktifler” olarak adlandırılan şudur. Ve direktiflerle, temelde düzenli bir jQuery JavaScript'i haline gelirsiniz, istediğiniz her şeyi yapabilirsiniz.

     

IGOR : Dolayısıyla, şablondaki bu belirli öğeye veya bu CSS'ye ne zaman rastladığınızı söyleyen ve bu tür kodları sakladığınızı söyleyen derleyicinin talimatı olarak yönergeyi düşünün. DOM ağacındaki öğeden ve öğenin altındaki her şeyden sorumlu.

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

Yani, sorunuzu doğrudan cevaplamak için: AngularJS çok yönlü ve gerçek bir MV * çerçevesi. Ancak, hala bildiğiniz ve yönergelerin içindeki jQuery ile sevdiğiniz gerçekten harika şeyler yapabilirsiniz. Bu, "jQuery'de eskisi gibi ne yapabilirim?" Meselesi değil. "AngularJS’e jQuery’de yaptığım şeylerin hepsini nasıl ekleyebilirim?" meselesi olduğu gibi.

Bu gerçekten iki çok farklı zihin durumu.

    
31
2014-01-15 19: 02: 25Z
  1. Kesinlikle hemfikir olduğumdan emin değilim. Fikir almak istiyorsan, Ember'e bak. Angular’ı altıncı fikirlere sahip olarak görüyordum - gördüğümlerin çoğu için, jQuery’in çok az görüşü var ve Ember’in de çok fazla görüşü var. Açısal doğru görünüyor.
    2014-02-06 18: 41: 34Z

Bu soruyu ilginç buluyorum çünkü JavaScript programlamaya ilk ciddi maruz kalmam, Node.js ve AngularJS. JQuery'i hiç öğrenmedim ve sanırım bu iyi bir şey çünkü hiçbir şeyi öğrenmem gerekmiyor. Aslında, problemlerimin jQuery çözümlerinden aktif olarak kaçınıyorum ve bunun yerine, sadece bunları çözmek için bir "AngularJS yolu" aradım. Bu nedenle, bu soruya verdiğim cevabın temelde “jQuery'i hiç öğrenmemiş biri gibi düşün” ve doğrudan jQuery'yi dahil etme eğiliminden kaçınacağını tahmin ediyorum (açıkça AngularJS bunu sahnelerin arkasında bir ölçüde kullanıyor).

    
30
2014-01-15 19: 12: 45Z

AngularJS ve jQuery:

AngularJs ve JQuery, JQLite işlevselliği dışında her seviyede tamamen farklıdır ve AngularJs'in temel özelliklerini öğrenmeye başladığınızda bir kez göreceksiniz.

AngularJs, bağımsız istemci tarafı uygulamasını oluşturmayı teklif eden istemci tarafı bir çerçevedir. JQuery, DOM etrafında oynayan bir istemci tarafı kütüphanesidir.

AngularJs Cool Principle - Kullanıcı arayüzünüzde bazı değişiklikler yapmak istiyorsanız, model veri değişikliği perspektifinden düşünün. Verilerinizi değiştirin, kullanıcı arayüzü yeniden oluşturulur. Gerekmedikçe ve gerekli olmadıkça ve ayrıca Açısal Yönergeler aracılığıyla ele alınmadıkça her zaman DOM etrafında oynamanız gerekmez.

Bu soruyu cevaplamak için, ilk kurumsal uygulamadaki deneyimimi AngularJS ile paylaşmak istiyorum. Bunlar, Angular'ın jQuery zihniyetimizi değiştirmeye başladığımız yerde sağladığı en harika özelliklerdir ve Angular'ı kütüphane yerine bir çerçeve gibi elde ederiz.

İki yönlü veri bağlama şaşırtıcı: UPDATE, DELTE, INSERT fonksiyonlarını içeren bir sisteme sahiptim. Ng-repeat kullanarak ızgara modelini bağlayan bir veri nesnesine sahibim. Sadece silmek ve eklemek için tek bir satır basit JavaScript kodu yazmanız yeterlidir. ızgara modeli anında değiştikçe ızgara otomatik olarak güncellenir. Güncelleme işlevselliği gerçek zamanlıdır, kod yoktur. Kendini harika hissediyorsun !!!

Yeniden kullanılabilir direktifler süper: Yönergeleri tek bir yere yazın ve uygulama boyunca kullanın. AMAN TANRIM!!! Bu yönergeyi sayfalama, regex, validasyon vb. İçin kullandım. Gerçekten harika!

Yönlendirme güçlü: Nasıl kullanmak istediğinizi uygulamanıza bağlı, ancak HTML ve denetleyici (JavaScript) belirtme isteğini yönlendirmek için çok az sayıda kod satırı gerektiriyor

Kontrolörler harika: Denetleyiciler kendi HTML'leriyle ilgilenirler, ancak bu ayrılma, ortak işlevsellik için de iyi çalışır. Ana HTML'deki bir düğmeyi tıklatarak aynı işlevi çağırmak istiyorsanız, her denetleyicide aynı işlev adını yazmanız ve tek tek kod yazmanız yeterlidir.

Eklentiler: Uygulamanızda bir bindirme gösterme gibi başka birçok benzer özellik var. Bunun için kod yazmanıza gerek yoktur, sadece wc-overlay olarak kullanılabilen bir bindirme eklentisini kullanın ve bu otomatik olarak tüm XMLHttpRequest (XHR) istekleri.

RESTful mimarisi için ideal: Tam bir çerçeve olmak, AngularJS'yi RESTful bir mimariyle çalışmak için mükemmel yapar. REST CRUD API'lerini çağırmak çok kolaydır ve

Hizmetler : Hizmetleri kullanarak ortak kodları ve denetleyicilerde daha az kod yazın. Kontrol cihazları arasında ortak işlevleri paylaşmak için servisler kullanılabilir.

Genişletilebilirlik : Angular, HTML direktiflerini açısal yönergeleri kullanarak genişletti. İfadeleri html içine yazın ve çalışma zamanında değerlendirin. Kendi direktiflerinizi ve hizmetlerinizi oluşturun ve ilave bir çaba göstermeden başka bir projede kullanın.

    
23
2015-05-24 02: 56: 31Z

Bir JavaScript MV * acemi olarak ve tamamen uygulama mimarisine odaklanarak (sunucu /müşteri tarafı ile ilgili değil), aşağıdaki kaynağı kesinlikle tavsiye ederim (henüz şaşırmamıştım): JavaScript Tasarım Modelleri , Addy Osmani tarafından, farklı JavaScript Tasarım Desenleri 'ye giriş olarak. Bu cevapta kullanılan terimler yukarıdaki bağlantılı belgeden alınmıştır. Kabul edilen cevabın gerçekte iyi yazılmış olanlarını tekrarlamayacağım. Bunun yerine, bu cevap AngularJS'e (ve diğer kütüphanelere) güç veren teorik geçmişlere geri döner.

Benim gibi, AngularJS (veya Ember.js , Durandal ve diğer MV’lerin hızlı bir şekilde farkına varacaksınız. * bu konudaki çerçeveler) farklı JavaScript tasarım modellerinin çoğunu birleştiren karmaşık bir çerçevedir.

(1) yerel JavaScript kodunu ve (2) daha küçük kitaplıkları bu kalıpların her biri için ayrı ayrı /ayrı ayrı test etmek için de daha kolay buldum > tek bir küresel çerçeveye dalmadan önce. Bu, bir çerçevenin hangi önemli konulara girdiğini daha iyi anlamamı sağladı (çünkü sorunla kişisel olarak karşı karşıya kalıyorsunuz).

Örneğin:

  • JavaScript Nesneye Yönelik Programlama (bu bir Google arama bağlantısıdır). Bu bir kütüphane değildir, ancak herhangi bir uygulama programlamasının kesinlikle bir ön şartıdır. Bana prototip, yapıcı, singleton ve amp; yerel uygulamalarını öğretti. dekoratör desenleri
  • Cephe düzeni için jQuery / alt çizgi (DOM'yi değiştirmek için WYSIWYG'ler gibi)
  • prototip /yapıcı /karma kalıp modeli için Prototype.js
  • için RequireJS / Curl.js modül kalıbı /AMD
  • gözlenebilir, yayınlama /abone olma modeli için KnockoutJS

Not: Bu liste tamamlanmadı ya da 'en iyi kitaplıklar'; onlar sadece benim kullandığım kütüphaneler. Bu kütüphaneler ayrıca daha fazla desen içerir, bahsedilenler sadece ana odakları veya orijinal amaçlarıdır. Bu listeden bir şey eksik olduğunu düşünüyorsanız, lütfen yorumlarda belirtin, ben de eklemekten memnuniyet duyarım.

    
20
2014-11-29 08: 54: 35Z

Aslında, AngularJS kullanıyorsanız, artık jQuery'ye ihtiyacınız yok. AngularJS'in kendisi, jQuery ile yapabileceğiniz birçok şey için çok iyi bir "yer değiştirme" olan bağlayıcı ve yönergeye sahiptir.

Genellikle AngularJS ve Cordova 'yı kullanarak mobil uygulamalar geliştiririm. JQuery'den ihtiyacım olan YALNIZ şey Selector.

Google’dan, dışarıda bağımsız bir jQuery seçici modül olduğunu görüyorum. Sizzle.

Ve JQuery Selector’un (Sizzle’i kullanarak) kullanarak AngularJS kullanarak bir web sitesine hızlı bir şekilde başlamama yardımcı olan küçük bir kod pasajı yapmaya karar verdim.

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

    
12
2014-11-22 15: 41: 23Z
kaynak yerleştirildi İşte