أدوات تقصير الروابط هي أدوات نستخدمها لجعل الروابط أقصر مما هي عليه في الواقع. باستخدام URL Shortener ، يمكنك تحويل رابط طويل (ربما لنموذج أو مقالة تسجيل) إلى إصدار أقصر.
خلف الكواليس ، تم تخزين النسخ الطويلة والقصيرة من ارتباط معين في بعض قواعد البيانات. بعد ذلك ، عندما يزور المستخدم الرابط القصير في المتصفح ، سيعيد URL Shortener توجيه المستخدم إلى النسخة الطويلة من الرابط (حيث يوجد المحتوى الفعلي).
تُستخدم الروابط المختصرة من أدوات تقصير عناوين URL بشكل شائع عندما تكون النسخة الطويلة من هذه الروابط طويلة جدًا بحيث لا يمكن استخدامها. تعد مشاركة الروابط على وسائل التواصل الاجتماعي أو عند تصميم النشرات والإعلانات استخدامًا شائعًا لاختصارات عناوين URL.
في أحد مشاريعي ، قمت بإنشاء أداة تقصير لعناوين URL شخصية. كنت أنوي استخدامه لروابط المقالات التي أكتبها أو مقاطع الفيديو التي أقوم بإنشائها. إستعملت Firebase لإنشاء الواجهة الخلفية لمختصر عناوين URL. على وجه التحديد ، استخدمت قاعدة بيانات Firestore لتخزين الإصدارات القصيرة والطويلة من أي رابط معين.
لإنشاء روابط ، كان علي استخدام وحدة تحكم Firebase. لم تكن هذه مشكلة ولكنها كانت مرهقة بسبب كثرة تحرير الروابط. لم تكن تجربة المستخدم (UX) مثالية. الآن واجهت مشكلة. كيف أقوم بإنشاء وتعديل وحذف الروابط؟ كنت بحاجة إلى إنشاء واجهة أمامية لمختصر عناوين URL. كنت بحاجة إلى موقع على شبكة الإنترنت من أجل هذا.
في هذه المقالة ، سنراجع الأدوات المتاحة المستخدمة لبناء هذه الواجهة الأمامية وخيارات القرار والعوامل التي أثرت في سبب اتخاذها.
بيان المشكلة
كانت متطلبات المشروع:
- المنصة / العمارة. هندسة وهيكل عملية الترميز.
- مجموعة أدوات واجهة المستخدم. مكونات لاستخدامها في الأجزاء المختلفة لواجهة المستخدم.
- وسائل الراحة. لم يكن بناء الواجهة الخلفية صعبًا ، لذا لا ينبغي أن تكون هذه الواجهة الأمامية أيضًا. أردت رمزًا نظيفًا وتطويرًا سريعًا.
اختيار القرار الأول: الزاوي
تتبادر إلى الذهن العديد من الأفكار عند البدء في بناء الواجهة الأمامية. بمعنى واسع ، يمكننا تصنيف خيارات بناء الواجهة الأمامية إلى 3 منصات:
- أدوات إنشاء مواقع الويب - مثل WordPress و Wix و Squarespace وما إلى ذلك.
- مبنى Vanilla - باستخدام HTML و CSS و JavaScript عادي.
- إطار عمل JavaScript - مثل React و Vue و Angular وما إلى ذلك.
من واقع خبرتي ، يوفر منشئو مواقع الويب مجموعة محدودة للغاية من الأدوات والمكونات والقوالب. لا يوفر معظم منشئي مواقع الويب طريقة سهلة لدمج خلفية مخصصة بالكامل مثل Firebase. في حين أنه من الممكن إنشاء مواقع رائعة من خلال ربط هذه الأجزاء معًا ، إلا أن درجة تعقيد مشروعي كانت على الأرجح تتجاوز ما توفره هذه الخدمات عادةً.
كان من الممكن استخدام أسلوب no-framework أو الفانيليا. ومع ذلك ، كان العامل الحاسم الذي جعلني لا أختار طريق الفانيليا النقي هو ذلك أحدث إصدار بخلاف CDN من Firebase JavaScript SDK (الإصدار 9) تم تصميمه مع التثبيت عبر npm or yarn وتجميع الوحدات النمطية في الاعتبار.
تتعامل أطر عمل JavaScript مع الأجزاء الأساسية للواجهة الأمامية (مثل التوجيه ، وربط الواجهة الخلفية ، وما إلى ذلك) لتقليل جهود المطورين. هناك الكثير منهم ويبدو أن اختيار أي منها كان خيارًا صعبًا.
هناك العديد من أطر عمل JavaScript لتطوير الواجهة الأمامية. تتضمن الأمثلة Angular و React و Vue وما إلى ذلك.
من بين الأطر المتاحة ، لدي ألفة كبيرة مع Angular. هذا لأنني استخدمته في مشاريع سابقة مثل:
- جوقة كارول مسابقة: بوابة حيث تنافس المشاركون في المسابقة في جولتين عبر الإنترنت من أسئلة الاختيار من متعدد الموقوتة في فصول مختارة من الكتاب المقدس.
- مجتمع Genesys AE-FUNAI: نموذج مخصص حيث يقوم أعضاء Genesys Campus Club AE-FUNAI (مجتمعي) بالإبلاغ عن تقدمهم ومشاركة إنجازاتهم.
- نظام إدارة البرنامج التعليمي: لوحة تحكم بسيطة لإدارة الجلسة بين الطلاب والمعلمين.
تسمح لي هذه الألفة بالبناء بسرعة مع Angular. لا ينبغي الاستهانة بالقدرة على البناء بسرعة.
اخترت Angular نظرًا لقدرته على البرمجة الشيئية (OOP). OOP هو نموذج برمجة يركز بشكل أكبر على الفئات أو البيانات أو الحالة التي تتم إدارتها ، بدلاً من المنطق الذي يتحكم في البيانات ، كما هو الحال مع البرمجة الوظيفية. يعد فصل المخاوف أحد مزايا استخدام OOP. بمعنى آخر ، يسمح OOP بالتغليف. يسمح لك بتوسيع نطاق جوانب البرنامج إلى مجالات أو فئات غريبة.
في Angular ، يتم تحديد نطاق المكونات (وطرق دورة حياتها) لفئات TypeScript. هذا يجعلك تفكر بطريقة OOP. تنعكس ميزة OOP في كيفية عمل مكونات Angular كوحدات واجهة مستخدم قابلة لإعادة الاستخدام في إطار Angular. بهذه الطريقة ترى المكوِّن الزاوي باعتباره كيانًا مكتفيًا ذاتيًا لا يزال جزءًا من الكل. هذا يجعل تطوير الواجهة الأمامية أمرًا سهلاً حيث يمكن تحديد أجزاء مختلفة من تطبيق الواجهة الأمامية للمكونات وبالتالي يمكن استخدامها عند الحاجة.
اخترت أيضًا Angular لأنه يستخدم TypeScript. TypeScript هو JavaScript مع ميزات لغة برمجة مكتوبة. تعني الكتابة في هذا السياق أن المتغير لا يمكنه تغيير نوع القيمة التي يحملها طوال حياته. على سبيل المثال ، المتغير الذي يحمل سلسلة لن يحتفظ فجأة برقم أثناء استخدامه في هذا البرنامج. تزيد الكتابة من جودة الشفرة وتقلل من الأخطاء.
كنتيجة لنظام النوع الخاص به ، يقلل TypeScript الوقت المستغرق في تصحيح أخطاء تطبيقات Angular. إنه يمنح خبرة المطور حيث سيكون لدى المطور المزيد من الوقت لإنشاء تطبيق الواجهة الأمامية. تصحيح الأخطاء يصبح أيضًا سهلاً للمطور.
ملحوظة: إليك المزيد عن البرمجة الشيئية باستخدام TypeScript
ومع ذلك ، فيما يتعلق بمزايا Angular ، تأتي تطبيقات Angular كإعداد كامل. يتعاملون مع ميزات مهمة مثل تجميع معالجات CSS الأولية أو خدمات Angular بأنفسهم. ومع ذلك ، عند استخدام Angular ، لا تحتاج إلى تكوين كل مكتبة بشكل مستقل ، حيث يتولى Angular هذا الأمر.
خدمة Angular هي ما يستخدمه Angular لتكوين حقن التبعية. بعبارات بسيطة ، يوفر حقن التبعية للتطبيق ما يحتاجه للعمل (التبعيات) دون أن يضطر التطبيق إلى الاهتمام بكيفية الحصول على التبعيات. لقد اخترت أيضًا Angular بسبب تعاملها مع الخدمات خارج الصندوق. لذلك ، سيتم توفير Firebase ، على سبيل المثال ، تلقائيًا لجميع مكونات Angular التي تحتاج إلى أي تكوين إضافي.
تجعل مزايا البرمجة الشيئية ، و TypeScript ، وحقن التبعية من Angular نقطة انطلاق لتطوير الواجهة الأمامية. إلى جانب حقيقة أنني كنت على دراية بـ Angular بالفعل ، كان Angular أكثر ملاءمة لمشروع تقصير عناوين URL هذا.
المقالات الزاويّة على CSS-Tricks هي أيضًا جزء من القصة. لقد منحوني المزيد من الثقة في استخدام Angular.
خيار القرار الثاني: تصميم المواد
بعد اختيار Angular ، كانت مهمتي التالية هي التفكير في كيفية التعامل مع واجهة المستخدم (UI).
يمكنني تجاهل وعمل Vanilla CSS بدلاً من ذلك ولكن لماذا أعيد اختراع العجلة؟ بعد كل شيء ، هذا من شأنه أن يهزم سبب استخدام إطار عمل JavaScript - الراحة.
مع اختيار مجموعة أدوات واجهة المستخدم ، يبدو أن هناك محيطًا من الخيارات. على سبيل المثال لا الحصر ، يمكن استخدام Bootstrap و Bulma و Semantic UI و Tailwind وما إلى ذلك. كل مجموعة أدوات لها مواصفاتها ودوافعها.
بالنسبة لحالة استخدام مشروعي ، قادت شركة Material Design المجموعة.
كان أحد أهم العوامل هو دعم التصميم الزاوي والمادي. توجد مواصفة Angular-only كاملة لمادة on material.angular.io (هذا كنطاق فرعي لمستندات Angular نفسها).
استقرت على التصميم متعدد الأبعاد لأنه يركز على المكونات. على عكس أطر CSS الأخرى ، فإنه لا يحتوي على فئات أدوات مساعدة CSS. كان هذا جيدًا لأنني أردت فقط بعض مجموعة المكونات (الأزرار ، والرموز ، والمدخلات ، والأشرطة الجانبية ، وأشرطة الوجبات الخفيفة ، وما إلى ذلك) تضيف المواد أيضًا تأثيرات الرسوم المتحركة ، والتموج ، والظل من تلقاء نفسها ؛ مما يجعلها أكثر ملاءمة من المكتبات الأخرى.
علاوة على ذلك ، تتمتع Angular Material بدعم تصميم خارج الصندوق ، عند تهيئة Angular Material ، لديك خيار اختيار سمة محددة مسبقًا لتطبيق Angular بأكمله أو إنشاء سمة مخصصة.
من أجل الراحة ، اخترت سمة داكنة أثناء إعداد Angular Material.
خيار القرار الثالث: أشكال رد الفعل
مع تحديد إطار العمل ومجموعة الأدوات ، وجهت انتباهي إلى واحدة من أهم ميزات أداة تقصير عناوين URL. جوهر الواجهة الأمامية لمختصر عناوين URL هو نموذج إنشاء الروابط وتحديثها.
دعنا نسمي هذا النموذج محرر الروابط. يحتوي نموذج محرر الروابط على مدخلين فقط ، أحدهما للنسخة القصيرة من الرابط والآخر لعنوان URL الكامل الذي ستتم إعادة التوجيه إليه في النسخة القصيرة.
لإدارة النماذج ، يأتي Angular بآليتين. لذا بدلاً من إنشاء نموذج والتعامل مع التحقق من صحته وتقديمه كما هو الحال في لغة HTML و JavaScript ، يجب عليك استخدام أي من الطريقتين اللتين توفرهما Angular. الطريقتان هما:
- نماذج يحركها القوالب
- أشكال رد الفعل
نماذج يحركها القوالب كما يوحي الاسم ، قم بتضمين كود HTML (قالب) الذي يتحكم في الجزء الأكبر من النموذج الزاوي. يُفضل هذا الأسلوب عندما لا يعمل النموذج الخاص بك كثيرًا أو يستخدم لمرة واحدة.
أشكال رد الفعل، من ناحية أخرى ، يوفر نهجًا يحركه النموذج للتعامل مع مدخلات النموذج التي تتغير قيمها بمرور الوقت. كنت بحاجة إلى نماذج تفاعلية لأنها نفس النموذج الذي سأستخدمه لتحرير الروابط المختلفة في أي وقت.
ملحوظة: هنا المزيد من المواد حول استخدام النماذج التفاعلية.
في هذه المرحلة ، بدأت فوائد الخيارات السابقة في الظهور. مادة الزاوي لديها form-field عناصر. ال form-field يلف الإدخال كمكون ويوفر رسومًا متحركة وتأثيرات تموج ورسائل خطأ إذا لزم الأمر.
لذلك استخدمته لإدخال اثنين من نموذج المحرر.
خيار القرار الرابع: الدرج والورق السفلي للمواد الزاوي
تضمن القرار النهائي كيفية تحسين تجربة المستخدم. سيحتاج مُختصر عناوين URL إلى ميزات أخرى مثل عرض جميع الروابط التي تم إنشاؤها وتحليلاتها. تتطلب هذه الميزات مساحة على الشاشة تتطلب مني إعادة التفكير فيما إذا كانت هناك حلول أفضل لعرض نموذج محرر الروابط للمستخدم.
إذا لم يكن المستخدم بحاجة حاليًا إلى نموذج محرر الروابط ، فمن المنطقي ألا يتم عرض نموذج محرر الروابط دائمًا. سيؤدي ذلك إلى توفير مساحة على واجهة المستخدم لعناصر أخرى.
ومع ذلك ، فإن تقسيم تجربة المستخدم هذه إلى صفحتين منفصلتين كان أمرًا مزعجًا. بدلاً من ذلك ، لفتح محرر الروابط عند الحاجة ، أضفت زر إجراء عائمًا على الصفحة لإنشاء روابط. عند النقر فوقه ، سيتسبب الزر في فتح نموذج المحرر في أي مكون مناسب لواجهة المستخدم.
A نهاية الورقة، كما يوحي الاسم ، هو مكون واجهة المستخدم الذي يفتح من أسفل الشاشة. يحتوي على محتوى تفاعلي يمكن للمستخدم العمل عليه. إنه يقوم بتراكب العرض الحالي لشاشة الهاتف المحمول (لكنه لا يحظرها بالكامل).
تُستخدم الأوراق السفلية عادةً بدلاً من النوافذ المنبثقة إذا كان المستخدم سيقضي وقتًا طويلاً في التفاعل مع محتواها. لذلك ، تعد الأوراق السفلية مناسبة تمامًا لفتح المحرر على شاشات الهاتف المحمول. ومع ذلك ، يكون التفاعل مع الورقة السفلية صعبًا عندما تكون الشاشة عريضة. كنت بحاجة إلى مكون واجهة مستخدم مختلف لشكل محرر الروابط على شاشات عريضة.
أدراج افتح بالجانب. كان استخدام درج لفتح نموذج محرر الروابط على شاشة عريضة هو خيار الانتقال. لن تكون الأدراج جيدة للمحرر على شاشات الهاتف المحمول. سيكون عرض الشاشة صغيرًا نسبيًا وقد يحجب الدرج الشاشة تمامًا (وهي ليست تجربة مستخدم مرغوبة).
لقد اخترت هذين المكونين لواجهة المستخدم من التصميم متعدد الأبعاد للنموذج ليكون له بعض التأثير سريع الاستجابة. لذلك سواء على هاتفي أو الكمبيوتر المحمول ، سيتم إنشاء روابط في مكون واجهة مستخدم مناسب.
في الكود ، يتحقق Angular مما إذا كان الجهاز ذو عرض صغير للشاشة. إذا كان الأمر كذلك ، فإنه يفتح ورقة سفلية تحتوي على نموذج محرر الروابط. من ناحية أخرى ، إذا كانت الشاشة عريضة ، يفتح Angular درجًا يحتوي على نفس الشكل.
أدى استخدام هذين المكونين إلى مضاعفات بسيطة. إذا تم تدوير هاتفي أو تم تقليل عرض نافذة متصفح الكمبيوتر المحمول ، فسيتم فتح النموذج على مكون واجهة المستخدم المعاكس. هذا بدلاً من الفتح في درج في جهاز كمبيوتر محمول ، سيتم فتحه في ورقة سفلية (نظرًا لتقليل عرض المتصفح).
الصيانة ، تدقيق المستقبل ، الإصدارات المستقبلية
عندما فكرت في الفرص للتكرار في هذا المشروع ، واجهت قيودًا مع حالة الاستخدام الحالية المصممة لدعم مسؤول واحد. ولكن مع المصادقة وحسابات المستخدمين ، يمكنه دعم مستخدمين إضافيين يديرون الروابط والوصول إلى التحليلات.
في هذه الحالة ، ستظل الخيارات المذكورة أعلاه للمكونات مناسبة. محرر الروابط مستجيب لذلك على أي جهاز ، يتمتع المستخدمون بتجربة مستخدم جيدة.
إذا اضطررت إلى القيام بذلك مرة أخرى ، أعتقد أنني كنت سأجرب طريقة الفانيليا. البناء بالكامل بدون أي مساعدين مثل الزاوي أو المادي أو مكونات واجهة المستخدم. سأحاول البناء من الصفر في HTML و CSS و JavaScript وأرى ما إذا لم أفقد الراحة كما اعتقدت.
وفي الختام
يمكنك الوصول إلى الرمز Angular النهائي هنا على GitHub.
كانت هذه مراجعة لبعض الخيارات الرئيسية التي قمت بها عند تطوير مشروعي. بالطبع ، هناك المزيد لبناء الواجهة الأمامية لمختصر عناوين URL. ولكن كبداية ، جعلت مكونات واجهة المستخدم هذه عملية البناء مريحة. لقد جعلوا نموذج محرر الروابط سريع الاستجابة ويمكن أن يكون ذا استخدام مشابه لك في مشاريعك (وليس بالضرورة أداة تقصير لعناوين URL).
هناك العديد من مكونات واجهة المستخدم الأخرى من مكتبات مختلفة يمكنك استخدامها لأي مشروع من هذا القبيل. ولكن كما هو الحال مع حالتي ، إذا كانت الملاءمة عاملاً حاسمًا ، فستتخذ القرار الصحيح الذي سيكون مناسبًا لواجهة المستخدم.
في النهاية ، ما شكل قراراتي هو فهم ما يتطلبه مشروعي ، ومعرفة الأدوات التي استخدمتها من المشاريع السابقة ، والتوقعات مع ضيق الوقت. ساعدت تجربتي السابقة - النجاحات والأخطاء - في إرشادي أيضًا.
هتاف!
