مجموعة AHA: Astro وhtmx وAlpine › نظرة عامة على الحزمة 1 / 24 التالي

نظرة عامة على الحزمة

لمن هذا الكتاب؟

قسم بعنوان “لمن هذا الكتاب؟”

مناسب تمامًا لمطوّري الواجهة الأمامية (frontend) الذين يعرفون React / JSX ويريدون تجربة تطوير (DX) مماثلة، ويريدون كذلك بلساطة أكبر بكثير في حياتهم، عبر توليد HTML على الخادم وكتابة أقل قدر ممكن من شيفرة JavaScript في جهة العميل (client-side JavaScript).

ما هي؟

قسم بعنوان “ما هي؟”

حزمة AHA (AHA Stack) مبنيّة على التقنيات الأساسية للويب:

  • HTTP
  • HTML
  • CSS
  • JavaScript
  • خوادم الويب
  • متصفّحات الويب
  • نموذج المستند (DOM)
  • أحداث المتصفّح
  • النماذج و FormData
  • XHR و fetch() و Request و Response
  • ملفات تعريف الارتباط (Cookies)

هذه هي التقنيات التأسيسية التي تُشغّل الويب. ومجتمعةً تصبّ في ما نسمّيه منصّة الويب (Web Platform). إنها بوصلةنا التي نتّجه إليها. معايير صناعة. ثابتة لا تتغيّر.

لن تتغيّر أبدًا، فهي صمّة كالصخر، تعمل كما هي، ولا تمرّ أبدًا بإصدار «2.0» يكسر التوافق، لأن ذلك ببساطة لا يحدث.

وهذه التقنيات توفّر:

  • لغة تُنشئ واجهات المستخدم تصريحيًا (HTML)
  • لغة تُنسّق واجهات المستخدم تصريحيًا (CSS)
  • وسيلة تتيح للعملاء طلب البيانات من خادم (HTTP)
  • وسيلة تُرسل البيانات من عميل إلى خادم (XHR / fetch)

لكن ذلك لا يكفي لبناء تطبيقات الويب الحديثة. فنحن بحاجة إلى شيء إضافي. شيء فوق هذه الأوليات، يجعل حياتنا أسهل، ويساعدنا على بناء التطبيقات.

هنا تحديدًا تأتي حزمة AHA إلى الصورة، وهي تقدّم بعض الأشياء التي يمكنها أن تُنمّي تجربة تطوير الويب (Web Development)، ونوع التطبيقات التي يمكننا بناؤها.

ينبغي أن نستعمل المنصّة بقدر ما نستطيع، دون إعادة اختراع أي شيء، حتى نستفيد من كل التقنيات التي يوفّرها لنا الويب.

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

فهذه هي الفكرة.

نقدّم مكتبة (library) تسهّل إدارة اتصالات HTTP مع خوادمنا. عندما يقوم المستخدم بفعل معيّن يستدعي إجراءً على الخادم، تنشئ هي الطلب، وتحصل على HTML في المقابل، وتحقن هذا HTML مباشرةً في جزء من الصفحة.

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

ونفعل ذلك بطريقة تصريحية (declarative)، لا بكتابة شيفرة JavaScript أمرية تُملي على الصفحة ما تفعله، بل نرتفع مستوىً من التجريد (abstraction) ونصرّح بما نريده منها أن تفعله.

ينبغي أن تسمح لنا المكتبة بإرسال أيّ طريقة HTTP (HTTP method) إلى الخادم، سواء كانت POST أو GET أو DELETE أو PUT أو PATCH.

ثمّ نحتاج وسيلة لتقديم صفحات HTML عبر HTTP، أي خادم ويب (Web Server) بعبارة أخرى. لا جديد هنا. نستعمل خادم الويب لبناء تطبيق متعدّد الصفحات (Multi Page Application) بدل تطبيق صفحة واحدة (Single Page Application). خادم ويب يستطيع التعامل مع العرض على الخادم (server-side rendering)، والتواصل مع قاعدة بيانات لجلب البيانات (وتخزينها). كل ما تحتاجه هذه الأداة هو القدرة على التعامل مع استجابات HTTP، والتواصل مع قاعدة بيانات عند الحاجة، والردّ بصفحات HTML كاملة أو بأجزاء HTML جزئية (HTML partials).

لدينا مسارات (routes)، وكل مسار يقدّم HTML صفحةٍ ما، مُولَّدًا على الخادم.

لا يوجد أي إطار عمل بلغة JavaScript يقرّر ما يظهر في الصفحة.

خادم الويب يتولّى الأمر كله. على الطراز القديم.

مع تطبيق صفحة واحدة «خالص» (pure Single Page Application)، نحصل على صفحة بلا جسم HTML يُرسَل إلى المتصفّح، ويرتبط بها شيء من شيفرة JavaScript. تُنزَّل الشيفرة، وتعمل حين تكون جاهزة، ثمّ تجلب بعض البيانات من الخادم على هيئة JSON، وأخيرًا تبني التطبيق الصفحةَ باستخدام واجهة DOM البرمجية (DOM API).

أطر الميتا (meta-frameworks) ومكتبات التوجيه (routing) تساعد عادةً على توليد الصفحة ديناميكيًا على الخادم، فتُرسِل HTML أوّليًا إلى العميل، ولا تُعالَج إلّا التنقّلات اللاحقة في جهة العميل. وماذا يحدث في هذه الحالة؟ النقر على رابط يُطلق طلبًا إلى الخادم لاسترجاع الصفحة الجديدة، عادةً في صورة ملف JavaScript إذا كان إطار الميتا يفصل كل صفحة في ملف JavaScript مختلف، أو نحصل على البيانات التي نحتاجها بصيغة JSON، فيعالجها التطبيق الموجود في جهة العميل (client-side) ويستخدمها لتوليد واجهة المستخدم (UI) عبر واجهة DOM البرمجية.

في الحالتين تكون شيفرة JavaScript تفعل أكثر بكثير ممّا ينبغي.

ما تفعله حزمة AHA هو أنها تعتمد على الخادم بدرجة أكبر بكثير. نحمّل الصفحة الأوّلية التي نطلبها من الخادم. ننقر على رابط؟ نحمّل صفحةً جديدة من الخادم. لا وجود لتطبيق JavaScript كبير في جهة العميل يقرّر كيف ينبغي أن تبدو الصفحة.

هكذا كان الويب المفترض أن يعمل (وهو ما زال؟). لا حاجة إلى مصارعة إطار العمل لإداء أمور الويب الأساسية. كل شيء يعمل ببساطة.

عندما نحتاج إلى وظائف أقرب إلى ما يقدّمه التطبيق، نضيف ما يُسمّى «رشّات JavaScript تفاعلية» (JavaScript sprinkles of interactivity). ونفعل ذلك بالطبع بـ JavaScript، للسبب الذي أُنشئت من أجله في المقام الأول. ويمكنك أن تفعل ذلك بشيفرة JavaScript بسيطة «خام» (vanilla)، أو باستعمال مكتبة تساعدك على إدارتها.

في نهاية المطاف، نضيف أداتين فوق منصّة الويب، من أجل:

  1. أن نجعل إنشاء التواصل بين العميل والخادم سهلًا
  2. أن نضيف تفاعلية جهة العميل (client-side interactivity) إلى كل صفحة

سينتج عن ذلك أن نتخلّص بسهولة من تعقيد أُطر تطبيقات الصفحة الواحدة (SPA) المبنيّة على أسلوب «DOM افتراضي» (virtual DOM)، ونبني تطبيقات أفضل وأسهل صيانةً وأسرع.

أقترح مجموعة أدوات «AHA»: Astro و htmx و Alpine.js.