الخروج من سبا الأرنب حفرة مع القضبان الحديثة

TL ؛ DR: ممر SPA مظلمة ومليئة بالرعب. يمكنك محاربتهم بلا خوف ... أو اختيار مسار آخر يقودك إلى المكان الصحيح: Rails الحديث.



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

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

أرنب SPA حفرة

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

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

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

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

بالنسبة للخادم:

• واجهة برمجة تطبيقات تلبي احتياجات بيانات عميلك
• نظام تسلسل JSON لتبادل البيانات مع العميل ونظام التخزين المؤقت الذي يدعم ذلك

لعميل JavaScript الجديد:

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

باختصار ، مع SPA سيكون لديك تطبيق آخر للحصول على الدعم. ومجموعة جديدة من المشاكل لحلها. ولاحظ أنه لا يمكنك استبدال تطبيق بآخر. لا تزال بحاجة إلى تطبيق الخادم (الآن سيعرض JSON بدلاً من HTML).

إذا لم يسبق لك أن عملت مع SPA ، يمكنك الاستهانة بالصعوبات التي ستواجهها. أعرف هذا لأنني ارتكبت نفس الأخطاء في الماضي. تقديم JSON؟ يمكنني التعامل معها. نموذج كائن مجال غني في JavaScript؟ هذا يبدو مضحكا. وأنت تعرف أن هذا الإطار سيحل كل هذه المشاكل. كعكة رائعة!

خطأ.

API وتبادل البيانات.

يعد التواصل بين التطبيق الجديد والخادم مشكلة معقدة.

هناك قوتان متعارضتان:

• ستحتاج إلى إجراء أقل عدد ممكن من طلبات الخادم لتحسين الأداء.
• يعد تحويل سجل واحد إلى JSON أمرًا بسيطًا. لكن خلط نماذج كبيرة من السجلات المختلفة لتقليل عدد الاستعلامات ليس على الإطلاق. ستحتاج إلى تطوير منطق التسلسل بعناية لتحسين عدد استعلامات قاعدة البيانات والحفاظ على الأداء على المستوى.

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

قد تساعد بعض المعايير هنا. واجهة برمجة تطبيقات JSON لتوحيد تنسيق JSON ؛ أو GraphQL ، لتحديد البيانات الضرورية فقط ، كما هو معقد على النحو المطلوب ، في استعلام واحد. ولكن لن ينقذك أحد منهم من:

• وضع كل تبادل للبيانات
• تنفيذ الاستعلامات لتحديد البيانات بكفاءة على الخادم

ويمثل هذان الجانبان قدرًا كافيًا من العمل الإضافي.

وقت التمهيد

اعتاد الناس على ربط سبا مع السرعة ، ولكن الحقيقة هي أن حملهم بسرعة ليس بالأمر السهل. هناك أسباب عديدة لذلك:

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

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

على سبيل المثال ، يتميز Discourse ، وهو سبا قائم على Ember ، بأوقات تحميل رائعة ، ولكن من بين أمور أخرى ، يقومون بتحميل كمية كبيرة من بيانات JSON مسبقًا كجزء من HTML الأولي حتى لا يقوموا بتقديم طلبات إضافية. وألاحظ أن فريق الخطاب مجنون بالمعنى الجيد للسرعة ومهاراتهم أعلى بكثير من المتوسط. فكر في الأمر قبل أن تتمكن من إعادة إنتاجه بسهولة في SPA.

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

يتطلب هذا الأسلوب تشغيل وقت تشغيل JavaScript على الخادم ، كما أنه لا يخلو من مشاكل فنية. على سبيل المثال ، يجب على المطورين النظر في أحداث تحميل SPA عند تغير عملية التحميل.

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

- الخادم: طلب خادم API
- الخادم: استعلام قاعدة البيانات
- الخادم: إنشاء JSON
- الخادم: تحويل JSON إلى HTML
- العميل: عرض HTML الأولي
- العميل: تنزيل SPA
- العميل: تحليل HTML الأولي والاشتراك في أحداث DOM

هل يمكنك طلب البيانات من قاعدة البيانات وإنشاء HTML وبدء العمل؟

هذا ليس عدلاً تمامًا ، لأنك لن تكون SPA ولأن معظم هذا السحر مخفي وراء الإطار ، ولكن لا يزال يبدو لي خطأ.

العمارة

إن تطوير التطبيقات بواجهة مستخدم غنية أمر صعب. هذا كله لأن هذه هي إحدى المشاكل التي ألهمت ظهور نهج موجه للكائنات والعديد من أنماط التصميم.

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

من الناحية العملية ، إذا بدأت في كتابة JavaScript في أجزاء صغيرة لتحسين التفاعل ، فسيتعين عليك في SPA أن تكتب الكثير من كود JavaScript الإضافي. هنا يجب عليك التأكد من أنك تفعل كل شيء بشكل صحيح.

هناك العديد من البنيات المختلفة مثل هياكل SPA:

• تختلف معظم أطر العمل عن قالب MVC التقليدي. استلهمت Ember في البداية من Cocoa MVC ، لكنها غيرت نموذجها البرمجي كثيرًا في الإصدارات الحديثة.
• هناك ميل إلى أن المطورين يفضلون المكونات بدلاً من الفصل التقليدي لوحدة التحكم والعرض التقديمي (انتقلت بعض الأطر ، مثل Ember و Angular ، إلى هذا النهج في الإصدارات الحديثة). تقوم جميع الأطر بتنفيذ نوع من ربط البيانات أحادية الاتجاه. لا يُحبط الربط على الوجهين بسبب الآثار الجانبية التي قد يساهم بها.
• تتضمن معظم الأطر نظام توجيه يسمح لك بتعيين عناوين URL والشاشات ، ويحدد كيفية إنشاء مكونات للعرض. هذا هو نهج ويب فريد من نوعه لا يوجد على واجهات سطح المكتب التقليدية.
• تفصل معظم الأطر قوالب HTML عن كود JavaScript ، ولكن React يمزج بين إنشاء HTML و JavaScript ويقوم بذلك بنجاح كبير ، نظرًا لاستخدامه على نطاق واسع. هناك أيضًا ضجيج حول تضمين CSS في JavaScript. لقد أثر Facebook ، بهندسته Flux ، إلى حد كبير على الصناعة ، كما تأثرت بشدة حاويات مثل Redux ، vuex ، إلخ.

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

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

أخيرًا ، لا يمكنني تحمل مزيج HTML و CSS في المكونات المليئة بمنطق JavaScript. أفهم ما هي المشكلة التي يحلها هذا ، لكن المشاكل التي يجلبها هذا النهج لا تجعلها تستحق العناء.

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

تكرار الرمز

عند العمل مع SPA ، قد تواجه ازدواجية في التعليمات البرمجية.

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

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

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

يمكنك المراهنة على أنك لست بحاجة إلى نموذج غني في SPA الخاص بك وأنك ستعمل بدلاً من ذلك مع كائنات JSON / JavaScript مباشرةً ، لتوزيع المنطق عبر مكونات واجهة المستخدم. الآن لديك نفس تكرار الرمز الممزوج برمز واجهة المستخدم ، حظًا موفقًا في ذلك.

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

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

الهشاشة

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

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

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

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

التحديات التنظيمية

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

ربما يكون هذا تحديًا أكثر أهمية لشركتك مما تعتقد. يشجع نهج SPA فرق عالية التخصص بدلاً من فرق من اختصاصيي:

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

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

قد يكون هذا التخصص مثاليًا لـ Facebook أو Google وفرقهم المكونة من عدة طبقات من القوات الهندسية. ولكن هل سيكون جيدًا لفريقك المكون من 6 أشخاص؟

القضبان الحديثة

هناك 3 أشياء تدخل في Rails الحديثة التي يمكن أن تغير رأيك بشأن تطوير تطبيقات الويب الحديثة:

• واحد منهم هو Turbolinks وهذا انفجار دماغي
• والآخر هو صديق قديم تم تجاوزه اليوم: ردود SJR وطلبات AJAX البسيطة للعرض
• وآخر واحد تمت إضافته مؤخرًا: التحفيز

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

الارتباطات

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

مستوحاة Turbolinks من pjax ومرت بالعديد من المراجعات.

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

لا أعتقد أن Turbolinks مدهش بكل بساطة مع حداثة (pjax - 8 years). أو تطوره الفني. يدهشني كيف يمكن لفكرة بسيطة أن تزيد من إنتاجيتك حسب الحجم مقارنةً بالبديل عن SPA.

دعني أسلط الضوء على بعض المشكلات التي يتم إصلاحها:

• تبادل البيانات. ليس لديك ذلك. لا حاجة إلى إجراء تسلسل JSON أو إنشاء واجهات برمجة التطبيقات أو التفكير في طلبات البيانات التي تلبي احتياجات العملاء من حيث الأداء.
• الحمل الأولي. على عكس SPA ، يحفز هذا النهج أوقات التحميل السريع (حسب التصميم). لعرض الشاشة ، يمكنك الحصول على البيانات التي تحتاجها مباشرة من قاعدة البيانات. HTML — .
• : JavaScript-. , SPA.

MVC , , Rails , , , : , HTML .

, , : , ( SPA). .

• . , . , , .. .
• . SPA, JavaScript , . , , , .

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

بالطبع ، Turbolinks ليست رصاصة فضية خالية من المتاعب. المشكلة الأكبر هي أنه يمكنه كسر كود JavaScript الحالي:

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

عرض AJAX وإجابات SJR

هل تذكر عندما كان عرض HTML من خلال Ajax شائعًا قبل 15 عامًا؟ خمن ماذا؟ لا تزال هذه أداة رائعة في ترسانتك:

• HTML DOM, ( 100 ).
• HTML , .

, Basecamp, , :



. JSON . , Rails.

, Rails , — JavaScript (SJR). Ajax ( ) JavaScript, . , AJAX- HTML-: , , .

يمكنك أن ترى كيف يحدث هذا إذا ذهبت إلى Basecamp وحاولت إنشاء مهام جديدة. بعد النقر على "Add todo" ، سيحفظ الخادم المهام ويستجيب بجزء JavaScript يضيف مهام جديدة إلى DOM.

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

التحفيز

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

• يستخدم MutationObserver لربط السلوك بـ DOM ، مما يعني أنه لا يهمه كيف يظهر HTML على الصفحة. بالطبع ، هذا يعمل بشكل رائع مع Turbolinks.
• سيوفر لك الكثير من التعليمات البرمجية المتداخلة لإرفاق السلوك بـ DOM ، ولإرفاق معالجات الأحداث بالأحداث ، ولوضع العناصر في الحاوية المحددة.
• ويهدف إلى جعل كود HTML الخاص بك مقروءًا ومفهومًا ، وهو أمر جيد إذا واجهت مشكلة اكتشاف أي جزء من JavaScript يعمل على هذا العنصر الملعون.
• DOM. , , , HTML, , Turbolinks.

Rails-, JavaScript HTML-, , (c JavaScript). Stimulus . SPA , .

Stimulus , . , - . -, : -, .

يُباع Turbolinks عادةً على أنه "احصل على جميع مزايا SPA دون أي إزعاج". لا أعتقد أن هذا صحيح تمامًا:

• تبدو التطبيقات التي تم إنشاؤها باستخدام Rails الحديثة سريعة ، ولكن لا يزال SPA يستجيب بشكل أسرع للتفاعلات المستقلة عن الخادم.
• هناك سيناريوهات يكون فيها SPA أكثر منطقية. إذا كنت بحاجة إلى تقديم مستوى عالٍ من التفاعل ، فأنت بحاجة إلى إدارة عدد كبير من الحالات ، وتنفيذ منطق معقد من جانب العميل ، وما إلى ذلك. إطار عمل SPA سيجعل حياتك أسهل.

الآن التنمية هي لعبة حل وسط. وفي هذه اللعبة:

• تتيح لك Modern Rails إنشاء تطبيقات سريعة بما يكفي وتبدو رائعة.
• بالنسبة لمجموعة متنوعة كبيرة من التطبيقات ، يتيح لك تطبيق Rails تنفيذ نفس الوظائف برمز أقل وتعقيد أقل.

أعتقد أنه مع Rails ، يمكنك الحصول على 90٪ مما يقدمه SPA بجهد 10٪. من حيث الأداء ، ريلز يقتل سبا. بالنسبة إلى UX ، أعتقد أن العديد من المطورين يرتكبون نفس الخطأ الذي ارتكبته ، على افتراض أن SPA UX غير مسبوق. الأمر ليس كذلك. في الواقع ، كما نوقش أعلاه ، من الأفضل أن تعرف ما تفعله عند إنشاء SPA ، أو UX سيكون في الواقع أسوأ.

الخلاصة

, SPA , , SPA. , « », , , SPA, .

, , SPA . , , . , SPA-, Rails- , , .

, :



, , . , , , .

, . . , -, — .

, . SPA, , . , . , Facebook Google, , , , , .

Rails, Rails , . , .