javascript - "التفكير في AngularJS" إذا كان لدي خلفية jQuery؟




(10)

هل يمكنك وصف التحول الفكري الذي هو ضروري؟

ضروري مقابل التعريفي

باستخدام jQuery ، يمكنك إخبار DOM بما يجب أن يحدث ، خطوة بخطوة. مع AngularJS يمكنك وصف النتائج التي تريدها ولكن ليس كيفية القيام بها. المزيد عن هذا here . أيضًا ، تحقق من إجابة مارك راجكوك.

كيف يمكنني تصميم وتصميم تطبيقات الويب من جانب العميل بشكل مختلف؟

AngularJS هو إطار كامل من جانب العميل يستخدم نمط MVC (راجع تمثيل رسوماته ). وهو يركز بشكل كبير على فصل المخاوف.

ما هو الفرق الأكبر؟ ماذا يجب أن أتوقف عن فعل / استخدام ؛ ما الذي يجب أن أبدأ به / استخدمه بدلاً من ذلك؟

jQuery هي مكتبة

AngularJS هو إطار جميل من جانب العميل ، قابل للاختبار بدرجة عالية ، يجمع بين العديد من الأشياء الرائعة مثل MVC ، وحقن التبعية ، وربط البيانات وأكثر من ذلك بكثير.

ويركز على فصل المخاوف والاختبارات (اختبار الوحدة والاختبار من طرف إلى طرف) ، مما يسهل التطوير القائم على الاختبار.

أفضل طريقة للبدء هي من خلال برنامجهم التعليمي الرائع . يمكنك الذهاب من خلال الخطوات في بضع ساعات. ومع ذلك ، في حال كنت تريد إتقان المفاهيم الكامنة وراء الكواليس ، فإنها تتضمن عددًا لا يحصى من المرجع لمزيد من القراءة.

هل هناك أي اعتبارات / قيود على جانب الخادم؟

يمكنك استخدامه على التطبيقات الموجودة حيث تستخدم بالفعل jQuery نقية. ومع ذلك ، إذا كنت ترغب في الاستفادة الكاملة من ميزات AngularJS ، فقد تفكر في ترميز جانب الخادم باستخدام طريقة RESTful .

سيسمح لك ذلك بالاستفادة من مصنع الموارد الخاص به ، والذي يخلق تجريدًا API RESTful من جانب الخادم ويجعل المكالمات من جانب الخادم (الحصول عليها وحفظها وحذفها وغير ذلك) سهلة للغاية.

لنفترض أنني على دراية بتطوير تطبيقات من جانب العميل في jQuery ، لكن الآن أود البدء باستخدام AngularJS . هل يمكنك وصف التحول الفكري الذي هو ضروري؟ إليك بعض الأسئلة التي قد تساعدك في صياغة إجابة:

  • كيف يمكنني تصميم وتصميم تطبيقات الويب من جانب العميل بشكل مختلف؟ ما هو الفرق الأكبر؟
  • ماذا يجب أن أتوقف عن فعل / استخدام ؛ ما الذي يجب أن أبدأ به / استخدمه بدلاً من ذلك؟
  • هل هناك أي اعتبارات / قيود على جانب الخادم؟

أنا لا أبحث عن مقارنة مفصلة بين jQuery و AngularJS .


1. لا تصمم صفحتك ، ثم قم بتغييرها باستخدام DOM

في jQuery ، يمكنك تصميم صفحة ، ثم جعلها ديناميكية. هذا لأن jQuery تم تصميمه من أجل التعزيز ونما بشكل لا يصدق من هذا المنطلق البسيط.

ولكن في AngularJS ، يجب أن تبدأ من الألف إلى الياء مع هندستك في الاعتبار. بدلاً من البدء بالتفكير "لدي هذه القطعة من DOM وأريد أن أجعلها تفعل X" ، عليك أن تبدأ بما تريد تحقيقه ، ثم اذهب إلى تصميم التطبيق الخاص بك ، ثم تذهب في النهاية نحو تصميم العرض الخاص بك.

2. لا تزيد مع jQuery AngularJS

وبالمثل ، لا تبدأ بفكرة أن jQuery يقوم بـ X ، و Y ، و Z ، لذلك سأضيف AngularJS فوق ذلك للنماذج ووحدات التحكم. هذا مغرٍ حقًا عندما تبدأ للتو ، ولهذا السبب أوصي دائمًا بأن مطوري AngularJS الجدد لا يستخدمون jQuery على الإطلاق ، على الأقل حتى يعتادوا على فعل الأشياء "Angular Way".

لقد رأيت العديد من المطورين هنا وفي قائمة المراسلات الإلكترونية ينشئون هذه الحلول المتقنة بمكونات jQuery المكونة من 150 أو 200 سطر من الكود ، ثم يقومون بغراءها في AngularJS مع مجموعة من الاستدعاءات وتطبيقات $apply s التي تكون مربكة وملفقة ؛ لكنهم في النهاية يعملون! المشكلة هي أنه في معظم الحالات يمكن إعادة كتابة هذا البرنامج المساعد في AngularJS في جزء من الشفرة ، حيث يصبح كل شيء فجأة مفهومة ومباشرة.

خلاصة القول هي هذه: عند حل ، أولا "التفكير في AngularJS" ؛ إذا لم تستطع التفكير في حل ، اسأل المجتمع ؛ إذا لم يكن هناك حل سهل بعد ذلك ، فلا تتردد في الوصول إلى jQuery. ولكن لا تدع jQuery تصبح عكاز أو أنك لن تتقن AngularJS.

3. دائما نفكر في مجال الهندسة المعمارية

أولاً ، تعرف أن التطبيقات ذات الصفحة الواحدة هي تطبيقات . انهم ليسوا صفحات الويب. لذلك نحن بحاجة إلى التفكير كمطور من جانب الخادم بالإضافة إلى التفكير كمطور من جانب العميل. علينا أن نفكر في كيفية تقسيم طلبنا إلى مكونات فردية قابلة للتوسعة قابلة للاختبار.

إذن كيف تفعل ذلك؟ كيف "تفكر في AngularJS"؟ فيما يلي بعض المبادئ العامة ، مقارنة مع jQuery.

وجهة النظر هي "السجل الرسمي"

في jQuery ، نقوم بتغيير العرض برمجيًا. يمكن أن يكون لدينا قائمة منسدلة تُعرف باسم ul مثل:

<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 ، في منطق التطبيق لدينا ، سنقوم بتنشيطه بشيء مثل:

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

عندما ننظر إلى العرض ، ليس من الواضح على الفور أن هناك أي وظائف هنا. للتطبيقات الصغيرة ، فلا بأس. ولكن بالنسبة للتطبيقات غير البسيطة ، سرعان ما تصبح الأمور مربكة ويصعب الحفاظ عليها.

في AngularJS ، رغم ذلك ، فإن العرض هو السجل الرسمي للوظائف القائمة على العرض. سيبدو إعلاننا على هذا النحو بدلاً من ذلك:

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

هذان يفعلان نفس الشيء ، لكن في نسخة AngularJS ، كل من يبحث في النموذج يعرف ما الذي يفترض أن يحدث. عندما يأتي عضو جديد في فريق التطوير على متن الطائرة ، يمكنها النظر إلى هذا الأمر ومن ثم تعرف أن هناك توجيهًا يسمى dropdownMenu يعمل عليه ؛ هي لا تحتاج أن تستشعر الإجابة الصحيحة أو تدقيق أي كود. أخبرنا الرأي بما كان من المفترض أن يحدث. نظافة كثير

غالبًا ما يطرح المطورون الجدد في AngularJS سؤالًا مثل: كيف يمكنني العثور على جميع الروابط من نوع معين وإضافة توجيه إليها. يزعج المطور دائمًا عندما نرد: لا تفعل. ولكن السبب في عدم القيام بذلك هو أن هذا هو مثل نصف jQuery ، ونصف AngularJS ، وليس جيدا. المشكلة هنا هي أن المطور يحاول "القيام jQuery" في سياق AngularJS. هذا لن ينجح أبداً. الرأي هو السجل الرسمي. خارج أي توجيه (أكثر على هذا أدناه) ، لن تقوم أبدًا أبدًا بتغيير DOM. ويتم تطبيق التوجيهات في وجهة النظر ، لذلك القصد واضح.

تذكر: لا تصمم ، ثم ضع علامة. يجب عليك المهندس المعماري ، ثم تصميم.

ربط البيانات

هذا إلى حد بعيد واحدة من الميزات الأكثر روعة من AngularJS ويقطع الكثير من الحاجة للقيام بأنواع من التلاعبات DOM التي ذكرتها في القسم السابق. سوف AngularJS تلقائيا بتحديث طريقة العرض الخاصة بك حتى لا تضطر إلى! في jQuery ، نرد على الأحداث ثم نقوم بتحديث المحتوى. شيء مثل:

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

لعرض يشبه هذا:

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

وبصرف النظر عن اختلاط المخاوف ، لدينا أيضًا نفس المشاكل التي تشير إلى النية التي ذكرتها من قبل. ولكن الأهم من ذلك ، كان علينا الإشارة إلى عقدة DOM وتحديثها يدويًا. وإذا أردنا حذف إدخال سجل ، فلابد أن نرمز إلى DOM مقابل ذلك أيضًا. كيف نختبر المنطق بغض النظر عن DOM؟ وماذا لو أردنا تغيير العرض التقديمي؟

هذا الفوضى قليلا واهية تافه. لكن في AngularJS ، يمكننا القيام بذلك:

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

ومن وجهة نظرنا يمكن أن تبدو هكذا:

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

ولكن بالنسبة إلى هذه المسألة ، يمكن أن يكون نظرتنا كما يلي:

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

والآن بدلاً من استخدام قائمة غير مرتبة ، نستخدم مربعات تنبيه Bootstrap. ونحن لم يكن لدينا لتغيير رمز وحدة التحكم! ولكن الأهم من ذلك ، بغض النظر عن مكان أو كيفية تحديث السجل ، سيتغير المشهد أيضًا. تلقائيا. أنيق!

على الرغم من عدم عرضه هنا ، إلا أن ربط البيانات يكون في اتجاهين. لذا يمكن أيضًا أن تكون رسائل السجل هذه قابلة للتعديل في العرض فقط عن طريق القيام بذلك: <input ng-model="entry.msg" /> . وكان هناك الكثير من الابتهاج.

طبقة نموذج متميزة

في jQuery ، يكون DOM نوعًا مثل النموذج. ولكن في AngularJS ، لدينا طبقة نموذج منفصلة يمكننا إدارتها بأي طريقة نريدها ، بشكل مستقل تمامًا عن العرض. هذا يساعد على ربط البيانات أعلاه ، ويحافظ على فصل المخاوف ، ويقدم اختبار أكبر بكثير. ذكرت إجابات أخرى هذه النقطة ، لذلك سأتركها في ذلك.

فصل المخاوف

وكل ما سبق ذكره في هذا الموضوع الشامل: الحفاظ على مخاوفك منفصلة. وجهة نظرك بمثابة السجل الرسمي لما يُفترض حدوثه (بالنسبة للجزء الأكبر) ؛ النموذج الخاص بك يمثل البيانات الخاصة بك ؛ لديك طبقة خدمة لأداء مهام قابلة لإعادة الاستخدام ؛ تقوم بمعالجة DOM وتعزيز وجهة نظرك مع التوجيهات ؛ وتلصقها جميعًا مع أجهزة التحكم. تم ذكر ذلك أيضًا في إجابات أخرى ، والشيء الوحيد الذي أود إضافته يتعلق بالإختبار ، والذي ناقشه في قسم آخر أدناه.

حقن التبعية

لمساعدتنا مع فصل المخاوف هو حقن التبعية (DI). إذا كنت قادمًا من لغة من جانب الخادم (من Java إلى PHP ) فأنت على الأرجح على دراية بهذا المفهوم بالفعل ، ولكن إذا كنت من الأفراد القادمين من jQuery ، فإن هذا المفهوم قد يبدو كأنه شيء سخيف من لا لزوم له . لكنها ليست كذلك. :-)

من منظور واسع ، تعني DI أن بإمكانك الإعلان عن المكونات بحرية تامة ومن ثم أي مكون آخر ، فما عليك سوى طلب نسخة منها وسيتم منحها. لا يتعين عليك معرفة أمر التحميل أو مواقع الملفات أو أي شيء من هذا القبيل. قد لا تظهر الطاقة على الفور ، ولكن سأقدم مثالًا واحدًا (شائعًا): الاختبار.

لنفترض في طلبنا ، أننا نطلب خدمة تقوم بتنفيذ التخزين من جانب الخادم من خلال واجهة REST تطبيقات REST ، وبناءً على حالة التطبيق ، التخزين المحلي أيضًا. عند إجراء اختبارات على وحدات التحكم لدينا ، لا نريد أن نتواصل مع الخادم - فنحن نختبر وحدة التحكم ، بعد كل شيء. يمكننا فقط إضافة خدمة صورية تحمل نفس اسم المكون الأصلي ، وسيضمن الحاقن أن وحدة التحكم الخاصة بنا تحصل على وحدة التزييف تلقائيًا - وحدة تحكمنا لا تحتاج إلى معرفة الفرق.

الحديث عن الاختبار ...

4. التطوير مدفوع بالتجربة - دائما

هذا في الواقع جزء من القسم 3 الخاص بالعمارة ، ولكن من المهم جدًا أن أضعه في قسم المستوى الأعلى الخاص به.

من بين العديد من الإضافات jQuery التي شاهدتها أو استخدمتها أو كتبت ، كم منها كان بها جناح اختبار مصاحب؟ ليس كثيرًا لأن jQuery غير قابل تمامًا لذلك. لكن AngularJS هو.

في jQuery ، تكون الطريقة الوحيدة للاختبار في كثير من الأحيان هي إنشاء المكون بشكل مستقل مع صفحة نموذج / عرض يمكن لاختباراتنا من خلالها تنفيذ معالجة DOM. لذلك يتعين علينا تطوير مكون بشكل منفصل ثم دمجه في تطبيقنا. كيف غير مريح! في كثير من الأحيان ، عند التطوير باستخدام jQuery ، نختار التكرارية بدلاً من التطوير القائم على الاختبار. ومن يستطيع أن يلومنا؟

ولكن لأن لدينا فصل المخاوف ، يمكننا أن نفعل التطوير المدفوع بالاختبارات بشكل تكراري في AngularJS! على سبيل المثال ، لنفترض أننا نريد توجيهًا فائقًا بسيطًا للإشارة إلى ما هو مسارنا الحالي في القائمة. يمكننا أن نعلن ما نريد في نظر طلبنا:

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

حسنًا ، يمكننا الآن كتابة اختبار للتوجيه غير when-active :

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

وعندما نجري الاختبار ، يمكننا تأكيد أنه فشل. الآن فقط يجب علينا إنشاء التوجيه الخاص بنا:

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

يمر اختبارنا الآن وتؤدي القائمة لدينا على النحو المطلوب. تطورنا هو على حد سواء تكرارية واختبارها مدفوعة. خبيث رائع.

5. من الناحية المفاهيمية ، لا يتم تعبئة توجيهات jQuery

ستسمع غالبًا "لا تفعل سوى DOM التلاعب في التوجيه". هذه ضرورة. تعامل مع الاحترام الواجب!

ولكن دعونا نغوص أعمق قليلا ...

بعض التوجيهات فقط تزين ما هو موجود بالفعل في العرض (يفكر في ngClass ) ، وبالتالي في بعض الأحيان يتم التلاعب ngClass DOM على الفور ثم يتم القيام به بشكل أساسي. ولكن إذا كان التوجيه يشبه "عنصر واجهة المستخدم" ولديه نموذج ، يجب عليه أيضًا احترام فصل المخاوف. وهذا يعني أن القالب أيضًا يجب أن يبقى مستقلاً إلى حد كبير عن تنفيذه في وظائف الوصلة والتحكم.

يأتي AngularJS مع مجموعة كاملة من الأدوات لجعل هذا سهل للغاية. مع ngClass يمكننا تحديث الطبقة بشكل ديناميكي ؛ ngModel يسمح ربط البيانات في اتجاهين. ngShow و ngHide برمجيا إظهار أو إخفاء عنصر. وغيرها الكثير - بما في ذلك تلك التي نكتب أنفسنا. وبعبارة أخرى ، يمكننا القيام بكل أنواع الذهول بدون التلاعب بالـ DOM. وكلما قل التلاعب بـ DOM ، فإن التوجيهات الأسهل هي اختبار ، وأسهل أسلوبها ، وأسهل تغييرها في المستقبل ، وأكثر قابلية لإعادة استخدامها وقابليتها للتوزيع.

أرى الكثير من المطورين الجدد في AngularJS باستخدام التوجيهات كمكان لرمي مجموعة من jQuery. وبعبارة أخرى ، فإنهم يفكرون "بما أنني لا أستطيع القيام بتلاعب DOM في وحدة التحكم ، فسوف أقوم بوضع هذا الرمز في توجيه". على الرغم من أن هذا بالتأكيد أفضل بكثير ، إلا أنه غالبًا ما يكون خاطئًا .

فكر في المسجل الذي قمنا ببرمجته في القسم 3. حتى لو وضعنا ذلك في توجيه ، ما زلنا نرغب في القيام به "Angular Way". لا يزال لا يأخذ أي تلاعب بـ DOM! هناك الكثير من المرات التي يكون فيها استخدام DOM ضروريًا ، لكنه أكثر ندرة مما تتخيل! قبل التلاعب بـ DOM في أي مكان في طلبك ، اسأل نفسك إذا كنت بحاجة إلى ذلك. قد يكون هناك طريقة أفضل.

إليك مثال سريع يوضح النمط الذي أراه كثيرًا. نريد زر قابل للتبديل. (ملاحظة: هذا المثال مفتعل قليلاً ولفوش كوشوك لتمثيل حالات أكثر تعقيدًا يتم حلها بنفس الطريقة تمامًا).

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

هناك بعض الأخطاء في هذا:

  1. أولاً ، لم يكن jQuery ضروريًا أبدًا. لا يوجد شيء قمنا به هنا والذي يحتاج إلى jQuery على الإطلاق!
  2. ثانيًا ، حتى إذا كان لدينا بالفعل jQuery على صفحتنا ، فلا يوجد سبب لاستخدامه هنا ؛ يمكننا ببساطة استخدام angular.element عملنا مكون عند إسقاطها في مشروع ليس لديها jQuery.
  3. ثالثًا ، حتى لو كان jQuery مطلوبًا لتنفيذ هذا التوجيه ، فسيستخدم jqLite ( angular.element ) دائمًا jQuery إذا تم تحميله! لذلك نحن لا نحتاج إلى استخدام $ - يمكننا فقط استخدام angular.element .
  4. رابعاً ، يرتبط ارتباطاً وثيقاً بالثالث ، هو أن عناصر jqLite لا يجب أن تكون ملفوفة $ - element الذي يتم تمريره إلى وظيفة link سيكون بالفعل عنصر jQuery!
  5. والخامس ، الذي ذكرناه في الأقسام السابقة ، لماذا نمزج عناصر القالب في منطقنا؟

يمكن إعادة كتابة هذا التوجيه (حتى في الحالات المعقدة للغاية!) ببساطة أكثر مثل:

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

ومرة أخرى ، فإن نموذج القالب موجود في القالب ، بحيث يمكنك (أو مستخدميك) تبديله بسهولة من خلال نموذج يلبي أي نمط ضروري ، ولم يكن من الضروري أن يتم لمس المنطق . إعادة الاستخدام - ازدهار!

وما زالت هناك كل هذه المزايا الأخرى ، مثل الاختبار - إنها سهلة! وبغض النظر عما يوجد في القالب ، لا يتم لمس واجهة API الداخلية الخاصة بالتوجيه ، لذا من السهل إعادة بيعها. يمكنك تغيير القالب قدر ما تريد دون لمس التوجيه. وبغض النظر عما تقوم بتغييره ، فستستمر اختباراتك.

w00t!

إذن ، إذا لم تكن التوجيهات مجرد مجموعات من الوظائف المشابهة لـ jQuery ، فما هي؟ التوجيهات هي في الواقع ملحقات HTML . إذا لم تفعل HTML شيئًا تحتاج إلى القيام به ، فأنت تكتب توجيهًا للقيام بذلك نيابةً عنك ، ثم استخدمه كما لو كان جزءًا من HTML.

بعبارة أخرى ، إذا لم يقم AngularJS بعمل شيء ما خارج الصندوق ، فكّر في كيفية قيام الفريق بإنجازه ngClick مع ngClick و ngClass و et al.

ملخص

لا تستخدم حتى jQuery. لا تدرجه حتى. سوف يعيقك. وعندما تصل إلى مشكلة تعتقد أنك تعرف كيفية حلها في jQuery بالفعل ، قبل أن تصل إلى $ ، حاول التفكير في كيفية القيام بذلك داخل حدود AngularJS. إذا كنت لا تعرف ، اسأل! 19 مرة من 20 ، أفضل طريقة للقيام بذلك لا تحتاج إلى jQuery ومحاولة حلها مع نتائج jQuery في مزيد من العمل بالنسبة لك.


مسج

jQuery يجعل أوامر جافا سكريبت طويلة يبعث على السخرية مثل getElementByHerpDerpأقصر ومتقاطعة عبر متصفح.

AngularJS

يتيح لك AngularJS إنشاء علامات / سمات HTML الخاصة بك التي تقوم بأشياء تعمل بشكل جيد مع تطبيقات الويب الديناميكية (حيث تم تصميم HTML للصفحات الثابتة).

تصحيح:

قائلا "لدي خلفية jQuery كيف أفكر في AngularJS؟" يشبه القول "لدي خلفية HTML كيف أفكر في JavaScript؟" إن حقيقة طرحك للسؤال توضح أنك لن تفهم على الأغلب الأغراض الأساسية لهذين الموردين. ولهذا السبب اخترت الإجابة عن السؤال من خلال الإشارة ببساطة إلى الاختلاف الأساسي بدلاً من الذهاب إلى القائمة بقول "AngularJS تستخدم التوجيهات في حين أن jQuery تستخدم CSS selectors لعمل كائن jQuery الذي يقوم بهذا وذاك ... إلخ". . هذا السؤال لا يتطلب إجابة مطولة.

jQuery هي طريقة لجعل برمجة جافا سكريبت في المتصفح أسهل. أوامر أقصر عبر المستعرض ، وما إلى ذلك.

AngularJS يمتد HTML ، لذلك ليس لديك لوضع في <div>كل مكان فقط لتقديم طلب. يجعل HTML تعمل بالفعل للتطبيقات بدلا من ما تم تصميمه ل ، وهو ثابت صفحات الويب التعليمية. إنها تحقق ذلك بطريقة دائرية باستخدام جافا سكريبت ، ولكنها في الأساس عبارة عن امتداد لـ HTML ، وليس JavaScript.


لا بد من → التعريفي

في jQuery ، يتم استخدام المحددات للعثور على عناصر DOM ثم ربط / تسجيل معالجات الأحداث لهم. عند تشغيل حدث ما ، ينفذ هذا الرمز (الإلزامي) لتحديث / تغيير DOM.

في AngularJS ، تريد التفكير في طرق العرض بدلاً من عناصر DOM. المشاهدات هي (افتراضية) HTML التي تحتوي على توجيهات AngularJS. تضع التوجيهات معالجات الأحداث خلف الكواليس لنا وتعطينا ربطًا ديناميكيًا. نادرا ما يتم استخدام المختارين ، وبالتالي فإن الحاجة إلى المعرفات (وبعض أنواع الطبقات) تتضاءل إلى حد كبير. ترتبط المشاهدات بالنماذج (عبر النطاقات). وجهات النظر هي إسقاط للنموذج. نماذج تغيير الأحداث (أي ، البيانات ، خصائص النطاق) ، والمشاهدات التي تعرض تحديث هذه النماذج "تلقائيًا".

في AngularJS ، فكر في النماذج ، بدلاً من عناصر DOM المحددة في jQuery والتي تمسك ببياناتك. فكر في المشاهدات كإسقاطات لهذه النماذج ، بدلاً من تسجيل طلبات الاسترداد للتلاعب بما يراه المستخدم.

فصل المخاوف

jQuery توظف جافا سكريبت غير مزعجة - يتم فصل سلوك (JavaScript) من الهيكل (HTML).

يستخدم AngularJS أجهزة التحكم والتوجيهات (كل منها يمكن أن يكون جهاز التحكم الخاص به ، و / أو ترجمة وربط الوظائف) لإزالة السلوك من العرض / البنية (HTML). لدى Angular أيضًا خدمات ومرشحات للمساعدة في فصل / تنظيم طلبك.

انظر أيضًا https://.com/a/14346528/215945

تصميم التطبيق

نهج واحد لتصميم تطبيق AngularJS:

  1. فكر في نماذجك. إنشاء خدمات أو كائنات JavaScript الخاصة بك لهذه النماذج.
  2. فكر في الطريقة التي تريد بها تقديم نماذجك - وجهات نظرك. قم بإنشاء قوالب HTML لكل طريقة عرض ، باستخدام الأوامر الضرورية للحصول على ربط بيانات ديناميكي.
  3. يمكنك إرفاق وحدة تحكم بكل عرض (باستخدام عرض ng والتوجيه أو ng-controller). اطلب من وحدة التحكم العثور على / الحصول فقط على أي بيانات نموذجية يحتاجها العرض للقيام بعمله. جعل وحدات التحكم رقيقة قدر الإمكان.

الوراثة البدائية

يمكنك القيام بالكثير مع jQuery دون معرفة كيفية عمل الوراثة النموذجية لجافا سكريبت. عند تطوير تطبيقات AngularJS ، سوف تتجنب بعض العثرات الشائعة إذا كان لديك فهم جيد لميراث JavaScript. القراءة الموصى بها: ما هي الفروق الدقيقة في الميراث النموذجي / النموذجي في AngularJS؟


jQuery هي مكتبة معالجة DOM.

AngularJS هو إطار MV *.

في الواقع ، AngularJS هي واحدة من الأطر القليلة JavaScript MV * (العديد من أدوات MVC JavaScript لا تزال تندرج تحت مكتبة الفئات).

كونها إطارًا ، فإنها تستضيف شفرتك وتتولى اتخاذ القرارات بشأن ما تتصل به ومتى!

يتضمن AngularJS نفسه إصدار jQuery-lite بداخله. لذا بالنسبة لبعض عمليات تحديد / معالجة DOM الأساسية ، فأنت لا تحتاج إلى تضمين مكتبة jQuery (فهي تحفظ الكثير من وحدات البايت للتشغيل على الشبكة).

AngularJS لديه مفهوم "توجيهات" للتلاعب DOM وتصميم مكونات UI قابلة لإعادة الاستخدام ، لذلك يجب عليك استخدامه عندما تشعر بالحاجة إلى القيام بالأشياء ذات الصلة بالتلاعب DOM (التوجيهات هي المكان الوحيد الذي يجب أن تكتب فيه jQuery code أثناء استخدام AngularJS).

ينطوي AngularJS على بعض منحنى التعلم (أكثر من jQuery :-).

-> لأي مطور قادم من خلفية jQuery ، ستكون نصيحتي الأولى هي "تعلم JavaScript كلغة من الدرجة الأولى قبل القفز على إطار عمل غني مثل AngularJS!" تعلمت الحقيقة المذكورة أعلاه بالطريقة الصعبة.

حظا سعيدا.


لوصف "النقلة النوعية" ، أعتقد أن الإجابة القصيرة يمكن أن تكون كافية.

AngularJS يغير الطريقة التي تجد بها العناصر

في jQuery ، عادة ما تستخدم محددات للعثور على عناصر ، ثم تقوم بسحبها:
$('#id .class').click(doStuff);

في AngularJS ، تستخدم التوجيهات لتحديد العناصر مباشرة ، لسحبها:
<a ng-click="doStuff()">

لا تحتاج AngularJS (أو تريد) العثور على عناصر باستخدام محددات - الاختلاف الأساسي بين jqLite الخاص بـ AngularJS مقابل jQuery الكامل هو أن jqLite لا يدعم المحددات .

لذلك عندما يقول الناس "لا تشمل jQuery على الإطلاق" ، فإن السبب الرئيسي في ذلك هو أنهم لا يريدون استخدام محددات. يريدون منك تعلم استخدام التوجيهات بدلاً من ذلك. مباشرة ، وليس اختيار!


jQuery: تفكر كثيرًا في "QUERYing the DOM " لعناصر DOM وفعل شيء ما.

AngularJS: النموذج هو الحقيقة ، وكنت أفكر دائما من هذا ANGLE.

على سبيل المثال ، عندما تحصل على بيانات من الخادم الذي تنوي عرضه بتنسيق ما في DOM ، في jQuery ، تحتاج إلى "1". العثور على 'أين في DOM الذي تريد وضع هذه البيانات ،' 2. UPDATE / APPEND "هناك من خلال إنشاء عقدة جديدة أو مجرد ضبط innerHTML . ثم عندما تريد تحديث هذا العرض ، فإنك "3. العثور على "الموقع و" 4. تحديث'. ذهب هذه الدورة من العثور على وتحديث كل القيام به في نفس السياق من الحصول على وتنسيق البيانات من الخادم في AngularJS.

باستخدام AngularJS ، لديك نموذجك (كائنات جافا سكريبت التي اعتدت استخدامها بالفعل) وقيمة النموذج تخبرك عن النموذج (بشكل واضح) وعن العرض ، وتنتشر عملية في النموذج تلقائيًا إلى العرض ، لذلك لا تفعل ذلك. لا بد لي من التفكير في الامر. سوف تجد نفسك في AngularJS لم يعد العثور على الأشياء في DOM.

لوضع طريقة أخرى ، في jQuery ، يجب أن تفكر في محددات CSS ، أي ، أين يوجد divأو tdيحتوي على فئة أو سمة ، وما إلى ذلك ، حتى أتمكن من الحصول على HTML أو اللون أو القيمة ، ولكن في AngularJS ، سوف تجد نفسك تفكر على هذا النحو: ما هو النموذج الذي أتعامل معه ، سأقوم بتعيين قيمة النموذج إلى حقيقة. لا تضايق نفسك إذا ما كان العرض الذي يعكس هذه القيمة هو مربع محدد أو يوجد في tdعنصر (التفاصيل التي تحتاج إلى تفكيرك فيها عادةً في jQuery).

ومع معالجة DOM في AngularJS ، تجد نفسك تضيف توجيهات وفلاتر ، والتي يمكنك اعتبارها كإضافات HTML صالحة.

شيئًا آخر ستختبره في AngularJS: في jQuery الذي تتصل به وظائف jQuery كثيرًا ، في AngularJS ، ستقوم AngularJS بالاتصال بوظائفك ، لذا ستقوم AngularJS "بإخبارك بكيفية القيام بالأشياء" ، ولكن الفوائد تستحق ذلك ، لذلك تعلم AngularJS يعني عادةً معرفة ما تريده AngularJS أو الطريقة التي تتطلب AngularJS من خلالها تقديم وظائفك وسوف تسميها وفقًا لذلك. هذا هو أحد الأشياء التي تجعل AngularJS إطارًا بدلاً من مكتبة.


أجد هذا السؤال مثيرًا للاهتمام ، لأن أول تعرض جدي لبرمجة جافا سكريبت كان Node.js و AngularJS. لم أتعرف على jQuery أبداً ، وأعتقد أن هذا أمر جيد ، لأنني لا أضطر إلى إلغاء أي شيء. في الواقع ، أتجنب بنشاط حلول jQuery لمشاكلي ، وبدلاً من ذلك ، ابحث فقط عن طريقة AngularJS لحلها. لذا ، أعتقد أن إجابتي على هذا السؤال ستختفي أساسًا ، "فكر كمن لم يتعلم jQuery أبدًا" وتجنب أي إغراء لإدراج jQuery مباشرة (من الواضح أن AngularJS يستخدمه إلى حد ما خلف الكواليس).


انهم التفاح والبرتقال. أنت لا تريد مقارنتها. انهم شيئين مختلفين AngularJs يحتوي بالفعل على jQuery lite الذي يتيح لك تنفيذ معالجة DOM الأساسية بدون حتى تضمين الإصدار jQuery المنفوخ بالكامل.

jQuery هو كل شيء عن التلاعب DOM. فهو يحل جميع آلام المستعرض المتبادل وإلا فسيتعين عليك التعامل معه ، ولكنه ليس إطارًا يسمح لك بتقسيم تطبيقك إلى مكونات مثل AngularJS.

والشيء الجميل في AngularJs هو أنه يسمح لك بفصل / عزل معالجة DOM في الأوامر. هناك توجيهات مضمنة جاهزة للاستخدام مثل ng-click. يمكنك إنشاء توجيهات مخصصة خاصة بك والتي ستحتوي على جميع المنطق الخاص بمنظورك أو التلاعب بـ DOM حتى لا ينتهي بك الأمر إلى رمز التلاعب في DOM في وحدات التحكم أو الخدمات التي ينبغي أن تهتم بمنطق الأعمال.

Angular يكسر تطبيقك إلى - وحدات التحكم - الخدمات - المشاهدات - وما إلى ذلك

وهناك شيء آخر ، هذا هو التوجيه. إنها سمة يمكنك إرفاقها بأي عنصر DOM ويمكنك أن تذهب إلى المكسرات باستخدام jQuery بداخله دون القلق من أن jQuery الخاص بك يتعارض مع مكونات AngularJs أو يتعارض مع بنيته.

سمعت من لقاء حضرته ، قال أحد مؤسسي Angular أنهم عملوا بجد لفصل تلاعب DOM لذا لا تحاول تضمينهم مرة أخرى.


في الواقع ، إذا كنت تستخدم AngularJS ، فأنت لست بحاجة إلى jQuery بعد الآن. AngularJS نفسها لديها الربط والتوجيه ، وهو "بديل" جيد جدًا لمعظم الأشياء التي يمكنك القيام بها باستخدام jQuery.

عادة ما أقوم بتطوير تطبيقات الهاتف المحمول باستخدام AngularJS و Cordova . الشيء الوحيد المطلوب من jQuery هو المختار.

عن طريق googling ، أرى أن هناك وحدة اختيار مستقل jQuery هناك. انها Sizzle.

وقررت إنشاء مقتطف شفرة صغير يساعدني على بدء موقع ويب بسرعة باستخدام AngularJS مع قوة jQuery Selector (باستخدام Sizzle).

لقد شاركت رمز بلدي هنا: https://github.com/huytd/Sizzular





angularjs