⏳ ♨️ 👨🏼‍🎤 أبنية الواجهة الأمامية الحديثة (الجزء 2) 🐕 🕡 🖐🏽

الجزء الثاني من مقالة " معماريات الواجهة الأمامية المعاصرة " ، والتي تناقش بنية الواجهة الأمامية من حيث توزيع تدفقات البيانات. ابدأ هنا

التنفيذ

خوارزميات تم إنشاؤها بواسطة DOM (خوارزميات مملوءة بـ DOM)

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

لا أعتقد أن هذا كان مقصودًا ، لكن jQuery قد بسَّط واجهة برمجة تطبيقات DOM إلى حد أنه كان من الصعب تمييزه عن واجهات برمجة التطبيقات المعتادة للغة البرمجة. وهذا بدوره سمح للمطورين بخلط حرفيا مستوى DOM API ( عرض ) بمنطق الأعمال ( النموذج ).

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

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

Backbone.js - MV *

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

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

أما بالنسبة لـ Backbone ، فلا يوجد جهاز تحكم فيها. إذن ما هذا؟ هل هو MVC أو MVP أو MVVM؟ بالاستعانة بتعريف خادم MVC ، يتحكم جهاز التحكم في مسؤوليتين ، وهما: الاستجابة لإجراءات المستخدم في شكل طلبات HTTP الواردة والتحكم في النموذج لإنشاء العرض (صفحة HTML). في حالة Backbone ، يتم تقاسم هذه المسؤوليات بين View و Router . لكن المفهوم المستقل للمراقب أو المقدم مفقود.

, Backbone — MVP, View Presenter, Template — View, Model Collection Model.

, Backbone - . , Backbone MVC, MVP. , .

هذه هي الطريقة التي يولد بها MV * أو Model-View-Whatever ("مهما كان"). لإجراء مناقشة تفصيلية ، يوصى بشدة بالاطلاع على مدونة Addi Osmani.

مقارنةً بـ jQuery السابق ، ساعدت Backbone في إنشاء تعليمات برمجية أكثر تنظيمًا.

في وقت سابق من هذه المقالة ، دعوت Backbone الحل التطوري التالي. والسبب هو أنه قام ببساطة بتمديد MVC من جانب الخادم لاستكماله. على سبيل المثال ، إذا كان خادمنا RESTful ويشير ضمنيًا إلى أن رمز الواجهة الأمامية هو مجرد وسيلة لتمثيل النموذج على جانب الخادم ، فإن Backbone تم تكوينه مسبقًا للمزامنة مع API:

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

Knockout.js - ربط البيانات للواجهة الأمامية

Knockout.js هو أحدث مثال على استخدام القوالب الأساسية. ويهدف إلى تنفيذ MVVM - Model-View-ViewModel لـ JavaScript. وهو كذلك. بينما تتعامل Backbone مع مشكلة التنظيم وبنية الكود ، فإن Knockout هو تطبيق فعال لمستوى العرض باستخدام ربط البيانات التعريفي . مزايا الارتباطات التعريفية هي نفسها كما هي الحال مع أي بنيات برمجة تعريفية:

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

في حين أن Knockout يوفر بنيات محددة جيدًا للعرض و ViewModel ، فإنه لا يقول أي شيء حول ما يجب أن يكون عليه نموذج التطبيق. وهذا يجعل Knockout شديد التركيز ومتعدد الاستخدامات ، حيث يمكن استخدامه كمكتبة بدلاً من إطار. من تجربتي الخاصة ، رأيت أنه تم استخدامه لإنشاء تطبيقات SPA مصغرة ، حيث يتكون تطبيق الويب من عدة صفحات ، وكل صفحة عبارة عن تطبيق Knockout صغير. تحدد هذه الإجابة على StackOverflow نطاق MVVM في Knockout بوضوح.

غالبًا ما يُفترض أنه مع الطراز ، يكون Knockout في جانب الخادم. يطلب ViewModel ببساطة نموذجًا من جانب الخادم باستخدام Ajax أو ما يعادله.

يحل Knockout محل jQuery وحلول النماذج مثل المقاود لتحديثات DOM ، ولكنه لا يزال يستخدم jQuery للرسوم المتحركة وأياكس والمرافق الأخرى. بالاشتراك مع Backbone ، يمكن أن يكون بمثابة التنفيذ الكامل لقالب MVVM. من الناحية النظرية ، يمكن أن يحدث هذا ، ولكن قبل أن يحدث هذا ، تم تطوير هذه المفاهيم بالفعل في أدوات الجيل التالي.

هنا تبدأ الحركة الثورية لـ Angular 1 ، Aurelia ، Ember.js ، إلخ.

نظرًا لارتباطه الوثيق بالعالم .NET ، فقد تم استخدام Knockout على نطاق واسع في تطبيق ASP.NET MVC. مثل العمود الفقري ، كان حلًا تطوريًا آخر لمشكلة مختلفة قليلاً. ومرة أخرى ، لم يتغير الافتراض القائل بأن الكود من جانب العميل هو ببساطة امتداد لنمط MVC من جانب الخادم. كان الخادم لا يزال هو العمارة السائدة.

تعد كل من Knockout و Backbone مكتبات JavaScript. بطريقة أو بأخرى ، كان ينظر إلى العمود الفقري كإطار. لماذا ا؟ لا توجد إجابة محددة ، ولكن ربما كان ذلك في المنظور. يتم دائمًا التعامل مع العمود الفقري مع مستوى تجريد أعلى بسبب تركيزه على بنية الكود. علاوة على ذلك ، لم يكن المقصود من Backbone أبدًا استبدال jQuery في كل مكان (حتى في عام 2019 ، يستخدم 70٪ من أفضل 10،000،000 موقع ويب jQuery) ، بينما يتداخل Knockout مع جوهر jQuery ، أي معالجات DOM ، والتي تعقد بشكل طبيعي Knockout. وبالتالي ، كان تكيف Knockout محدودًا مقارنة بالعمود الفقري. لكنها كانت لا تزال واحدة من أولى تطبيقات ربط البيانات التعريفية لمجتمع الواجهة الأمامية ، وتستحق ذكرًا خاصًا.

الزاوي 1 - أعطني السيطرة

ما فعله jQuery مع DOM ، فعل Angular 1 مع النظام البيئي للواجهة الأمامية ككل. هذا غيّر إلى الأبد فكرة إنشاء تطبيقات العميل على نطاق واسع. قدم العديد من المفاهيم كأساس - نظام معياري ، حقن التبعية ، عكس التحكم ، ربط أسهل للبيانات ، إلخ.

كانت آنذاك وستظل الآن مهمة صعبة لاختيار مكتبات جافا سكريبت المناسبة وإنشاء مجموعة التكنولوجيا المثالية للواجهة الأمامية. زوّدت Angular 1 بديلاً أبسط ولكن أكثر تماسكًا. يمكن قول الشيء نفسه عن Ember.js وأنظمة أخرى مماثلة ، لكن قابلية تطبيق Angular 1 كانت على مستوى نوعي مختلف عن بدائلها في ذلك الوقت.

Angular 1 هو حل ثوري بمعنى أنه يشير بوضوح إلى الابتعاد عن فكرة ملحق MVC البسيط من جانب الخادم مع رمز من جانب العميل مبعثر عبر الصفحات. جعلت Angular 1 SPA من الدرجة الأولى ، وهو حل فعلي تقريبًا لخلق تجربة مستخدم من الجيل التالي.

الإطار أو المكتبة؟

كانت الحلول السابقة مكتبات أكثر من إطار. الزاوية 1 هي بلا شك بنية محددة جيدًا. عامل التمييز الضروري بين النظام الأساسي والمكتبة هو IOC - Inversion of Control. علاوة على ذلك ، لتصنيف Angular 1 كإطار ، يمكننا ملاحظة:

MVVMs محددة جيدًا: الزاوي 1 يحتوي على كائنات واضحة من طراز ، عرض ، و ViewModel.
(DI): Angular 1 DI, Model. Angular 1 (Service). , .
(data binding) : , . , MVVM. . (Angular 1 ). . . MVC. , .
النظام المعياري: يقدم Angular 1 نظامًا معياريًا خاصًا بالإطار. الوحدات هي الأساس لتنظيم التعليمات البرمجية لكل لغة تقريبًا. لم يكن لدى JavaScript نظام معياري حتى عام 2015 (لم تدعمه المتصفحات حتى عام 2018). Angular متقدم جدًا على وقته من حيث التنظيم.

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

تضارب مساحة الاسم: على الرغم من أن DI كان رائعًا ، فقد تم تنفيذه باستخدام نمط محدد مواقع الخدمة الذي استخدم مساحة الاسم العامة. هذا جعل بادئة الخدمات إلزامية تقريبا.
. , , , . React . -, .
. , Angular 1, . , Angular 1 $scope, ViewModel, Controller, $scope. , VMFactory . , Angular 1 , .

كانت هناك العديد من القضايا الثانوية الأخرى. Angular 2 ، أو مجرد Angular ، كان اختراقاً كاملاً لدرجة أنه بدا كإطار جديد بالكامل. لا أجد شيئًا مشتركًا بينهما ، باستثناء الاسم وبعض المفاهيم.

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

عاش Angular 1 طويلًا ولا يزال يعيش بين مجتمع الواجهة الأمامية. مع كل إيجابياتها وسلبياتها ، ساعدت المجتمع على فهم أهمية بنية البرمجيات وقدمت الأساس لكتابة تطبيقات قابلة للتطوير. أصبحت عيوبها ونواقصها الأساس لحل المشاكل للهياكل المستقبلية.