استخدام Response_to للتدهور الرشيق باستخدام Ajax في RoR 2.x
-
02-07-2019 - |
سؤال
كنت أتصفح كتاب AWDR حول تطوير الويب باستخدام Ruby on Rails وكانت إحدى المشكلات المتعلقة بالرمز القديم هي عدم استخدام Response_to للتأكد من أن العرض المستخدم هو عرض JavaScript.الآن في بعض الأمثلة المحدثة، رأيت أشخاصًا يذكرون ذلك لاحقًا، عند تنفيذ التدهور الرشيق، استخدم request.xhr؟لمعرفة ما إذا كان المستخدم قد قام بتمكين جافا سكريبت، وإذا لم يكن الأمر كذلك، فسيقوم بإعادة توجيه المستخدم.
كنت أتساءل إذا كان بإمكانك استخدام Response_to للحصول على نفس السلوك، وإذا كان الأمر كذلك، فهل يعتبر هذا نموذجًا جيدًا أم لا ولماذا؟
إذن ما أفكر في القيام به هو شيء مثل:
def function
respond_to do |format|
format.js do
basic_stuff
end
format.html do
basic_stuff
user_redirect
end
end
end
يبدو أنه ينتهك مبدأ DRY نوعًا ما، وربما أفتقد شيئًا ما حول كيفية تفاعل المستخدم والخادم هنا.لأكون صادقًا، لم توضح لي وثائق واجهة برمجة التطبيقات (API) الأمر تمامًا.
المحلول
حسنًا، يمكنك إعادة البناء على النحو التالي:
def function
basic_stuff # executed regardless of the mime types accepted
respond_to do |format|
format.html do
user_redirect
end
end
# will fall back rendering the default view - which you should ensure will be js
end
request.xhr?
ينظر إلى الطلب X-Requested-With
الرأس (لمعرفة ما إذا كان يحتوي على "XMLHttpRequest"). respond_to
ينظر إلى أنواع التمثيل الصامت المقبولة.
يمكنك استخدام أي منهما لتنفيذ نوع من التدهور الرشيق.
لكن لن تكون قادرًا على الاستخدام xhr?
للتدهور الرشيق ما لم تكن مكالمات ajax الخاصة بك تقوم بتعيين هذا الرأس (يقوم النموذج الأولي بذلك تلقائيًا).
علاوة على ذلك، respond_to
يعطي المزيد من المرونة أي.إرسال xml، json، js، مهما كان من نفس الكتلة.
لذا فإنني أوصي respond_to
هنا.