البحث في الموقع

أعترف بأنّي لا أمتلك خبرة كبيرة في مكتبة Webpacker الجديدة في إطار العمل Ruby on Rails، ولكنّي قرّرت الاعتماد على هذه المكتبة تمامًا والاستغناء كلّيًا عن مكتبة Sprockets للتعامل مع الأصول assets. وباعتباري أحد متّبعي مبدأ Convention Over Configuration فقد حاولت جاهدًا إيجاد الطريقة التي يمكن الاصطلاح عليها في تشييد تطبيق Webpacker. هذه المكتبة في أيامها الأولى لذا أظنّ أنّ فريق مطوري Rails لم يقوموا بهذا الأمر أيضًا، وأعتقد بأنّ مجتمع المطوّرين سيجد حلًّا لهذه المسألة قريبًا. على أي حال، إليك الطريقة التي اتبعتها في استبدال asset pipeline بـ Webpacker. إن كنت ترغب في العمل على مشروع جديد، فاستخدم الأمر: rails new blank --skip-sprockets --webpack ليتم إنشاء تطبيق Rails جديد مع الاستغناء عن مكتبة Sprockets وإضافة المكتبة Webpacker. أما لو كنت ترغب في إضافة Webpacker إلى مشروع قائم فعليك بمراجعة التوثيقات. بعد ذلك احذف بعض الجواهر gems والتي لم نعد بحاجة إليها من ملف Gemfile، وهي sass-rails، uglifier و coffee-rails. كذلك يمكنك التخلص من المجلد app/assets لأنّنا لم نعد بحاجة إليه بعد الآن. لنلق نظرة في البداية على محتويات ملف application.js الذي يتم إنشاؤه افتراضيًّا بواسطة Webpacker. /* eslint no-console:0 */ // This file is automatically compiled by Webpack, along with any other files // present in this directory. You're encouraged to place your actual application logic in // a relevant structure within app/javascript and only use these pack files to reference // that code so it'll be compiled. // // To reference this file, add <%= javascript_pack_tag 'application' %> to the appropriate // layout file, like app/views/layouts/application.html.erb console.log('Hello World from Webpacker') تشير التعليقات الواردة في هذا الملف إلى أن المجلد app/javascript/packs هو نقطة الولوج entry point إلى الحزم المستخدمة في التطبيق، وأنّ عليك وضع التطبيق الحقيقي في المجلد app/javascript. ترتيب الملفّات والمجلّدات لقد نظّمت تطبيق Webpacker الخاصّ بي كما هو موضح أدناه، والتطبيق يحمل اسم blog. سترى أنّي قد أدرجت تطبيق JavaScript الحقيقي في المجلد app/javascript/blog بدلًا من app/javascript ولم أقم بذلك اعتباطًا. أولًا: يعني هذا أن بمقدوري إضافة العديد من التطبيقات إلى المشروع الواحد وحسب الحاجة، بدلًا من تكديس جميع الشيفرات جنبًا إلى جنب. ثانيًا: ستتيح لي هذه الطريقة امتلاك نقطة ولوج حقيقية للحزم وهذا ما سأوضّحه الآن. blog +-- app | +-- javascript | | +-- blog | | | +-- fonts | | | +-- images | | | +-- styles | | | +-- index.js | | +-- packs | | | +-- application.js لنلق نظرة الآن إلى ملف app/javascript/packs/application.js وهو نقطة الولوج إلى حزمتي، وهو ملفّ بسيط للغاية: import 'blog'; سيتم استيراد التطبيق وتشغيل الملف app/javascript/blog/index.js والذي سيصبح نقطة الولوج إلى تطبيق JavaScript الخاصّ بي. بهذه الطريقة أحافظ على نقطة الولوج بسيطة قدر الإمكان أما ما تبقى من الشيفرة فيكون ضمن التطبيق. جدير بالذكر كذلك أنّك لست ملزمًا بتسمية المجلد - والملفّ - باسم blog، بل يمكنك استخدام أي اسم تشاء، ولكنّني توخيت تبسيط الأمور بجعل اسم المجلد مطابقًا لاسم تطبيق Rails. والآن سنستخدم javascript_pack_tag للإشارة إلى تطبيقنا. javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' مرحلة التطوير عند العمل في بيئة التطوير Development استخدم الأمر bin/webpack-dev-server وستتمّ مراقبة التطبيق وإعادة بنائه عند الحاجة، وإرسال التعديلات إلى المتصفّح. وبعد أن يصبح التطبيق جاهزًا للتجميع Compile يمكن استدعاء الأمر bin/webpack أو rails assets:precompile، ولكن سيتولى الخادوم هذه المهمّة على الأرجح. مكتبتا Turbolinks وRails UJS إن كنت ستستخدم Turbolinks و Rails UJS في تطبيقك فعليك إعداد هاتين المكتبتين وتشغيلهما. من السهل استدعاء المكتبتين بواسطة الأمر //= require في حال كنت تستخدم asset pipline ولكن عند استخدام هاتين المكتبتين كوحدات فالأمر مختلف قليلًا. في البداية علينا تثبيت المكتبتين: yarn add rails-ujs turbolinks بعد ذلك علينا استيراد المكتبتين وتشغيلهما في ملف app/javascript/blog/index.js: import Rails from 'rails-ujs'; import Turbolinks from 'turbolinks'; Rails.start(); Turbolinks.start(); كما تلاحظ فقد اتبعنا نفس الأسلوب في استدعاء كلتا المكتبتين وتشغيلهما. متغيرات البيئة Environment Variables يمكن الوصول إلى متغيرات البيئة عبر الشيفرات الخاصة بنا بعد تجميعها. عادة ما أضيف اللاحقة .erb إلى اسم الملف ثم أنفّذ شيئًا مماثلًا لهذا: <%= ENV['X_ENV_VAR'] %> ولكن هناك طريقة أفضل، إذ يمكن تهجير المتغيرات إلى process.env وكما يلي: export const STRIPE_API_KEY = process.env.STRIPE_API_KEY; أوراق الأنماط Stylesheets يمكن وبكل بساطة استيراد ملفات CSS أو Sass التي ترغب باستخدامها في التطبيق. لقد حدّدت الملف app/javascript/blog/styles/app.scss كنقطة ولوج Sass وبهذا أبقي جميع الملفات في مجلد styles، وتصبح عملية استيرادها إلى التطبيق أمرًا سهلًا للغاية: import './styles/app.scss'; يمكن استخدام المحرّف ~ مع import وستبدأ عملية البحث عن الملف من المجلد node_modules، فلو أردت مثلًا استيراد مكتبة Bootstrap إلى التطبيق يمكنك استخدام الشيفرة التالية: @import '~bootstrap/scss/bootstrap'; الصور لا تختلف الصور عن أوراق الأنماط في شيء، إذ يجب استيرادها في البداية لتتمكن من استخدامها في التطبيق. عادة ما أضع الصور في مجلد app/javascript/blog/images ثم أنشئ ملفًّا باسم index.js في نفس المجلد وظيفته استيراد جميع الصور في المجلد. فعلى سبيل المثال: import './logo.svg'; import './menu-open.svg'; import './menu-close.svg'; عليك الانتباه إلى أنّ هذه الطريقة لن تُضمّن الصور في أوراق الأنماط، وإنما تدفعها إلى Webpacker لتكون متاحة للاستخدام في التطبيق. ويمكنك حينئذٍ استخدام الدالة المساعدة asset_pack_path في العرض للإشارة إلى هذه الملفات. فلو أردت مثلًا استخدام إحدى هذه الصور: = image_tag asset_pack_path('logo.svg') إضافة إلى ذلك يمكنك الإشارة إلى الصور في CSS أو Sass وسيتلقّفها Webpacker بصورة تلقائية. وبصورة عامة يكون مسار الجذر نقطة الولوج الخاصّة بأوراق الأنماط لذا لن تكون بحاجة إلى استخدام المسارات المطلقة. ختامًا كما شاهدت فإن الأمر يتطلب الكثير من العمل، وهذا هو الأسلوب الذي أتبعه في استخدام Webpacker الآن. حاولت البحث عن مقالات تعنى بتفصيل طريقة استخدام Webpacker ولكنّي لم أجد شيئًا يذكر في الوقت الحاضر. أنا متحمّس جدًّا لمعرفة طريقة الاستخدام القياسية لهذه المكتبة هذا في حال تمّ تحديدها في المستقبل. ترجمة - وبتصرّف - للمقال Replacing Rails Asset Pipeline with Webpacker لصاحبه Dwight Conrad Watson.

يأتي Laravel مضمّنا مبدئيًّا بالكثير من المهام الشائعة في تطوير تطبيقات الويب؛ إلا أن المطوّر يحتاج لإضافة ميزات خاصّة لإطار العمل لاستخدامها في مشروعه، وهو ما يمكن فعله في Laravel عبر الدوّال المساعِدة المخصّصة. هذا الدرس جزء من سلسلة تعلم Laravel والتي تنتهج مبدأ "أفضل وسيلة للتعلم هي الممارسة"، حيث ستكون ممارستنا عبارة عن إنشاء تطبيق ويب للتسوق مع ميزة سلة المشتريات. يتكون فهرس السلسلة من التالي: مدخل إلى Laravel 5.تثبيت Laravel وإعداده على كلّ من Windows وUbuntu.أساسيات بناء تطبيق باستخدام Laravel.إنشاء روابط محسنة لمحركات البحث (SEO) في إطار عمل Laravel.نظام Blade للقوالب.تهجير قواعد البيانات في Laravel.استخدام Eloquent ORM لإدخال البيانات في قاعدة البيانات، تحديثها أو حذفها.إنشاء سلة مشتريات في Laravel.الاستيثاق في Laravel.إنشاء واجهة لبرمجة التطبيقات API في Laravel.إنشاء مدوّنة باستخدام Laravel.استخدام AngularJS واجهةً أمامية Front end لتطبيق Laravel. الدوّال المساعدة المخصّصة في Laravel. (هذا الدرس)استخدام مكتبة Faker في تطبيق Laravel لتوليد بيانات وهمية قصدَ الاختبار. عند استخدام الدالة asset في قالب Blade فأنت تستدعي دالة مساعِدة مضمّنة في Laravel. الدوال المساعدة هي دوال مبنية لتأدية أعمال اعتيادية ويمكن غالبا استخدامها في أي ملف من إطار العمل أو التطبيق. سنشرح في هذا الدرس كيفية بناء دوال مساعدة مخصّصة. يغطي الدرس المواضيع التالية: مجلّد الدوال المساعِدة.تعريف صنف مساعِد.مزود الخدمة الخاص بالصنف المساعِد.كنية الصنف المساعد.سنستخدم نفس المشروع الذي أنشأناه في الدرس السابق لإيضاح المفاهيم الواردة في هذا الدرس. مجلد الدوال المساعدةسننشئ مجلّدا خاصّا بالأصناف التي ستعرّف الدوال المساعدة داخل مجلد التطبيق app، نعطيه اسم Helpers. داخل مجلد الدوال المساعدة app/Helpers ننشئ ملفا باسم MyFuncs.php لتعريف الصنف MyFuncs ونضيف إليه الشفرة المصدرية التالية: <?php namespace App\Helpers; class MyFuncs { public static function full_name($first_name,$last_name) { return $first_name . ', '. $last_name; } }تنشئ الشفرة أعلاه صنفا لتعريف الدالة المساعدة full_name. نبدأ بتعريف فضاء أسماء لأصناف المساعدات داخل فضاء أسماء التطبيق: namespace App\Helpers;ثم نعرّف الصنف MyFuncs الذي توجد داخله الدالة المساعدة full_name. الدالة المساعدة full_name هي دالة ثابتة static تقبل سلسلتي محارف Strings ثم تلمّهما Concatenate. صنف مزود الخدمة الخاص بالمساعِداتتستخدَم مزودات الخدمة للتحميل التلقائي للأصناف كما أشرنا في درس إنشاء سلة مشتريات في Laravel 5؛ سنعرّف مزود خدمة لتحميل جميع الأصناف الموجودة في المجلّد app/Helpers. سنستخدم Artisan لإنشاء مزود خدمة كما فعلنا مع النماذج و التهجيرات، نفذ الأمر التالي: php artisan make:provider HelperServiceProviderينشئ الأمر السابق ملفا باسم HelperServiceProvider على المسار /app/Providers؛ نفتحه لتحريره. عدّل الملف ليصبح كالتالي: <?php namespace App\Providers; use Illuminate\Support\ServiceProvider; class HelperServiceProvider extends ServiceProvider { /** * Bootstrap the application services. * * @return void */ public function boot() { // } /** * Register the application services. * * @return void */ public function register() { foreach (glob(app_path().'/Helpers/*.php') as $filename){ require_once($filename); } } }نعرّف فضاء الأسماء الذي ينتمي إليه الصنف App\Providers ثم نستدعي صنف مزود الخدمة Illuminate\Support\ServiceProvider وهو صنف يمدده مزود الخدمة الذي نحن بصدد تعريفه. تمهّد الدالة boot خدمات التطبيق Bootstrapping، أي تحميل الأصناف التي تعرّف الخدمات أثناء بدء التطبيق العمل. ثم يأتي دور الدالة register التي تحمّل محتويات المجلد Helpers بسبر ملفاته وتحميلها الواحد تلو الآخر. إعداد مزود خدمة المساعدات وكنية صنف المساعداتنحتاج لإعلام إطار العمل Laravel بوجود مزوّد الخدمة الذي أنشأناه. لذا سنفتح ملف إعداد التطبيق config/app.php ونضيف عنصرا جديدا إلى مصفوفة providers على النحو التالي: App\Providers\HelperServiceProvider::class,ثم ننتقل إلى مصفوفة الكنى aliases لإضافة كنية لصنف MyFuncs: 'MyFuncs' => App\Helpers\MyFuncs::class,احفظ التعديلات. استخدام المساعِدات المخصصةننشئ في ملف المسارات routes.php مسارا خاصّا لتجربة الدالة المساعدة: Route::get('/func', function () { return MyFuncs::full_name("Hsoub","Academy"); });نستدعي الدالة MyFuncs::full_name مع تمرير المعطيين الضروريين إليها. افتح المسار http://angulara.dev/func لتجربة عمل الدالة المساعدة. ستحصل على النتيجة التالية: Hsoub, Academyخاتمةتستخدَم الدوال المساعدة لتنفيذ مهام يكثُر استعمالها في تطبيقات الويب. يمكنك إنشاء دوال مساعدة مخصّصة وإضافتها إلى التطبيق. تفيد الدوال المساعدة كثيرا في تهيئة المخرجات وصياغتها ضمن قوالب Blade والاستغناء بالتالي عن معالجة البيانات داخل القوالب. ترجمة -وبتصرّف- لمقال Laravel 5 Custom Helper لصاحبه Rodrick Kazembe.