سنبني في هذا الدليل تطبيقًا لإنشاء الفواتير بصيغة PDF بالاعتماد على مكتبة React، وهي مكتبة لبناء واجهات مستخدم تفاعلية في الويب و إطار عمل Refine الذي يعتمد على رياكت React لتسهيل بناء تطبيقات CRUD وتحسين تجربة المطور في إدارة البيانات والتفاعل مع الواجهات الأمامية، ثم ننشره على منصة DigitalOcean’s App Platform.

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

اقتباس

ملاحظة: يمكنك الحصول على الشيفرة المصدرية الكاملة للتطبيق الذي سنبنيه في هذا الدليل من هذا المستودع على GitHub.

سنستخدم التقنيات التالية بجانب Refine:

• نظام إدارة المحتوى Strapi القائم على التخزين السحابي Cloud لتخزين البيانات. ولجلب البيانات منه، سنستخدم موفر البيانات data-provider المدمج في Refine. يمكننا الوصول إلى API الخاص بـ Strapi عبر api.strapi-invoice
• مكتبة واجهة المستخدم Ant Design

بعد بناء التطبيق، سننشره باستخدام منصة DigitalOcean’s App Platform، التي تُبسّط وتسرّع عملية إعداد وإطلاق وتوسيع التطبيقات والمواقع الثابتة. يمكن نشر الكود عن طريق رابط مستودع GitHub، وستتولى المنصة App Platform إدارة البنية التحتية وبيئات عمل التطبيق والاعتمادات.

أما المتطلبات المُسبقة للعمل، فتكون كالآتي:

• بيئة تطوير محلية لـ Node.js
• تحتاج إلى معرفة أساسية بـ React وRefine وJSX
• حساب GitHub لاستضافة الكود البرمجي
• حساب DigitalOcean

ما هو Refine؟

إطار عمل Refine هو إطار عمل مفتوح المصدر يعتمد على React لتطوير التطبيقات التي تعتمد على إدارة البيانات الكثيرة مثل الأدوات الداخلية، لوحات التحكم Dashboards، ولوحات الإدارة Admin Panels، وجميع أنواع تطبيقات CRUD. يوفر مجموعة من خطافات Hooks والمكونات التي تساهم في تقليل وقت التطوير وتحسين تجربة المطور.

ملاحظة: CRUD هي اختصار للعمليات التي تتم على البيانات، وهي اختصار للحرف الأول من كلمات إنشاء Create وقراءة Read وتعديل Update وحذف Delete.

صُمم Refine لبناء تطبيقات الأعمال التجارية لبعضها B2B جاهزة للإنتاج؛ فبدلًا من البدء من الصفر، يوفر إطار العمل بعض الأدوات الأساسية التي تساعد في إدارة البيانات والحالة والاستيثاق Authentication والأذونات.

يتميز Refine باعتماده على بنية بدون رأس Headless، مما يسمح باستخدام أي مكتبة لتصميم واجهة مستخدم أو تصميم تنسيقات انسيابية CSS خاص. ويدعم مكتبات واجهة المستخدم مفتوحة المصدر مثل Ant Design وMaterial UI و Mantine و Chakra UI. لذا بهذه الطريقة، يمكننا التركيز على بناء الأجزاء المهمة من التطبيق دون الانشغال بالتفاصيل التقنية.

إنشاء تطبيق Refine جديد

ستستخدم الأمر البرمجي التالي لإنشاء المشروع بتفاعلية أكبر:

npm create refine-app@latest

اختر الخيارات التالية عندما تُطلب:

✔ Choose a project template · Vite
✔ What would you like to name your project?: · refine-invoicer
✔ Choose your backend service to connect: · Strapi v4
✔ Do you want to use a UI Framework?: · Ant Design
✔ Do you want to add example pages?: · No
✔ Choose a package manager: · npm

بعد اكتمال الإنشاء، ننتقل إلى مجلد المشروع ونبدأ التطبيق باستخدام:

npm run dev

نفتح الرابط http://localhost:5173 في المتصفح لرؤية التطبيق.

تثبيت المكتبات الخارجية

سنحتاج لتثبيت بعض حزم npm التي سنستخدمها في التطبيق:

• ‏react-input-mask‏‮: لتنسيق حقول الإدخال، ستستخدم هذه المكتبة لتنسيق حقل رقم الهاتف
• ؜antd-style: حل css-in-js خاص بـ Ant Design. ستستخدم هذه المكتبة لتخصيص مكونات Ant Design
• ؜vite-tsconfig-paths: ملحق لـ Vite يسمح بحل الواردات باستخدام مسار JSX

للقيام بذلك ننفذ الأمر التالي:

npm install react-input-mask antd-style

ثم نثبت الأنواع التالية:

npm install @types/react-input-mask vite-tsconfig-paths --save-dev

بعد تثبيت الحِزم، سنحتاج إلى تحديث ملف tsconfig.json لاستخدام مسار JSX. هذا يجعل استيراد الملفات أسهل للقراءة و الصيانة، فبدلًا من كتابة الأمر التالي:

"import { Log } from "../../types/Log

سنكتب ما يلي: 

"import { Log } from "@/types/Log

لتحقيق ذلك، نضيف الكود التالي إلى ملف tsconfig.json:

{
  "compilerOptions": {
    "target": "ESNext",
    "useDefineForClassFields": true,
    "lib": ["DOM", "DOM.Iterable", "ESNext"],
    "allowJs": false,
    "skipLibCheck": true,
    "esModuleInterop": false,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "module": "ESNext",
    "moduleResolution": "bundler",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react-jsx",
    "baseUrl": "./src",
    "paths": {
      "@/*": ["./*"]
    }
  },
  "include": ["src", "vite.config.ts"],
  "references": [{ "path": "./tsconfig.node.json" }]
}

سنحتاج أيضًا إلى تحديث ملف vite.config.ts لاستخدام ملحق vite-tsconfig-paths، والذي يسمح لـ Vite بحل الواردات باستخدام مسار JSX كالتالي:

import react from "@vitejs/plugin-react";
import { defineConfig } from "vite";
import tsconfigPaths from "vite-tsconfig-paths";

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [tsconfigPaths({ root: __dirname }), react()],
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          antd: ["antd"],
        },
      },
    },
  },
});

إضافة المكونات الأساسية والدوال المساعدة

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

التطبيق فى مستودع GitHub شامل و يعمل جيدًا، لذا سيساعد إعداد هذه الملفات وتجهيزها على اتباع خطوات الدليل وعدم الإطالة فيه.

أولًا، نحذف الملفات والمجلدات التالية من المشروع الذي أنشأته:

• مجلد src/components
• مجلد src/contexts
• ملف src/authProvider.ts
• ملف src/constants.ts

ثم ننسخ الملفات والمجلدات التالية إلى نفس الموقع في المشروع:

• ؜components
• ؜providers
• ؜utils
• ؜types
• ؜styles

بنية المشروع بعد التعديل

بعد هذه الخطوات، يجب أن تكون بُنية المشروع كما يلي:

└── 📁src
    └── 📁components
    └── 📁providers
    └── 📁styles
    └── 📁types
    └── 📁utils
    └── App.tsx
    └── index.tsx
    └── vite-env.d.ts

بعد هذه الخطوات، سيُظهِر ملف App.tsx خطأ لأنك أزلت ملفات authProvider.ts وconstants.ts. ستقوم بإصلاح ذلك عن طريق تحديث ملف App.tsx في الخطوة التالية.

الخلاصة

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

ترجمة وبتصرف للمقال Building a React PDF Invoice Generator App with Refine and Deploying it to DigitalOcean's App Platform لكاتبيه Alican Erdurmaz و Anish Singh Walia.

اقرأ أيضًا

• مصادر تعلم مكتبة React لبناء تطبيقات الويب
• تعرف على أمان مواقع الويب
• إنشاء تطبيق قائمة مهام باستخدام React
• الدليل المرجعي للعمل على نظام غيت Git
• أساسيات جافاسكربت اللازمة للعمل مع React

تعد ريآكت React أحد أشهر مكتبات لغة جافا سكريبت المستخدمة في تطوير الواجهات الأمامية front-end development، إلا أن تطوير التطبيقات بهذه المكتبة يمكن أن يتسبب لك ببعض المشكلات مع محركات البحث. نستعرض في هذه المقالة أهم التحديات التي تواجه المطورين في تحسين محركات البحث SEO للتطبيقات المصممة باستخدام مكتبة ريآكت React، ونوضح أهم الخطوات التي يمكنك اتباعها لتجاوز هذه المشكلات بفعالية، وتحسين سيو التطبيقات، ورفع رتبتها في صفحة نتائج محرك البحث.

لمحة عن ريآكت React وآلية عملها

ريآكت React هي مكتبة جافا سكريبت مخصصة لإنشاء واجهات مستخدم تفاعلية متعددة المنصات وهي تعتمد على تقسيم التطبيق لعدة مكونات أو أجزاء صغيرة قابلة لإعادة الاستخدام لتساعد في إنشاء تطبيقات واجهات أمامية فعالة وعالية الأداء. طُورت مكتبة ريآكت في الأساس من أجل إنشاء تطبيقات الصفحة الواحدة Single Page Applications أو اختصارًا SPAs -وهي تطبيقات مبنية بالاعتماد على صفحة واحدة ويمكنك أن تنتقل بين صفحاتها دون الحاجة إلى تحميل الصفحات الجديدة بالكامل- ولكنها اليوم تصلح لإنشاء مختلف أنواع مواقع الويب وتطبيقات الجوال. إلا أن المواقع والتطبيقات المصممة بهذه المكتبة قد تواجه مجموعة من التحديات والمشكلات المتعلقة بترتيبها في محركات البحث، وهذا ما ستلاحظه بنفسك إذا كنت قد طورت في البداية تطبيقات ويب بالطريقة التقليدية وكتبت بنفسك كافة التعليمات الأساسية اللازمة لواجهات هذه التطبيقات دون الاستعانة بمكتبات أوأطر عمل جاهزة، ثم انتقلت بعد ذلك لاستخدام مكتبة ريآكت إذ ستلاحظ أن جزءَا كبيرًا من شيفرات HTML و CSS الخاصة بتطبيقك قد أصبحت جزءًا من شيفرات جافا سكريبت JavaScript. السبب في ذلك هو أن مكتبة ريآكت React لا توصي بإنشاء عناصر واجهة المستخدم أو تحديثها بشكل مباشر، بل تعتمد طريقة أخرى بدلاً وهي وصف (حالة state) عناصر واجهة المستخدم أي تصف كيف يجب أن تظهر واجهة المستخدم في أي وقت، ثم تُحدِّث بعد ذلك نموذج تمثيل المستند ككائن DOM ليتوافق مع هذه الحالة بطريقة فعالة، كما توفر ريآكت مكونات قابلة لإعادة الاستخدام يمكننا استخدامها لوصف حالة واجهة المستخدم.

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

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

طريقة زحف محرك البحث جوجل إلى صفحات الويب وفهرستها

قبل الغوص في حلول تحسين سيو تطبيقات رياكت من الضروري أن تفهم كيف يزحف محرك البحث جوجل Google إلى تطبيقاتك ومواقعك ويفهرسها، فمحرك البحث جوجل هو أشهر محرك بحث ويتلقى ما يزيد على 90% من مجمل عمليات البحث عبر الإنترنت ويمكنك من خلال فهم طريقة عمله معرفة العوامل التي تؤثر على فهرسة موقعك.

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

خطوات فهرسة جوجل

يتبع زاحف جوجل Googlebot عملية من عدة خطوات لفهرسة مواقع الويب وهي كالتالي:

ينشئ زاحف جوجل رتل انتظار للزحف crawl queue يتضمن كافة عناوين URL التي اكتشفها والتي يحتاج للزحف إليها وفهرستها لاحقًا. عندما يكون الزاحف جاهزًا، فإنه يأخذ عنوان URL التالي في رتل الانتظار، ويرسل طلبًا لجلب محتوى HTML للصفحة. بعدها يقوم الزاحف Googlebot بتحليل محتوى HTML وتحديد فيما إذا كان يحتاج كذلك إلى جلب سكربتات جافا سكريبت وتنفيذها لعرض المحتوى. إذا كانت الإجابة نعم سيضاف عنوان URL إلى رتل انتظار التصيير render queue. لاحقًا، يقوم المصيّر renderer الخاص بالزاحف بجلب شيفرات جافا سكريبت وتنفيذها من أجل تصيير أو عرض render الصفحة ويرسل كود HTML الناتج مرة أخرى إلى وحدة لمعالجة الكود processing unit. تستخرج وحدة المعالجة جميع وسوم الروابط <a> لعناوين URL المكتشفة في صفحة الويب وتضيفها من جديد إلى رتل انتظار الزحف crawl queue. أخيرًا يضاف المحتوى إلى فهرس جوجل.

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

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

ملاحظة: ينصح بقراءة الإرشادات التي يعتمدها جوجل من أجل إدارة وتحسين ميزانية الزحف الخاصة بك من هنا.

لماذا يمثل السيو تحديًا في ريآكت React ؟

بعد أن كونت فكرة عامة عن طريقة عمل زاحف جوجل Googlebot وفهرسته للموقع ستتمكن كمهندس برمجيات من تحديد المشكلات المحتملة التي تواجهها محركات البحث التي تحاول الزحف إلى صفحات مواقع أو تطبيقات ريآكت وفهرستها بشكل أفضل.

وفيما يلي نبين أبرز أسباب حدوث مشكلات في تحسين محركات البحث لمواقع وتطبيقات React ونوضح سبل حلها والتغلب عليها.

السبب الأول: محتوى الصفحة فارغ عند المرور عليها لأول مرة

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

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

السبب الثاني: زيادة وقت التحميل التي تؤثر على تجربة المستخدم UX

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

وبما أن جوجل تعتبر أن مواقع الويب التي تستغرق وقتًا طويلاً للتحميل تؤثر سلبًا على تجربة المستخدم وتعتمد هذا الأمر كمعيار لتحديد ترتيب المواقع في محركات البحث فالمواقع الأبطأ في التحميل ستحصل على ترتيب أقل في صفحة نتائج البحث.

السبب الثالث: صعوبة تخصيص البيانات الوصفية metadata لكل صفحة من صفحات الموقع

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

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

كما تعتمد رياكت على منهجية تصيير كل المحتوى بما في ذلك وسوم ميتا من جانب العميل، وبالتالي سيكون هيكل التطبيق App shell هو نفسه لكامل الموقع أو التطبيق، بمعنى آخر ستكون البيانات الوصفية metadata موحدة لكافة صفحات موقع الويب أو التطبيق وسيكون من الصعب تخصيص هذه البيانات لكل صفحة على حدة، وبهذا سترى محركات البحث نفس البيانات الوصفية لجميع الصفحات، حتى لو كانت هذه الصفحات مختلفة تمامًا عن بعضها البعض وهذا قد يؤثر على فهرستها بصورة صحيحة.

السبب الرابع: عدم وجود طريقة مدمجة لإنشاء خريطة الموقع Sitemap

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

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

نصائح عامة لتحسين محركات البحث غير مرتبطة بمكتبة ريآكت

إليك أهم النصائح والممارسات التي يمكنك الأخذ بها لتحسين محركات البحث للمواقع والتطبيقات بشكل عام وليست خاصة بتطبيقات ريآكت فقط.

• احصل على عنوان URL سهل لموقعك أو تطبيقك ويمكن فهمه من قبل البشر ومحركات البحث ويعطي فكرة واضحة عن المحتوى الذي يتضمنه.

• حَسّن ملف robots.txt لمساعدة روبوتات البحث على فهم كيفية الزحف إلى صفحات موقعك.

• استخدم شبكة توصيل محتوى CDN لتخزين جميع الأصول الثابتة مثل CSS و JS والخطوط، واستخدم صورًا متجاوبة لتقليل أوقات تحميل الصفحات.

كما يمكن معالجة العديد مشكلات السيو باستخدام التصيير من جانب الخادم SSR أو التصيير المسبق pre-rendering وسنستعرض هذه الأساليب بمزيد من التفصيل في فقرات لاحقة.

ما هي تطبيقات ريآكت المتماثلة Isomorphic

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

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

يسمح هذا النهج المتماثل للخادم يتصيير render تطبيق رياكت وإرسال النتيجة إلى المستخدمين ومحركات البحث ليتمكنوا من عرض المحتوى على الفور، بينما تُحمّل أكواد وتنفذ جافا سكريبت في الخلفية وقد اعتمدت عدة أطر على هذا الأسلوب وزادت من شهرته مثل إطار Next.js ومولد المواقع Gatsby .

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

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

مقاييس أداء الموقع

سنوضح الآن بعض المعايير التي تستخدمها محركات البحث لتصنيف وترتيب مواقع الويب لنساعدك على فهم المزيد حول رفع رتبة موقعك في نتائج البحث.

إلى جانب الإجابة على استفسار المستخدم بسرعة ودقة، تعتقد جوجل أن موقع الويب الجيد يجب أن يحقق ما يلي:

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

تتوافق هذه الميزات تقريبًا مع المقاييس التالية:

• زمن وصول أول بايت (TTFB): هو اختصار لعبارة Time to First Byte ويعني مقدار الوقت الذي يستغرقه وصول أول جزء من المحتوى من الخادم إلى المتصفح، أو الوقت بين النقر على الرابط ووصول الجزء الأول من المحتوى للمستخدم.
• أضخم محتوى مرئي (LCP): وهو اختصار لعبارة Largest Contentful Paint ويمثل الزمن الذي يحتاجه عرض العنصر الذي يتضمن أضخم جزء مرئي من الصفحة وهو يعطي فكرة عن زمن انتظار المستخدم لتحميل ما يكفي من الصفحة لتصبح ذات معنى، وتوصي جوجل بأن لا تتجاوز هذه القيمة 2.5 ثانية.
• زمن التفاعل (TTI): وهو اختصار لعبارة Time to Interactive ويعني الوقت الذي تصبح فيه الصفحة تفاعلية أي يمكن للمستخدم النقر فوق عناصر أو تمريرها…إلخ.
• حجم الحزمة (Bundle Size): ويمثل إجمالي عدد البايتات المحملة والتعليمات البرمجية المنفذة قبل أن تصبح الصفحة مرئية وتفاعلية بالكامل.

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

مسارات التصيير Render Paths

نعني بمسارات التصيير الطرق المختلفة التي يمكن من خلالها الوصول إلى محتوى الصفحة حيث يمكننا تصيير أو عرض تطبيق React على جانب المتصفح client-side أو على جانب الخادم server-side وإنتاج مخرجات مختلفة.

وهنالك وظيفتان تتفاوتان بشكل كبير بين التطبيقات المصيًّرة من جانب العميل والخادم وهما عملية التوجيه routing، وعملية تقسيم التعليمات البرمجية code splitting، لنتعرف على آلية القيام بكل منهما في كل حالة:

حالة التصيير من جانب العميل (CSR)

التصيير من جانب العميل هو مسار التصيير الافتراضي في تطبيقات رياكت ذات الصفحة الواحدة React SPA. حيث أن الخادم يوفر غلاف تطبيق shell app لا يتضمن أي محتوى فعلي وبمجرد قيام المتصفح بتحميل أكواد جافا سكريبت JavaScript المضمنة في الصفحة ويحللها وينفذها سيملأ محتوى HTML ويعرض بالكامل.

في هذه الحالة يتم التعامل مع وظيفة التوجيه بواسطة تطبيق العميل client app من خلال إدارة سجل المتصفح browser history. وهذا يعني أنه يتم تصيير أو عرض نفس ملف HTML بغض النظر عن المسار الذي طُلِب، ويقوم العميل بتحديث حالة العرض view state الخاصة به بعد عرضه.

أما تقسيم الكود في هذه الحالة فهو أمر بسيط نسبيًا حيث يمكن تقسيم التعليمات البرمجية الخاصة بالتطبيق باستخدام الاستيراد الديناميكي dynamic imports أو بالاستعانة بمكتبة React.lazy إذ يقسم الكود بحيث يتم تحميل التبعيات المطلوبة فقط بناءً على المسار أو إجراءات المستخدم.

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

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

التصيير من جانب العميل باستخدام البيانات التمهيدية (CSRB)

لنفترض أن لدينا حالة تصيير من جانب العميل CSR ولكن بدلاً من جلب البيانات بعد تصيير وعرض مستند DOM بحيث تظهر المحتويات أو البيانات ذات الصلة بشكل تدريجي، سنفترض أن الخادم يرسل البيانات ذات الصلة مباشرة داخل كود HTML المُصَيَّر.

يمكن أن نضيف عقدة node كما يلي داخل صفحة HTML:

<script id="data" type="application/json">
      {"title": "My blog title", "comments":["comment 1","comment 2"]}
</script>

يضمن هذا الكود البيانات بصيغة JSON داخل صفحة HTML، وتحلل هذه القاعدة التي تحتوي على البيانات المطلوبة (وهي عنوان المدونة والتعليقات عليها) وتفسر عند إضافة المكون إلى مستند DOM على النحو التالي:

var data = JSON.parse(document.getElementById('data').innerHTML);

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

تصيير المحتوى الثابت من جانب الخادم (SSRS)

في هذه الحالة يتم إنشاء وتصيير الصفحة بالكامل على جانب الخادم قبل إرساله إلى المتصفح، تخيل على سبيل المثال حالة لموقع أو تطبيق ويب تحتاج فيه إلى إنشاء كود HTML بسرعة، على سبيل المثال إذا كنت تريد بناء تطبيق ريآكت لآلة حاسبة عبر الإنترنت، وأدخل المستخدم لهذا التطبيق استعلام من المستخدم من خلال عنوان URL على النحو التالي:

/calculate/34+15

يحتاج التطبيق لمعالجة هذا الاستعلام وتقييم النتيجة والرد بكود HTML الذي تم إنشاؤها، وبما أن كود HTML النتاتج يملك بنية بسيط جدًا فلست بحاجة لأن تقوم رياكت بإدارة DOM ومعالجته ويمكنك الاكتفاء بعرض HTML الناتج مباشرة.

لذلك يمكن توفير محتوى HTML و CSS فقط واستخدام التابع renderToStaticMarkup لتحقيق ذلك.

سيتعامل التطبيق في هذه الحالة مع التوجيه بالكامل من جانب الخادم لأنه يحتاج إلى إعادة حساب HTML لكل نتيجة (كلما تم تغيير عنوان URL)، كما يمكن استخدام التخزين المؤقت لكود HTML الناتج ضمن شبكة توصيل المحتوى CDN لتسريع استجابة التطبيق. ويمكن أيضًا تخزين ملفات CSS مؤقتًا بواسطة المتصفح لتحميل الصفحات اللاحقة بسرعة أكبر.

التصيير من جانب الخادم مع المكونات المعززة (SSRH)

المكونات المشبعة أو المعززة Hydrated Components هي مكونات رياكت تعمل كجسر بين نسخ التطبيق التي تنشأ على الخادم والعميل، ولفهم آلية عملها تخيل الآن أنك تحتاج لتطوير تطبيق رياكت كامل الوظائف على العميل، أي تطبيق يتطلب تفاعل المستخدمين ويوفر إمكانية تنقلهم بين الصفحات ويحتاج لجلب البيانات من الخادم. ملاحظة:يشير مصطلح التشبيع أو التعزيز hydration في رياكت إلى الطريقة التي تتصل بها React مع كود HTML الموجود مسبقًا والذي تم تصييره بالفعل بواسطة رياكت في جانب الخادم. فهو عملية يتم فيها ربط أو تعزيز شيفرة جافا سكريبت التفاعلية لمحتوى HTML الثابت المصير مسبقًا على الخادم لجعل كود HTML تفاعليًا. وبالتالي تقوم رياكت بتنفيذ التصيير الأول لصفحات الموقع على الخادم، وترسل محتوى HTML الناتج إضافة إلى ملفات جافا سكريبت إلى العميل، ثم تقوم بإعادة تعزيز الكود المرسل من جانب الخادم، ليصبح التطبيق وكأنه تطبيق تصيير من جانب العميل (CSR) من هذه النقطة فصاعدًا.

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

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

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

هنا تبرز فائدة إطارات العمل مثل NextJS. فهي تختفي التعقيدات المرتبطة بعمليات التوجيه وتقسيم الكود في حالة تصيير الصفحات على الخادم وتعتمد أسلوب التصيير من جانب الخادم مع المكونات المعززة SSRH لتوفر تجربة أكثر سلاسة للمطورين.

التصيير المسبق للمحتوى الثابت (PRS)

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

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

التصيير المسبق مع تفعيل المكونات (PRH)

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

مصفوفة الأداء

لنناقش الآن كيفية تأثير كل مسار من مسارات التصيير التي وضحناها سابقًا على مقاييس أداء مواقع الويب ونعرف أي طريقة منها هي الأفضل من خلال الجدول التالي الذي يعطي نتيجة تتراوح من 1 إلى 5 وتدل النتائج على ما يلي:

1. نتيجة غير مرضية
2. نتيجة ضعيفة 3.نتيجة متوسطة
3. نتيجة جيدة
4. نتيجة ممتازة

يمكن أن نستنتج من الجدول السابق ما يلي:

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

طرق إضافية لتحسين سيو مواقع الويب

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

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

الخاتمة

هذا تكون قد وصلت لنهاية هذا المقال الذي وضحنا فيه أبرز تحديات تحسين محركات البحث في تطبيقات ومواقع رياكت، ووضحنا أهم الاستراتيجيات التقنيات المستخدمة التي يمكنك القيام بها للتغلب عليها لتحسين سيو تطبيقات ومواقع رياكت React الخاصة بك وتحسين فرصك في ظهورها في نتائج البحث.

اقرأ أيضًا

• مقارنة شاملة بين رياكت React و Next.js
• المصطلحات المستخدمة في React
• شمولية تطبيقات React لكافة أنواع المستخدمين
• تقسيم تطبيق React إلى مكونات

نكتشف في هذا المقال الاختلافات بين مكتبة رياكت React وإطار العمل Next.js وهو إطار عمل مشهور لجافا سكريبت تستخدمه شركات عديدة مثل تيك توك TikTok وهولو Hulu ونايكي Nike لتحسين تطبيقات الويب الخاصة بها. كما سنتعرّف على متى وكيف نستخدم Next.js، ونسرد بعض النصائح حول مفهوم العرض أو التصيير rendering والتوجيه والتصفح والتنقل في هذه التطبيقات.

يعدّ Next.js إطار عمل سريع جدًا تعتمد عليه المواقع التي تتطلب في عملها حجم بيانات كبير مثل هولو Hulu ونيتفلكس Netflix. فإذا كنت بالفعل ملمًا بمكتبة ريآكت React، فيجب أن تتعرف بالتأكيد على هذه التقنية التي تزداد انتشارًا يومًا بعد يوم، فعلى الرغم من أن كلاً من React و Next.js يساعدان في تصميم واجهات مستخدم فعالة لمواقع الويب، إلا أنّ لديهما بعض الاختلافات الرئيسية، حيث يعد Next.js أكثر تطورًا وتفصيلًا من React، وهو مناسب تحديدًا للمواقع التي تهتم بتحسين محركات البحث SEO أو التصيير المسبق pre-rendering.

Next.js أم React

ظهر إطار العمل رياكت React أو ما يعرف كذلك باسم ReactJS أو React.js لأول مرة في عام 2013، وهو أكثر شهرة وانتشارًا من Next.js بكثير، ولكن الإطار Next.js الذي صدر عام 2016 بدأ بالانتشار وازدات شعبيته شيئًا فشيئًا وحصل على أكثر من 117 ألف نجمة على جيتهاب GitHub حتى تاريخ شهر يناير 2024 إلى جانب ملايين التنزيلات الأسبوعية له من مدير الحزم npm. دعونا نرى مقارنة بسيطة في الأداء بين Next.js و React التي توضح متى يجب أن نستخدم Next.js ومتى نستخدم React:

• سرعة التطوير: يقدم Next.js ميزات حديثة ومبتكرة تسهل عملية التطوير لتصميم تطبيق React متقدم، ومع إدخال ميزة المجمّع compiler الخاص به في الإصدار Next.js 12، زادت سرعة التطوير فيه أيضًا بالمقارنة مع رياكت React، وبالتالي يقلّل Next.js من الوقت الذي ينتظره المبرمج لتحديث الشيفرة البرمجية، مما يقلّل من الإحباط والوقت الضائع خلال التطوير.

• جلب البيانات وأوقات التحميل: يمكن لإطار Next.js عبور شجرة React والاستعلام عن البيانات الموجودة في الخادم، مما يسمح بالتحميل المُسبق لبيانات الصفحة. وهذا يؤدي في كثير من الأحيان إلى تقليل أوقات تحميل التطبيق للصفحات المصممة باستخدام Next.js مقارنة بالصفحات المكتوبة بإطار React العادي فحسب.

• التصيير وتحسين محركات البحث: يتميز Next.js بميزة التصيير المُسبق، بينما يستخدم React التصيير المُعتمد على المستخدم وتوفر الصفحات المُصيَّرة والمعدة مسبقًا استراتيجيات تحسين محركات بحث فعالة الصعب تحقيقها في تطبيق React عادي.

• التوجيه: يوفر Next.js نظام ملفات مبني ومحدّد مسبقًا لعملية التوجيه routing. ويساهم هذا النظام في تقليل المرونة مقارنة بالخيارات المتنوعة لمكتبة React (مثل مكتبة React Router)، ولكنه يبسّط عملية إعداد الصفحة والتوجيه.

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

دعونا نستكشف بعض حالات استخدام Next.js بمزيد من التفصيل، حتى تتمكن من الإجابة عن السؤال "هل يجب أن أستخدم Next.js؟ في تطبيقات الويب أم لا"

التصيير في Next.js

التصيير rendering هو العملية التي تحول شيفرة React إلى HTML حيث يعرضه المتصفح كواجهة مستخدم ضمن الصفحة. يقدّم Next.js ثلاث طرق للتصيير

• التصيير المعتمد على المستخدم Client-side rendering أو CSR اختصارًا
• تصيير الخادم Server-side rendering أو SSR اختصارًا
• توليد الموقع الثابت static side generation أو SSG اختصارًا
• بالإضافة إلى إعادة التوليد الثابت التدريجي incremental static regeneration أو ISR اختصارًا.

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

1. تصيير المستخدم

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

يكون استدعاء المستخدم ممكنًا لمكونات Next.js باستخدام useEffect أو useSWR في React.

2. تصيير الخادم

يُتيح Next.js أيضًا إنشاء صفحة HTML على الخادم. في هذه الحالة، يتم إرسال شيفرة HTML المُولَّد إلى جانب المستخدم بحيث تظهر واجهة موقع الويب قبل التفعيل. ثم يكون موقع الويب القابل للعرض جاهزًا للاستخدام بعد اكتمال تهيئة جافا سكريبت على جانب المستخدم.

تُضاف بعض دوال التكوين البسيطة إلى الصفحة في الصفحات التي نرغب في أن يؤدي Next.js تصيير الخادم فيها.

3. توليد موقع ثابت

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

يُمكننا تنفيذ SSG على صفحات Next.js التي نرغب في تصميمها بشكل ثابت باستخدام تعليمة ‎‎getStaticProps(‎)‎‎ وتعليمة getStaticPaths()‎، والأخير يحدد المسارات للصفحات الثابتة.

تحسين محركات البحث في Next.js

تسمح السرعة والقدرة على استدعاء جميع صفحات موقع ويب في Next.js لمحركات البحث بتصفح وفهرسة الموقع بسرعة وسهولة، مما يعزز من عملية تحسين محركات البحث. وتحسين محركات البحث أمر ضروري للعديد من الشركات والمواقع الإلكترونية لأن المواقع التي تمّ تحسين محركات البحث فيها بشكل أفضل؛ تظهر في أعلى النتائج عند البحث. والمواقع ذات التصنيف الأعلى تكون أكثر احتمالًا للنقر عليها من قبل المستخدمين، حيث يصل معدل نقر المستخدمين إلى 27.6% للنتيجة الأولى، وهو معدل يزيد عشر مرات عن معدل نقر المستخدمين على النتيجة العاشرة والذي يبلغ 2.4%.

في حين تواجه مواقع React التي تحتوي على كميات كبيرة من المحتوى - الذي يستخدم شيفرة جافا سكريبت للتصيير - تحديات في تحسين محركات البحث عند التعامل مع تصفح وفهرسة جوجل.

ملاحظة: إن قدرة Next.js على التصيير من طرف الخادم بسهولة لا تُحسِّن فقط ترتيب الصفحة على محركات البحث فحسب، بل تُحسِّن أيضًا سرعة التحميل الفعلي للموقع من أجل تجربة مستخدم مثالية.

البدء مع Next.js

لنلقي نظرة على أساسيات تهيئة Next.js والتوجيه والتصفح والتنقل حتى تتمكن من جني فوائد التصيير المسبق وتحسين محركات البحث. قبل البدء تأكد من تحميل أحدث إصدار من Node.js على جهازك. يمكنك التحقق من إصدار Node.js على جهازك باستخدام الأمر

 node --version

وهناك طريقتان لتهيئة مشروع Next.js:

1. تهيئة تلقائية، مع ضبط محدد مسبقًا.
2. تهيئة يدوية مع الضبط.

سنتبع التهيئة التلقائية للبدء في مشروعنا بشكل أسهل. تدير أداة سطر الأوامر CLI أو create-next-app التهيئة التلقائية وتجعل من الممكن تصميم التطبيقات بسرعة. دعونا ننشئ مشروعنا مع دعم Next.js المدمج للغة TypeScript؛ وهي لغة مشتقة من جافا سكريبت تضمن نوع متغيرات صحيح:

npx create-next-app@latest --typescript

سيطلب create-next-app اسم تطبيقك. يجب أن يتكون اسم مشروعك من حروف صغيرة وأن يستخدم الشرطات بدلاً من المسافات. على سبيل المثال، اخترنا الاسم next-js-tutorial. بمجرد اكتمال التهيئة، سترى رسالة نجاح على شاشتك.

يفرض Next.js نظامًا صارمًا لهيكلة الملفات، ففي مشروعنا الجديد سنجد الهيكلية التالية:

• تُنظم الصفحات pages وتنسيق الموقع styles في مجلداتها الخاصة.
• تُخزَّن واجهات برمجة التطبيقات أو API في مجلد pages/api.
• تحفظ البيانات المتاحة للعامة في المجلد public.

التوجيه والصفحات في Next.js

يستخدم Next.js هيكلة الملفات داخل مسار الصفحات pages لتحديد مسارات التطبيق. حيث نعرّف جميع المسارات في مجلد pages، ويُعدّ ملف
pages/index.tsx هو نقطة الدخول للتطبيق حيث نحدد الخطوط المخصصة، وأكواد تتبّع التطبيق، وغيرها من العناصر التي تتطلب وصولًا عامًا.

هناك طريقتان لإضافة مسارات جديدة:

1. إضافة ملف ينتهي بـ .tsx مباشرة في المجلد pages.
2. إضافة ملف index.tsx ضمن مجلد فرعي جديد من المجلد pages (الملفات index توجّه تلقائيًا إلى بداية المجلد).

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

مسارات الصفحة

يمكننا إضافة مسار صفحة أساسي، مثل about-us، باستخدام ملف about-us.tsx:

|— pages
|    |— _app.tsx
|    |— about-us.tsx
|    |— api
|    |— index.tsx

أو يمكننا استخدام ملف index.tsx ضمن مجلد pages/about-us:

|— pages
|    |— _app.tsx
|    |— about-us
|    |    |— index.tsx
|    |— api
|    |— index.tsx

استمر وأضف مسار صفحة about-us.tsx إلى مشروعك.

import styles from '../styles/Home.module.css'

const AboutUs: NextPage = () => {
  return ( 
    <div className={styles.container}>
      <main className={styles.main}>
        <h1 className={styles.title}>
          About Us Example Page
        </h1>
      </main>
    </div>
  )
}

export default AboutUs

سنرى توجيه الصفحة فعليًا عند استخدامها بالتزامن مع التنقل في Next.js. في الوقت الحالي، سنعيد NextPage ككلمة مؤقتة مع سلسلة عنوان حتى يعمل التنقل بشكل صحيح.

المسارات المتداخلة

تسمح المسارات المتداخلة nested routes بإعادة استخدام عدة تخطيطات اختيارية على صفحة (على سبيل المثال، عندما ينقر المستخدم على عنوان URL، قد ترغب في تحديث محتوى الجسم والاحتفاظ بتخطيطات الرأس والتذييل).

|— pages
|    |— _app.tsx
|    |— api
|    |— index.tsx
|    |— parent
|    |    |— child.tsx

نحدد المسار المتداخل/parent/child باستخدام مجلد parent ومجلد أو ملف child متداخل (مثالنا يوضح ملفًا).

المسارات الديناميكية

تسمح المسارات الديناميكية dynamic routes للتخطيطات بالاستجابة للتغييرات في الوقت الحقيقي عندما لا يفي استخدام المسارات المعرفة مسبقًا
pre-defined paths بالغرض. على سبيل المثال، إذا كنا نرغب في إنشاء مسار /product/[productId]‎ (أي عند النقر على منتج، يتوسع مكونه). يُمكننا بسهولة إضافة مسار ديناميكي بافتراض أن productId هو متغير قابل للوصول في تعريفنا لمجلد product، وذلك عبر إنشاء مجلد product وتضمين صفحة productId بين قوسين:

|— pages
|    |— _app.tsx
|    |— api
|    |— index.tsx
|    |— product
|    |    |— [productId].tsx

بهذه الطريقة، سيكون لديك مسار مثل product/testId ستُضبط فيه قوائم الإعدادات (أي productId يُضبط إلى testId).

أخيرًا، من الممكن أيضًا دمج تقنيات التوجيه. على سبيل المثال، يُمكننا إنشاء مسار ديناميكي مُتداخِل pages/post/[postId]/[comment].tsx.

التنقل في Next.js

يستخدم Next.js مكونات Link خاصة به بدلاً من وسم <a> في HTML عند التنقل بين صفحات المستخدم للسماح لـNext.js بتحسين التنقل واسترجاع البيانات مسبقًا. يعمل Link بشكل مماثل لوسم <a> ويستخدم href كالمسار الذي سيتم فتحه. يجب عليك استخدام خاصية passHref لإجبار Link على تمرير قيمة مساره إلى المكونات الفرعية (على سبيل المثال، عند استخدام مكونات مخصصة المظهر).

<p className={styles.description}>
  Here's our example <Link href="/about-us">About Us</Link> page
</p> 

الفائدة الرئيسية من استخدام Link بدلاً من وسم <a> هي أنه يحمّل البيانات مسبقًا في الخلفية عندما يضغط المستخدم فوق الرابط أو بالقرب منه. يجعل هذا المحتوى متاحًا بشكل أكبر للمستخدم لمعالجته، مما يؤدي إلى تحسين أداء التطبيق. وما زال بإمكانك استخدام وسم <a> في Next.js عند الربط بصفحات خارجية خارج التطبيق.

على سبيل المثال للربط بصفحة About Us من مشروع Next.js، افتح ملف التطبيق الرئيسي pages/index.tsx. سنستورد أولًا مكون الرابط Link من next/link، ثم نضيف فقرة مرتبطة تحت مكون<h1>:

الآن يمكننا تشغيل التطبيق باستخدام الأمر npm run dev، اذهب إلى http://localhost:3000، ثم شاهد النص المضاف وصفحة About Us تعمل على http://localhost:3000/about-us (المسار المُعاد بعد النقر على About Us).

الخلاصة

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

أسئلة شائعة

نختم مقالنا بمجموعة من الأسئلة الشائعة المتعلقة بإطار عمل Next.js ورياكت React

1. لماذا أستخدم Next.js؟

يجعل Next.js من عملية بناء بعض واجهات مواقع الويب عملية أسهل كما يضيف مزايا على React، ويقدّم مجتمعًا قويًا وتوثيقًا جيدًا، كما أنه يكسب شعبية كبيرة بين مطوري الواجهات الأمامية.

2. هل React أفضل من Next.js؟

لا، React ليس أفضل من Next.js، يجب على المطورين أن يختاروا إطار العمل بناءً على ما يصلح لمشروعهم وبناءً على أولوياتهم (قد يستفيد موقع يركّز على تحسين محركات البحث من Next.js على سبيل المثال، وذلك بالنظر إلى أنه يقلّل من وقت تحميل التطبيق).

3. لم يُنظر إلى Next.js بكونه أفضل من React؟

يقدم Next.js تحسينات على سرعة التطوير ويقلل من وقت تحميل التطبيق، كما يحتوي على التصيير المسبق.

4. ما الفرق بين Next.js و React؟

إن Next.js إطار عمل مبني على React مع بعض المزايا المُضافة بشكل افتراضي، React هو مكتبة جافا سكريبت شائعة تُستخدم لبناء واجهات المستخدم التفاعلية، بالأخص في تطبيقات الويب.

5. ما هي المشاكل التي يحلها Next.js؟

يقدّم Next.js التصيير المسبق ويمكن أن يحسن من نتائج الموقع على محركات البحث مع تقليل وقت التحميل.

6. لم قد أختار React.js؟

يعدّ React إطارًا أقلّ تحكمًا وأكثر شعبية من Next.js ويقدم للمطورين زيادة في المرونة وموارد عديدة.

7. هل React وReact.js يشيران للشيء ذاته؟

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

8. هل يعد Next.js إطار عمل؟

نعم، Next.js إطار عمل مفتوح المصدر مبني على React.

ترجمة -وبتصرف- للمقال Next.js vs React: A Comparative Tutorial لصاحبه Ayyaz Ali

اقرأ أيضًا

• كل ما تود معرفته عن إطار ريآكت نيتف React Native
• المصطلحات المستخدمة في React
• مصادر تعلم مكتبة React لبناء تطبيقات الويب
• مقدمة إلى Node.js

ستتعرف في مقال اليوم على رياكت نيتف React Native أحد أشهر أطر عمل لغة البرمجة جافا سكريبت JavaScript والذي يمكنك من خلاله إنشاء تطبيقات جوال متعددة المنصات تعمل على نظامي التشغيل أندرويد Android و أي أو إس iOS بسهولة ومرونة.

ما هو React Native

ريآكت نيتف React Native هو إطار عمل framework مفتوح المصدر للغة البرمجة جافا سكريبت JavaScript طورته شركة ميتا Meta أو فيسبوك سابقًا عام 2015 لتمكن المطورين من تطوير الواجهات الأمامية لتطبيقات الجوال متعددة المنصات cross platform، أي أن التطبيقات المطورة باستخدام هذا الإطار يمكنها العمل على أنظمة تشغيل الجوال الأساسية مثل أندرويد Android وآي أو إس iOS بذات الوقت.

تتميز التطبيقات المطورة باستخدام ريأكت نيتف React Native بكونها تشبه التطبيقات الأصيلة Native apps وأسلوب تطوير تطبيقات أصيلة هو أحد أساليب تطوير تطبيقات الجوال المصممة للعمل على نظام تشغيل محدد فقط، فكي تتمكن من تطوير تطبيق جوال أصيل تحتاج لأن تبرمج التطبيق بلغة البرمجة الأم الخاصة بكل نظام تشغيل على حدا مثل لغة Objective-C أو Swift لنظام أندرويد ولغة جافا Java أو كوتلن Kotlin لنظام iOS.

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

استخدامات React Native

يتيح لك إطار React Native إنشاء تطبيقات الهاتف المحمول وتطوير واجهات مستخدم تفاعلية وغنية بالمميزات لا يمكن تمييزها عن التطبيقات الأصيلة المبنية باللغات الأساسية للمنصات بسرعة وسهولة باستخدام لغة جافا سكريبت JavaScript ومكتبة ريآكت React.

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

إيجابيات إطار React Native

إذا كنت تفكر في برمجة تطبيق جوال فإن استخدام إطار React Native خيار مناسب ويوفر لك العديد من المميزات التي قد لا تتوفر في أطر العمل الأخرى، ومن أبرز هذه المميزات:

• يعتمد إطار عمل ريآكت نيتف React Native على لغة البرمجة جافا سكريبت JavaScript التي تعد واحدة من أشهر وأقوى لغات البرمجة وأسهلها في التعلم.
• يمكن من خلال ريآكت نيتف برمجة تطبيقات متوافقة مع أنظمة الجوال الأساسية أندرويد Android و آي أو إس iOS بسهولة وسرعة وبأقل وقت وتكلفة باستخدام نفس الكود البرمجي.
• يمكن من خلاله تطوير تطبيقات فعالة قادرة على الوصول لموارد الهاتف مثل الكاميرا و الموقع ولها نفس مظهر التطبيقات الأخرى على الهاتف مما يحسن تجربة المستخدم.
• يملك إطار ريآكت نيتف شعبية هائلة بين أوساط المطورين فقد حصل على أكثر من 112 نجمة على مستودع Github، كما يملك مجتمع دعم كبير ونشط يوفر ميزات وأدوات جديدة باستمرار كما يوفر مصادر تعلم منوعة تساعدك في التعلم وحل أي مشكلة تواجهك.
• يستخدم ريآكت نيتف في تطوير تطبيقات العديد من الشركات الكبرى ومن أبرزها تطبيق التواصل الاجتماعي فيسبوك، كما تستخدمه شركة إنستغرام Instagram وشوبيفاي Shopify وديسكورد Discord وغيرها ما يعزز من شهرته وموثوقيته.
• يوفر الكثير من المكتبات والحزم والمكونات مفتوحة المصدر التي يمكن إعادة استخدامها بسهولة لتطوير تطبيقات جوال بوظائف ومميزات احترافية دون الحاجة لكتابة كافة الأكواد من الصفر ومن أبرزها مكتبة React Navigation التي تبسط عمليات التنقل ضمن شاشات التطبيق المختلفة.
• يوفر ميزة إعادة التحميل السريع (hot reloading) التي تمكن المطور من رؤية التغييرات التي يجريها على التطبيق مباشرة دون الحاجة لإيقافه وإعادة تشغيله، أي بمجرد إنشاء تطبيقك يمكنك عكس أي تعديل في التعليمات البرمجية على وظائف التطبيق دون الحاجة إلى إعادة بنائه وهذه الميزة تسرع عمل مبرمج التطبيقات وتزيد إنتاجيته.
• يوفر الكثير من الأدوات المساعدة التي تسهل عمل المطورين مثل منصة Expo التي توفر مجموعة من الأدوات والخدمات التي تسرع بشكل كبير إعداد بيئة العمل وبناء تطبيقات React Native وتعديلها وتصحيح أخطائها ونشرها.

سلبيات إطار React Native

لا يخلو إطار ريآكت نيتف React Native من بعض العيوب شأنه شأن أي تقنية أخرى، ومن بينها نذكر:

• لا توفر المكونات القياسية في إطار ريآكت نيتف React Native كافة المميزات التي يحتاجها المطور لذا قد يضطر لاستيراد مكتبات خارجية لتضمينها، واستخدام الكثير من المكتبات الخارجية قد يؤثر على أداء التطبيق كما أنها قد تؤثر على أمانه إذا لم تحدّث بصورة مستمرة.
• قد لا تتوفر في بعض المكتبات الخارجية ومكونات الطرف الثالث التي يحتاج المطور لاستخدامها توثيقات مساعدة ووافية حول طريقة استخدامها والتعامل معها.
• قد تكون التطبيقات التي تتضمن الكثير من عمليات المعالجة بطيئة نسييًا، لكون لغة جافا سكريبت JavaScript غير مناسبة بشكل عام للمعالجة الثقيلة، أما بالنسبة للتطبيقات التي تحتاج فقط للتفاعل مع واجهات برمجة التطبيقات API أو التعامل مع قواعد البيانات فهو مناسب تمامًا.

الفرق بين رياكت نيتف وفلاتر

يتنافس إطار ريآكت نيتف React Native مع إطار فلاتر Flutter مفتوح المصدر الذي طورته جوجل عام 2017 هو لا يقل شهرة عن ريآكت نيتف حيث يملك أكثر من 157.6 ألف نجمة على موقع GitHub ويتميز بسرعته واستقراره.

يملك كلا الإطارين الكثير من المميزات المتشابهة وكلاهما خيار مناسب لتطوير تطبيقات الجوال متوافقة مع مختلف الأنظمة الأساسية باستخدام نفس التعليمات البرمجية، لكن الاختلاف الأساسي بينهما هو أن ريآكت نيتف يستخدم لغة جافا سكربيت المشهورة، أما فلاتر فيستخدم لغة دارت Dart وهي لغة برمجة قوية وعالية الأداء طورتها جوجل لكنها لا تستخدم على نطاق واسع بين أوساط المبرمجين.

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

وبالطبع يعتمد اختيار إطار العمل على متطلبات تطبيقك وخبرتك فإذا كنت على دراية بلغة برمجة جافا سكريبت فسيكون ريآكت نيتف الخيار الأنسب وإذا كنت تهتم بسرعة وأداء التطبيق فمن الأنسب اختيار فلاتر.

الفرق بين رياكت ورياكت نيتف

تعد كل من ريآكت React و ريآكت نيتف React Native تقنيتين شائعتين في تطوير التطبيقات وكلاهما مطور من قبل فيسبوك وكثيرًا ما يخلط المبتدئون بينهما بسبب تشابه أسمائهما لكن هناك أيضًا فروقات بينهما.

حيث أن ريآكت React أو ما يعرف كذلك باسم ReactJS أو React.js هي مكتبة جافا سكريبت مفتوحة المصدر مشهورة لتطوير تطبيقات الويب ذات الصفحة الواحدة Single Page Apps أو اختصارًا SPA وهي تطبيقات تعتمد على تقنيات الويب وتسمح للمطورين بإنشاء واجهات مستخدم UI تفاعلية جميلة وأنيقة باستخدام مكونات قابلة لإعادة الاستخدام وتسهل وتسرع عمل المطورين وتستخدم هذه المكتبة لغة خاصة توسع لغة جافا سكريبت وتشبه HTML تسمى JSX.

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

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

خطوات تعلم إطار العمل رياكت نيتف React Native

يحتاج تعلم إطار React Native لتأسيس في بعض التقنيات قبل البدء كي تتمكن من تعلمه بسهولة وسلاسة، وإليك أهم خطوات تعلم إطار React Native

• تعرف على تقنيات تطوير تطبيقات الويب الأساسية مثل HTML و CSS ومفهوم نموذج كائن المستند DOM فبالرغم من أنك لن تكتب أكوادها مباشرة في تطبيقات React Native إلا أنها تشكل أساسًا لفهم تقنيات أخرى ستحتاجها.
• ركز على تعلم تخطيط flexbox في CSS فإطار React Native يستخدمه بشكل أساسي لتخطيط عناصر الواجهات.
• تعلم أساسيات لغة جافا سكريبت JavaScript وتعرف من خلالها على أساسيات البرمجة ومبادئها ومصطلحاتها الأساسية مثل المتغيرات والحلقات التكرارية والشروط والوظائف البرمجية وهياكل البيانات.
• تعلم كيفية استخدام واجهة برمجة التطبيقات API وإجراء الطلبات منها والحصول على البيانات وعرضها في تطبيقاتك.
• يمكنك كخطوة اختيارية تعلم مكتبة React وصيغة JSX التي تستخدمها لإنشاء مكونات واجهة المستخدم قبل الانتقال إلى تعلم إطار العمل React Native فهو كما ذكرنا سابقًا مبني على أساسها وتعلمها سيكون خطوة مفيدة تسهل الخطوات اللاحقة.
• تعلم كيفية كتابة التنسيقات لمكونات تطبيقاتك لإنشاء واجهات مستخدم أنيقة واحترافية لتطبيقات الهواتف المحمولة.
• ابدأ بتعلم إطار React Native وإعداد بيئة التطوير وتعلم طريقة استخدام سطر الأوامر في تطوير الويب من طرف العميل وأهما أدوات سطر الأوامر مثل npm وتعرف على طريقة استخدام أدوات مطور الويب المدمجة في المتصفحات لتصحيح الأخطاء.
• تعلم أساسيات React Native وأهم المكونات التي يوفرها لتطوير التطبيقات لنظامي iOS وAndroid.
• ابدأ بتطوير تطبيقات ريآكت نيتف بسيطة مثل تطبيق آلة حاسبة تطبيق أو تطبيق تدوين ملاحظات أو تطبيق توليد كلمات المرور فالممارسة العملية ضرورية لتعزيز كل ما تعلمته من مفاهيم نظرية حول ريأكت نتيف.
• انتقل لتطوير تطبيقات ريآكت نيتف متكاملة لبناء معرض أعمال خاص بك وتدرب من خلالها على كافة خطوات تطوير التطبيقات الأصيلة بدءًا من تحديد فكرة التطبيق حتى مرحلة نشره وإصداره على كل منصة.

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

مصادر تعلم رياكت نيتف React Native

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

وإذا كنت تفضل التعلم من الكتب فقد وفرت أكاديمية حسوب العديد من الكتب المميزة والمجانية باللغة العربية التي تساعدك على تعلم الكثير حول لغة البرمجة جافا سكريبت والعديد من اللغات والتقنيات الأخرى.

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

الخلاصة

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

هل أنت مهتم ببناء تطبيقات الهواتف المحمولة ولديك أي تساؤل حول استخدامات React Native في هذا المجال؟ لا تتردد في طرح سؤالك في قسم التعليقات أسفل المقال.

اقرأ أيضًا

• مدخل إلى React Native
• مصادر تعلم مكتبة React لبناء تطبيقات الويب
• مقدمة إلى أطر عمل تطوير الويب من طرف العميل
• خطوات برمجة تطبيق للمبتدئين
• مدخل إلى التحريك في React Native
• برمجة تطبيقات الأندرويد

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

اختبار تطبيقات React Native

سنحتاج إلى إطار عمل للاختبارات عند البدء باختبار أي نوع من الشيفرة، لتنفيذ مجموعة من الحالات المختبرة، والتدقيق في نتائجها. فلاختبار تطبيق جافا سكربت JavaScript سنجد أن إطار العمل Jest هو الأكثر شعبية لأداء المهمة. ولاختبار تطبيقات React Native المبنية على المنصة Expo باستخدام Jest، ستزودنا Expo بمجموعة من إعدادات تهيئة على هيئة مجموعة جاهزة تدعى jest-expo. ولكي نستخدم المدقق ESLint في ملف اختبار Jest، سنحتاج إلى الإضافة eslint-plugin-jest الخاصة به. لنبدأ إذًا بتثبيت الحزم:

npm install --save-dev jest jest-expo eslint-plugin-jest

لاستخدام المجموعة jest-expo في Jest، لا بدّ من إضافة إعدادات التهيئة التالية في الملف "package.json"، مع سكربت الاختبار:

{
  // ...
  "scripts": {
    // other scripts...
    "test": "jest"
  },
  "jest": {    
      "preset": "jest-expo",    
      "transform": {      
          "^.+\\.jsx?$": "babel-jest"
      },    
      "transformIgnorePatterns": [
     "node_modules/(?!((jest-)?react-native|@react-native(-community)?)|expo(nent)?|@expo(nent)?/.*|@expo-google-fonts/.*|react-navigation|@react-navigation/.*|@unimodules/.*|unimodules|sentry-expo|native-base|react-native-svg|react-router-native)"

      ]
  },
  // ...
}

يطلب الخيار transform من Jest تحويل شيفرة الملفين "js." و"jsx." باستخدام مصرّف Babel. بينما يُستخدم الخيار transformIgnorePatterns لتجاهل مجلدات محددة ضمن المجلد "node_modules" أثناء تحويل الملفات. وتتطابق تقريبًا إعدادات Jest هذه مع تلك المقترحة في توثيق Expo.

لاستخدام الإضافة eslint-plugin-jest، لا بدّ من وضعها ضمن مصفوفة الإضافات والموسِّعات في الملف "eslintrc.".

{
  "plugins": ["react", "react-native"],
  "settings": {
    "react": {
      "version": "detect"
    }
  },

 "extends": ["eslint:recommended", "plugin:react/recommended", "plugin:jest/recommended"],
 "parser": "@babel/eslint-parser",
  "env": {
    "react-native/react-native": true
  },
  "rules": {
    "react/prop-types": "off",
    "react/react-in-jsx-scope": "off"
  }
}

وللتأكد من نجاح التهيئة، أنشئ المجلد "tests" في المجلد "src"، ثم أنشئ ضمنه الملف "example.js" وضع فيه الشيفرة التالية:

describe('Example', () => {
  it('works', () => {
    expect(1).toBe(1);
  });
});

لننفذ الآن هذا المثال من خلال الأمر: npm test. ينبغي أن يشير خرج العملية إلى نجاح الاختبار المتواجد في الملف "src/tests/example.js".

تنظيم الاختبارات

تقتضي إحدى طرق تنظيم ملفات الاختبارات بوضعها في مجلد وحيد يُدعى "tests". ويفضّل عند استخدام هذه الطريقة وضع ملفات الاختبار ضمن المجلدات الفرعية الملائمة كما نفعل مع ملفات الشيفرة، إذ ستُوضع الاختبارات التي تتعلق بالمكوّنات مثلًا في المجلّد "components"، وتلك التي تتعلق بالخدمات ستُوضع في المجلّد "utils"، وهكذا. سينتج عن هذا التنظيم الهيكلية التالية:

src/
  __tests__/
    components/
      AppBar.js
      RepositoryList.js
      ...
    utils/
      authStorage.js
      ...
    ...

أما الطريقة الأخرى فهي وضع ملف الاختبار بجانب ملف الشيفرة الذي سيستخدمه. ويعني ذلك أننا سنضع الملف الذي يتضمن اختبارات للمكوّن AppBar مثلًا في نفس المجلد الذي يحتوي شيفرة هذا المكوّن. وستنتج عن هذه الطريقة في التنظيم الهيكلية التالية:

src/
  components/
    AppBar/
      AppBar.test.jsx
      index.jsx
    ...
  ...

شيفرة المكوّن في المثال السابق موجودةٌ في الملف "index.jsx"، بينما ستجد الاختبارات في الملف "AppBar.test.jsx". ولكي تجد بسهولة الملفات التي تحتوي الاختبارات، عليك أن تضعها في المجلد "tests" أو في ملفات تحمل إحدى اللاحقتين "test." أو "spec."، أو أن تهيئ يدويًا الأنماط العامة global patterns.

اختبار المكونات

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

تعرّفنا في القسم 5 على إحدى هذه المكتبات وهي React Testing Library. لكن لسوء الحظ فهذه المكتبة مخصصة فقط لاختبار تطبيقات الويب المبنية باستخدام React. لكن بالطبع هناك مقابل لها في React Native وهي المكتبة React Native Testing Library التي سنستخدمها في اختبار مكوّنات تطبيقات React Native. وكما ذكرنا فإن جميع هذه المكتبات تتشارك بنفس الواجهة البرمجية، ولن تضطر إلى تعلّم الكثير من المفاهيم الجديدة. بالإضافة إلى هذه المكتبة، سنحتاج إلى مجموعة من مُطابقات Jest مخصصة للمكتبة مثل toHaveTextContent و toHaveProp. تزوّدنا المكتبة jest-native بهذه المُطابقات، لذلك لا بدّ أولًا من تثبيت هذه الحزم:

npm install --save-dev react-test-renderer@17.0.1 @testing-library/react-native @testing-library/jest-native

ملاحظة: إذا واجهت مشاكل في اعتمادية النظير peer، فتأكد من مطابقة إصدار react-test-renderer مع نسخة react للمشروع في أمر npm install المذكور أعلاه. يمكنك التحقق من إصدار react من خلال تنفيذ الأمر:

npm list react --depth=0

وفي حال فشل التثبيت بسبب مشكلات اعتمادية النظير، فحاول مرةً أخرى باستخدام الراية ‎--legacy-peer-deps في الأمر npm install.

لنتمكن من استخدام هذه المُطابقات، علينا توسيع الكائن expect العائد للمكتبة Jest. ويجري تنفيذ ذلك باستخدام ملف إعداد عام. لذلك أنشئ الملف "setupTests.js" في المجلد الجذري لمشروعك، وهو نفسه المجلد الذ++ي يحتوي الملف "package.json". أضف الشيفرة التالية إلى هذا الملف:

import '@testing-library/jest-native/extend-expect';

هيئ الملف السابق على انه ملف إعداد ضمن أوامر تهيئة Jest الموجودة في الملف "package.json":

{
  // ...
  "jest": {
    "preset": "jest-expo",
    "transform": {
      "^.+\\.jsx?$": "babel-jest"
    },
    "transformIgnorePatterns": [
      "node_modules/(?!(jest-)?react-native|react-clone-referenced-element|@react-native-community|expo(nent)?|@expo(nent)?/.*|react-navigation|@react-navigation/.*|@unimodules/.*|unimodules|sentry-expo|native-base|@sentry/.*|react-router-native)"
    ],
    "setupFilesAfterEnv": ["<rootDir>/setupTests.js"]
  }
  // ...
}

تعتمد المكتبة على مفهومين أساسيين هما الاستعلامات (query) وإطلاق الأحداث (fire event)؛ إذ تُستخدم الاستعلامات لاستخلاص مجموعة من العقد من المكوّن الذي يُصيّر بواسطة الدالة render، ونستفيد منها في اختبار وجود عنصر أو كائن ما، مثل نص معين، ضمن المكوّن المُصيَّر. يمكنك تحديد العقد باستخدام الخاصية testID ثم الاستعلام عنها باستخدام الدالة getByTestId. تقبل جميع المكوّنات البنيوية في الخاصية testID. وإليك مثالًا عن كيفية استخدام الاستعلامات:

import { Text, View } from 'react-native';
import { render } from '@testing-library/react-native';

const Greeting = ({ name }) => {
  return (
    <View>
      <Text>Hello {name}!</Text>
    </View>
  );
};

describe('Greeting', () => {
  it('renders a greeting message based on the name prop', () => {
    const { debug, getByText } = render(<Greeting name="Kalle" />);

    debug();

    expect(getByText('Hello Kalle!')).toBeDefined();
  });
});

تعيد الدالة render الاستعلامات ودوال مساعدة أخرى مثل الدالة debug التي تطبع شجرة React بطريقة واضحة بالنسبة للمستخدم. استخدم هذه الدالة إن كنت غير متأكد من شكل المكوّن الذي صيَّرته الدالة render. يمكننا أن نحصل على العقدة Text التي تحتوي نصًا محددًا عن طريق الدالة getByText. وللاطلاع على كل الاستعلامات المتاحة، راجع توثيق المكتبة React Native Testing. يُستخدم المُطابق toHaveTextContent للتأكد من أن المحتوى النصي للعقدة صحيح. وللاطلاع كذلك على كل المُطابقات الخاصة بالمكتبة React Native، راجع توثيق jest-native. وتذكر أنك ستجد معلومات عن كل مُطابقٍ عام في توثيق Jest.

أما المفهوم الثاني الذي ترتكز عليه المكتبة React Native Testing في عملها هو إطلاق الأحداث firing events، إذ يمكننا إطلاق حدث ضمن عقدة معينة باستخدام توابع الكائن fireEvent. سنستفيد من ذلك على سبيل المثال في طباعة نص ضمن حقل نصي أو على زر. وإليك مثال عن اختبار تسليم نموذج بسيط:

import { useState } from 'react';
import { Text, TextInput, Pressable, View } from 'react-native';
import { render, fireEvent } from '@testing-library/react-native';

const Form = ({ onSubmit }) => {
  const [username, setUsername] = useState('');
  const [password, setPassword] = useState('');

  const handleSubmit = () => {
    onSubmit({ username, password });
  };

  return (
    <View>
      <View>
        <TextInput
          value={username}
          onChangeText={(text) => setUsername(text)}
          placeholder="Username"
        />
      </View>
      <View>
        <TextInput
          value={password}
          onChangeText={(text) => setPassword(text)}
          placeholder="Password"
        />
      </View>
      <View>
        <Pressable onPress={handleSubmit}>
          <Text>Submit</Text>
        </Pressable>
      </View>
    </View>
  );
};

describe('Form', () => {
  it('calls function provided by onSubmit prop after pressing the submit button', () => {
    const onSubmit = jest.fn();
    const { getByPlaceholderText, getByText } = render(<Form onSubmit={onSubmit} />);

    fireEvent.changeText(getByPlaceholderText('Username'), 'kalle');
    fireEvent.changeText(getByPlaceholderText('Password'), 'password');
    fireEvent.press(getByText('Submit'));

    expect(onSubmit).toHaveBeenCalledTimes(1);

    // تحوي أول وسيط من أول استدعاء onSubmit.mock.calls[0][0]
    expect(onSubmit.mock.calls[0][0]).toEqual({
      username: 'kalle',
      password: 'password',
    });
  });
});

نريد في هذا الاختبار أن نتأكد من أنّ الدالة onSubmit ستُستدعى على نحوٍ صحيح بعد أن تُملأ حقول النموذج باستخدام التابع fireEvent.changeText ويُضغط على الزر باستخدام التابع fireEvent.press. ولتحري إذا ما استُدعيت الدالة onSubmit وبأية وسطاء، يمكن استخدام الدالة المقلّدة mock function؛ والدوال المقلدة هي دوال ذات سلوك مبرمج مسبقًا كأن تعيد قيمةً محددة. كما يمكننا تحديد توقّعات expectations لهذه الدوال، فمثلًا "توقّع أن الدالة المقلّدة قد استدعيت مرةً واحدة". يمكنك الاطلاع على قائمة بكل التوقعات المتاحة في توثيق توقعات Jest.

عدّل وجرّب في تلك الأمثلة السابقة، وأضف اختبارات جديدة في المجلد "tests "، بحيث تتأكد من فهمك للأفكار السابقة قبل الغوص أعمق في موضوع الاختبارات.

التعامل مع الاعتماديات أثناء الاختبارات

يُعد اختبار المكوّنات سهلًا نوعًا ما لأنها صرفة بشكلٍ أو بآخر. فلا تعتمد المكوّنات الصرّفة على التأثيرات الجانبية side effects، مثل طلبات الشبكة أو استخدام واجهات برمجية أصيلة، مثل AsyncStorage. فالمكوّن Form ليس صرفًا بقدر المكون Greeting، لأن تغيرات حالته قد تُعد أثرًا جانبيًا. لكن الاختبارات تبقى سهلةً مع ذلك.

لنلقِ الآن نظرةً على استراتيجية لاختبار المكوّنات مع الآثار الجانبية، وسنختار على سبيل المثال المكوّن RepositoryList من تطبيقنا. لهذا المكوّن حاليًا أثر جانبي واحد وهو استعلام GraphQl الذي يحضر قائمة بالمستودعات المقيّمة. يُستخدم المكوّن حاليًا كالتالي:

const RepositoryList = () => {
  const { repositories } = useRepositories();

  const repositoryNodes = repositories
    ? repositories.edges.map((edge) => edge.node)
    : [];

  return (
    <FlatList
      data={repositoryNodes}
      // ...
    />
  );
};

export default RepositoryList;

ينتج التأثير الجانبي عن استخدام الخطاف useRepositories الذي يرسل استعلام GraphQL. هناك عدة طرق لاختبار المكوّن، إحدى هذه الطرق هي تقليد استجابات المكتبة Apollo Client كما هو مشروح في توثيقها. أما الطريقة الأبسط هي افتراض أن المكوّن يعمل كما نتوقع (ويُفضل من خلال اختباره)، ثم استخلاص الشيفرة "الصرفة" له ووضعها في مكوّن آخر مثل RepositoryListContainer:

export const RepositoryListContainer = ({ repositories }) => {
  const repositoryNodes = repositories
    ? repositories.edges.map((edge) => edge.node)
    : [];

  return (
    <FlatList
      data={repositoryNodes}
      // ...
    />
  );
};

const RepositoryList = () => {
  const { repositories } = useRepositories();

  return <RepositoryListContainer repositories={repositories} />;
};

export default RepositoryList;

يحتوي المكوّن الآن التأثيرات الجانبية فقط وتنفيذه سهل. يمكن اختبار المكوّن RepositoryListContainer بتمرير بيانات عن مستودع من القائمة من خلال الخاصية repositories، والتأكد أنّ معلومات المحتوى المُصيَّر صحيحة.

التمرينان 10.17 - 10.18

10.17 اختبار قائمة المستودعات المقيمة

أنجز اختبارًا يتأكد أن المكوّن RepositoryListContainer سيصيِّر بصورةٍ صحيحة كلًا من: اسم المستودع ووصفه واللغة وعدد التشعبات وعدد النجوم ومعدل التقييم وعدد التقييمات. تذكر أنه بالإمكان الاستفادة من المطابق toHaveTextContent في التحقق من احتواء العقدة على سلسلة نصية محددة.

const RepositoryItem = (/* ... */) => {
  // ...

  return (
    <View testID="repositoryItem" {/* ... */}>
      {/* ... */}
    </View>
  )
};

كما يمكنك استخدام الاستعلام getAllByTestId للحصول على كل العقد التي تمتلك قيمة محددة للخاصية testID على هيئة مصفوفة، وإن كنت غير متأكد من المكوّن الذي صُيَّر، استفد من الدالة debug في تفكيك نتيجة التصيير.

const repositoryItems = getAllByTestId('repositoryItem');
const [firstRepositoryItem, secondRepositoryItem] = repositoryItems;

// توقع شيئًا من عنصر المستودع الأول والثاني

استخدم الشيفرة التالية أساسًا لاختبارك:

describe('RepositoryList', () => {
  describe('RepositoryListContainer', () => {
    it('renders repository information correctly', () => {
      const repositories = {
        pageInfo: {
          totalCount: 8,
          hasNextPage: true,
          endCursor:
            'WyJhc3luYy1saWJyYXJ5LnJlYWN0LWFzeW5jIiwxNTg4NjU2NzUwMDc2XQ==',
          startCursor: 'WyJqYXJlZHBhbG1lci5mb3JtaWsiLDE1ODg2NjAzNTAwNzZd',
        },
        edges: [
          {
            node: {
              id: 'jaredpalmer.formik',
              fullName: 'jaredpalmer/formik',
              description: 'Build forms in React, without the tears',
              language: 'TypeScript',
              forksCount: 1619,
              stargazersCount: 21856,
              ratingAverage: 88,
              reviewCount: 3,
              ownerAvatarUrl:
                'https://avatars2.githubusercontent.com/u/4060187?v=4',
            },
            cursor: 'WyJqYXJlZHBhbG1lci5mb3JtaWsiLDE1ODg2NjAzNTAwNzZd',
          },
          {
            node: {
              id: 'async-library.react-async',
              fullName: 'async-library/react-async',
              description: 'Flexible promise-based React data loader',
              language: 'JavaScript',
              forksCount: 69,
              stargazersCount: 1760,
              ratingAverage: 72,
              reviewCount: 3,
              ownerAvatarUrl:
                'https://avatars1.githubusercontent.com/u/54310907?v=4',
            },
            cursor:
              'WyJhc3luYy1saWJyYXJ5LnJlYWN0LWFzeW5jIiwxNTg4NjU2NzUwMDc2XQ==',
          },
        ],
      };

      // أضف شيفرة اختبارك هنا
    });
  });
});

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

10.18 اختبار نموذج تسجيل الدخول

أنجز اختبارًا يتحقق أن الدالة onSubmit ستُستدعى بوسطاء مناسبين عندما يُملأ حقلي اسم المستخدم وكلمة المرور في النموذج ويُضغط على زر الإرسال. ينبغي أن يكون الوسيط الأول كائنًا يمثّل قيم النموذج، ويمكنك إهمال بقية وسطاء الدالة. تذكر أنك قد تستعمل توابع fireEvent لتنفيذ أحداث ودوال مقلِّدة للتحقق من استدعاء معالج الحدث onSubmit أو لا.

لا حاجة لاختبار أي شيفرة متعلقة بالمكتبة Apollo Client أو AsyncStorage والموجودة في الخطاف useSignIn. وكما فعلنا في التمرين السابق، استخلص الشيفرة الصرفة وضعها في مكوّن خاص واختبره.

انتبه إلى إرسالات نماذج Formik فهي غير متزامنة، فلا تتوقع استدعاء الدالة onSubmit مباشرة بعد الضغط على زر الإرسال. يمكنك الالتفاف على المشكلة بجعل دالة الاختبار دالة غير متزامنة باستخدام التعليمة Async واستخدام الدالة المساعدة waitFor العائدة للمكتبة React Native Testing. كما يمكنك يمكن أن تستخدم الدالة waitFor لانتظار تحقق التوقعات. فإن لم يتحقق التوقع خلال فترة محددة، سترمي الدالة خطأً. إليك مثالًا يشير إلى أسلوب استخدام هذه الدالة:

import { render, fireEvent, waitFor } from '@testing-library/react-native';
// ...

describe('SignIn', () => {
  describe('SignInContainer', () => {
    it('calls onSubmit function with correct arguments when a valid form is submitted', async () => {
  //صيّر المكوّن ثم املأ الحقول النصية ثم اضغط زر الإرسال
      await waitFor(() => {
  // توقع أن تُستدعى دالة الإرسال مرة واحد وأن يكون الوسيط الأول صحيحًا

      });
    });
  });
});

توسيع التطبيق

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

التمرينات 10.19 - 10.24

10.19: واجهة لعرض مستودع واحد

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

ستجد عنوان المستودع ضمن الحقلurl العائد للنوع "Repository" في تخطيط GraphQL. تستطيع إحضار مستودع واحد من خادم Apollo بإجراء الاستعلام repository. يُمرَّر إلى هذا الاستعلام وسيط واحد وهو المعرّف المميز id للمستودع. إليك مثالًا عن استخدام الاستعلام repository.

{
  repository(id: "jaredpalmer.formik") {
    id
    fullName
    url
  }
}

اختبر استعلامك كما هو معتاد في أرضية عمل Apollo قبل استخدامه في التطبيق. إن لم تكن على دراية بتخطيط GrapQL أو الاستعلامات التي يتيحها، افتح النافذة "docs" أو النافذة "schema" في أرضية عمل GraphQL. وإن واجهتك صعوبة في استخدام المعرف id مثل متغير في الاستعلام، توقف قليلًا لتطلع على توثيق Apollo Client بما يخص الاستعلامات.

لتطلع على طريقة التوجه إلى عنوان URL في المتصفح، اقرأ توثيق Expo حول واجهة الربط البرمجية Linking API، لأنك ستحتاج ذلك عند تنفيذك للزر الذي يفتح المستودع في GitHub.

ينبغي أن تمتلك واجهة العرض عنوانًا خاصًا بها، ومن الجيد أن تحدد المعرّف المميز id للمستودع ضمن المسار الذي يوجهك نحو هذا العنوان مثل معامل مسار، كي تستطيع الوصول إليه باستخدام الخطاف useParams. ينبغي أن يكون المستخدم قادرًا على الوصول إلى واجهة العرض بالضغط على المستودع ضمن قائمة المستودعات. ومن الممكن تنفيذ ذلك بتغليف المكوّن RepositoryItem داخل المكّون البنيوي Pressable في المكوّن RepositoryList، ثم استخدام الدالة navigate لتغيير العنوان من خلال معالج الحدث onPress. استخدم الخطاف useNavigate أيضًا للوصول إلى الكائن دالة navigate.

ستبدو النسخة النهائية لواجهة عرض مستودع واحد قريبة من الشكل التالي:

10.20: قائمة بالآراء حول مستودع

بعد أن أنجزنا واجهة عرض لمستودع وحيد، سنعرض تقييمات المستخدمين ضمن هذه الواجهة. ستجد التقييمات في الحقل reviews العائد للنوع "Repository" في تخطيط GraphQL. تشكل التقييمات قائمةً صغيرةً مرقمةً يمكن الحصول عليها باستخدام الاستعلام repositories. وإليك مثالًا عن طريقة إحضار قائمة التقييمات لمستودع واحد:

{
  repository(id: "jaredpalmer.formik") {
    id
    fullName
    reviews {
      edges {
        node {
          id
          text
          rating
          createdAt
          user {
            id
            username
          }
        }
      }
    }
  }
}

يحتوي الحقل text لكل تقييم على رأي المستخدم للنص، ويحتوي الحقل rating على قيمة عددية بين 0 و100، أما الحقل craetedAt فيحتوي على بيانات إنشاء هذا التقييم، وأخيرًا يحتوي الحقل user معلومات عن مُنشئ التقييم ويحمل النوع "User".

نريد أن نعرض التقييمات على شكل شريط تمرير، مما يجعل المكوّن البنيوي FlatList ملائمًا لأداء المهمة. ولكي تعرض معلومات مستودع محدد في أعلى الواجهة، استخدم الخاصية ListHeaderComponent للمكون FlatList. يمكنك أيضًا استخدام المكوّن البنيوي ItemSeparatorComponent لإضافة مساحة بيضاء بين العناصر المعروضة كما هو الحال بين عناصر المكوّن RepositoryList مثلًا. إليك مثالًا عن هيكلية التنفيذ:

const RepositoryInfo = ({ repository }) => {
  // Repository's information implemented in the previous exercise
};

const ReviewItem = ({ review }) => {
  // Single review item
};

const SingleRepository = () => {
  // ...

  return (
    <FlatList
      data={reviews}
      renderItem={({ item }) => <ReviewItem review={item} />}
      keyExtractor={({ id }) => id}
      ListHeaderComponent={() => <RepositoryInfo repository={repository} />}
      // ...
    />
  );
};

export default SingleRepository;

ستبدو النسخة النهائية عن تطبيق قائمة المستودعات مشابهة للشكل التالي:

البيانات التي تراها تحت اسم المستخدم لمنشئ التقييم هي تاريخ الإنشاء الذي نجده في الحقل createdAt وهو من النوع "Review"، وينبغي أن يكون تنسيق البيانات مريحًا للمستخدم مثل الصيغة "يوم.شهر.سنة". قد يساعدك تثبيت المكتبة date-fns على تنسيق تاريخ الإنشاء بالاستفادة من الدالة format.

يمكن إنجاز الحاوية ذات الشكل الدائري باستخدام خاصية التنسيق borderRadius. ولتفعل هذا عليك تثبيت قيمتي الخاصيتين width و height، ثم ضبط خاصية التنسيق border-radius عند القيمة "width/2".

10.21: نموذج التقييم

أنجز نموذجًا لإنشاء تقييم جديد لمستودع مستخدمًا المكتبة Formik. ينبغي أن يضم النموذج أربعة حقول هي:

• اسم دخول مالك المستودع.
• اسم المستودع.
• التقييم على هيئة قيمة عددية.
• رأي المستخدم على هيئة نص.

تحقق من الحقول مستخدمًا تخطيط Yup، بحيث تتأكد أن:

• اسم المستخدم لمالك المستودع هو قيمة نصية إجبارية.
• اسم المستودع هو قيمة نصية إجبارية.
• التقييم هو قيمة عددية إجبارية بين 0 و100.
• رأي المستخدم هو قيمة نصية اختيارية.

اطلع على توثيق Yup لإيجاد المُقيَّمات validators المناسبة، واستخدم رسائل خطأ مناسبة عند استخدامك لهذه المُقيِّمات، إذ يمكنك تعريف رسالة الخطأ مثل وسيط للتابع message العائد للمقيّم. يمكنك أيضًا توسيع نص الحقل ليمتد على عدة أسطر باستعمال الخاصية multiline العائدة للمكون TextInput.

استخدم الطفرة createReview لإنشاء تقييم جديد، واطلع على وسطاء الطفرة بفتح إحدى النافذتين "docs" أو "schema " في أرضية عمل GraphQL. ويمكنك استخدام الخطاف useMutation لإرسال الطفرة إلى خادم Apollo.

بعد نجاح عمل الطفرة createReview، حوّل المستخدم إلى واجهة عرض المستودع التي أنجزناها في التمرين السابق. نفّذ ذلك باستخدام التابع navigate بعد أن تستخرج كائن التاريخ باستخدام الخطاف useNavigate. يمتلك التقييم الذي أنشأته حقلًا باسم "repositoryId" يمكنك استخدامه لتأسيس مسار لعنوان التقييم.

استخدم سياسة الإحضار "cache-and-network" لتمنع جلب بيانات الذاكرة المؤقتة مع الاستعلام repository في واجهة عرض مستودع وحيد. يمكنك استخدامها مع الخطاف على النحو التالي:

useQuery(GET_REPOSITORY, {
  fetchPolicy: 'cache-and-network',
  // خيارات أخرى
});

انتبه إلى أن التقييم سيكون فقط لمستودعات GitHub العامة الموجودة فعلًا، وأن المستخدم سيقيَّم مستودعًا محددًا مرة واحدة فقط. ليس عليك الآن التعامل مع حالات الخطأ هذه، بل فقط إظهار الخطأ مع الرمز المحدد والرسالة المناسبة. جرّب ما نفّذته على أحد المستودعات العامة التي تملكها، أو أية مستودعات عامة أخرى.

ينبغي أن يتمكن المستخدم من الوصول إلى واجهة التقييم من خلال شريط التطبيق. لذلك أنشئ نافذة جديدة عنوانها "Create a review". ينبغي أن تكون النافذة مرئية للمستخدم الذي سجل دخوله فقط. وعليك أن تحدد أيضًا عنوانًا لواجهة التقييم.

ستبدو النسخة النهائية للتطبيق مشابهة للشكل التالي:

التُقطت شاشة التطبيق هذه بعد إخفاق إرسال بيانات نموذج لإظهار شكله في هذه الحالة.

10.22: نموذج تسجيل مستخدم جديد

أنجز نموذجًا لتسجيل مستخدم جديد مستخدمًا Formik. ينبغي أن يضم النموذج ثلاثة حقول: اسم مستخدم، كلمة مرور، وتأكيدًا لكلمة المرور. تحقق من صحة البيانات في النموذج مستخدمًا تخطيط Yup ومتبعًا مايلي:

• اسم المستخدم هو سلسلة نصية إجبارية طولها بين 1 و 30.
• كلمة المرور هي سلسلة نصية إجبارية طولها بين 1 و 5.
• تأكيد كلمة المرور يتطابق تمامًا مع كلمة المرور.

قد يربكك قليلًا تأكيد كلمة المرور، لكن يمكن إنجاز الأمر بالاستفادة من التابعين oneOf وref كما هو مبين في إرشادات هذا المشروع.

يمكنك إنشاء مستخدم جديدة باستخدام الطفرة createUser، ويمكنك الإطلاع على كيفية استخدامها من خلال توثيق أرضية عمل Apollo.

سجّل دخول المستخدم الجديد بعد إنشاء حسابه الخاص مستخدمًا الخطاف useSignIn كما فعلنا في نموذج تسجيل الدخول. وجِّه المستخدم الجديد بعد تسجيل دخوله إلى واجهة عرض المستودعات المقيّمة.

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

ستبدو النسخة النهائية لواجهة تسجيل مستخدم جديد مشابهة للصورة التالية:

التُقطت شاشة التطبيق هذه بعد إخفاق إرسال بيانات نموذج لإظهار شكله في هذه الحالة.

10.23: ترتيب بيانات تطبيق قائمة المستودعات المقّيمة

تُرتّب المستودعات حتى هذه اللحظة وفقًا لتاريخ تقييم المستودع. أنجز آلية تسمح للمستخدم أن يختار أساسًا لترتيب هذه المستودعات وفقًا لما يلي:

• المستودعات الأخيرة: سيكون المستودع الذي قُيَّم آخيرًا وللمرة الأولى في أعلى القائمة. هذا الترتيب هو المتبع حاليًا، وينبغي أن يكون الخيار الإفتراضي.
• المستودعات الأعلى تقييمًا: سيكون المستودع الذي يحمل أعلى قيمة لمعدّل التقييم في أعلى القائمة.
• المستودعات الأدنى تقييمًا: سيكون المستودع الذي يحمل أدنى قيمة لمعدّل التقييم في أعلى القائمة.

يمتلك الاستعلام repositories الذي يحضر قائمة المستودعات وسيطًا يدعى orderby يمكنك استخدامه لتحديد أسلوب الترتيب المتبع، إذ يمتلك هذه الوسيط قيمتين فقط هما:

• CREATED_AT: الترتيب وفق تاريخ التقييم لأول مرة.
• RATING_AVERAGE: الترتيب على أساس معدل التقييم.

كما يمتلك الاستعلام وسيطًا يدعى orderDirection ويستخدم لتغيير جهة الترتيب. يملك الوسيط الأخير قيمتين، هما: ASC (تصاعدي، من التقييم الأدنى إلى الأعلى) و DESC (تنازلي، من التقييم الأعلى إلى الأدنى).

يمكن المحافظة على خيار الترتيب باستخدام الخطاف useState على سبيل المثال، كما يمكن تمرير المتغيرات التي يستخدمها الاستعلام repositories إلى الخطاف useRepositories مثل وسطاء.

يمكنك أيضًا استخدام المكتبة react-native-picker أو المكوّن Menu العائد للمكتبة React Native Paper لإنجاز شيفرة ترتيب القائمة، كما يمكنك استخدام الخاصية ListHeaderComponent العائدة للمكوّن FlatList لتزويدك بترويسة تحتوي على مكوّن الاختيار.

ستبدو النسخة النهائية لهذه الميزة، وبناء على مكوَّن الاختيار الذي اعتمدته، قريبةً من الصورة التالية:

10.24: انتقاء مستودعات محددة من القائمة

يتيح خادم Apollo ترشيح المستودعات بناءً على اسمها أو اسم مالكها، ويمكن إنجاز ذلك باستخدام الوسيط searchKeyword العائد للاستعلام repositories. إليك مثالًا عن كيفية استخدام الوسيط مع الاستعلام:

{
  repositories(searchKeyword: "ze") {
    edges {
      node {
        id
        fullName
      }
    }
  }
}

أنجز ميزةً في التطبيق لترشيح قائمة المستودعات المقيّمة بناءً على كلمة محددة. ينبغي أن يكون المستخدم قادرًا على الكتابة ضمن مربع إدخال نصي وستظهر نتائج الفلترة وفقًا للكلمة المكتوبة مباشرة أثناء الكتابة. يمكنك استخدام المكوّن البسيط TextInput، أو استخدام مكوّن أكثر عصرية مثل المكوّن Searchbar العائد للمكتبة React Native Paper على أنه مربع إدخال نصي. ضع مكوّن الإدخال النصي ضمن ترويسة المكوّن FlatList.

ولتفادي تنفيذ عدد كبير من الاستعلامات أثناء كتابة المستخدم للكلمة بسرعة، اختر آخر سلسة كتبها بعد تأخير بسيط. تدعى هذه التقنية بالتريّث debouncing. تمثّل المكتبة use-debounce حلًا جيدًا لتأخير متغيّر الحالة، بعد أن تستخدم زمن انتظار معقول مثل 500 ميلي ثانية. خزّن قيمة النص الذي يُكتب في مربع الإدخال مستخدمًا الخطاف useState، ومرر القيمة المُؤخَّرة إلى الاستعلام كقيمة للوسيط searchKeyword.

قد تعترضك مشكلة فقدان مكون الإدخال النصي تركيز الدخل بعد كتابة كل حرف، وذلك لأن المحتوى الذي تقدّمه الخاصية ListHeaderComponent سيُلغى باستمرار. يمكن حل المشكلة بتحويل المكوّن المسؤول عن تصيير المكوّن FlatList إلى مكوّن صنف class component ومن ثم تعريف دالة تصيير الترويسة إلى خاصية للصنف على النحو التالي:

export class RepositoryListContainer extends React.Component {
  renderHeader = () => {
    // يحوي خاصيات المكون this.props
    const props = this.props;

    // ...

    return (
      <RepositoryListHeader
      // ...
      />
    );
  };

  render() {
    return (
      <FlatList
        // ...
        ListHeaderComponent={this.renderHeader}
      />
    );
  }
}

ستبدو النسخة النهائية لميزة انتقاء المستودعات قريبةً من الصورة التالية:

الترقيم بطريقة المؤشرات

عندما تعيد الواجهة البرمجية قائمةً مرتبةً من العناصر من مجموعةٍ ما، فإنها ستعيد مجموعةً جزئيةً من العناصر من أصل المجموعة الكاملة لتقليل عرض حزمة الاتصال مع الخادم وتقليل الذاكرة المستخدمة لتخزين القائمة في تطبيق المستخدم. يمكن أن نطلب تلك المجموعة الجزئية لتوافق معاملات محددة لكي يستطيع المستخدم أن يطلب مثلًا أول عشرين عنصرًا منها ابتداءًا من عنصر محدد. تدعى هذه التقنية عادة بالترقيم pagination. وعندما نستطيع الحصول على قائمة بعد عنصر محدد بمؤشر معيّن، سنكون أمام الترقيم المبني على المؤشرات cursor-based pagination.

فالمؤشر إذًا هو تحديدٌ لعنصر في قائمة مرتبة. لنلقي نظرةً على قائمة المستودعات المرقمة التي يعيدها الاستعلام repositories باستخدام الاستعلام التالي:

{
  repositories(first: 2) {
    totalCount
    edges {
      node {
        id
        fullName
        createdAt
      }
      cursor
    }
    pageInfo {
      endCursor
      startCursor
      hasNextPage
    }
  }
}

يبلِّغ الوسيط first الواجهة البرمجية ان تعيد فقط أول مستودعين. وإليك مثالًا عن الاستجابة لهذا الاستعلام:

{
  "data": {
    "repositories": {
      "totalCount": 10,
      "edges": [
        {
          "node": {
            "id": "zeit.next.js",
            "fullName": "zeit/next.js",
            "createdAt": "2020-05-15T11:59:57.557Z"
          },
          "cursor": "WyJ6ZWl0Lm5leHQuanMiLDE1ODk1NDM5OTc1NTdd"
        },
        {
          "node": {
            "id": "zeit.swr",
            "fullName": "zeit/swr",
            "createdAt": "2020-05-15T11:58:53.867Z"
          },
          "cursor": "WyJ6ZWl0LnN3ciIsMTU4OTU0MzkzMzg2N10="
        }
      ],
      "pageInfo": {
        "endCursor": "WyJ6ZWl0LnN3ciIsMTU4OTU0MzkzMzg2N10=",
        "startCursor": "WyJ6ZWl0Lm5leHQuanMiLDE1ODk1NDM5OTc1NTdd",
        "hasNextPage": true
      }
    }
  }
}

يعتمد تنسيق الكائن الناتج والوسطاء على مواصفات اتصالات مؤشر أرضية عمل GraphQL للترحيل، والتي أصبحت مواصفات ترقيم صفحات شائعة جدًا واعتُمدت على نطاقٍ واسع في واجهة برمجة تطبيقات GitHub's GraphQL API. سيحتوي الكائن الذي يحمل النتيجة مصفوفةً باسم edges تحتوي بدورها على عناصر لها سمتين الأولى هي العقدة node والأخرى هي المؤشر cursor؛ إذ تحتوي العقدة على المستودع بحد ذاته كما نعرف؛ أما المؤشر فهو تمثيلٌ مشفّر للعقدة بأسلوب "Base64". ويحتوي المؤشر على المعرّف id للمستودع بالإضافة إلى تاريخ إنشائه. هذه هي كل المعلومات التي نريدها لكي نشير إلى العنصر عندما تُرتَّب العناصر وفق تاريخ إنشاء المستودع. يحتوي الكائن pageInfoعلى معلومات مثل المؤشرات على بداية ونهاية المصفوفة.

دعونا نتأمل الحالة التي نريد فيها مجموعة العناصر التي تلي آخر عنصر من المجموعة الحالية وهو العنصر "zeit/swr". يمكننا إسناد قيمة الحقل endCursor إلى الوسيط after للاستعلام على النحو التالي:

{
  repositories(first: 2, after: "WyJ6ZWl0LnN3ciIsMTU4OTU0MzkzMzg2N10=") {
    totalCount
    edges {
      node {
        id
        fullName
        createdAt
      }
      cursor
    }
    pageInfo {
      endCursor
      startCursor
      hasNextPage
    }
  }
}

والآن سنحصل على العنصرين التاليين، وسنستمر في هذه العملية حتى يأخذ الحقل hasNextPage القيمة false، وهذا يعني أننا وصلنا آخر القائمة، ولتتعمق أكثر في الترقيم المتعلق بالمؤشرات، إقرأ المقالة التي عنوانها Pagination with Relative Cursors على موقع Shopify، حيث تقدم المقالة الكثير من التفاصيل عن طريقة كتابة الشيفرة بالإضافة إلى الفوائد من استخدام الترقيم بالمؤشرات مقارنةً بالترقيم وفق ترتيب العنصر index-based.

التمرير اللانهائي

تُصمّم القوائم المرتبة عموديًا في تطبيقات سطح المكتب أو تطبيقات الهواتف الذكية بتقنية تدعى التمرير اللانهائي - infinite scrolling. ويعتمد مبدأ هذه التقنية على النقاط التالية:

• إحضار المجموعة الأولية من العناصر.
• عند وصول المستخدم إلى آخر عنصر من هذه المجموعة، يجري إحضار المجموعة التالية من العناصر التي تبدأ من العنصر الذي يلي آخر عنصر من المجموعة السابقة.

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

لنرى كيف سننفذ ذلك عمليًا من خلال خطاف Apollo Client الذي يُدعى useQuery. يضم توثيق Apollo Client تفاصيل كثيرة عن طريقة تنفيذ الترقيم باستخدام المؤشرات. لننجز إذًا ميزة التمرير اللانهائي لعرض قائمة المستودعات المقيّمة.

علينا أولًا أن نحدد متى يصل المستخدم إلى آخر عنصر في القائمة. ولحسن الحظ، يمتلك المكون FlatList الخاصية onEndReached التي تستدعى الدالة التي ستنفذ العملية عندما يصل المستخدم إلى آخر عنصر من القائمة. يمكنك التحكم بوقت استدعاء الدالة onEndReach باستخدام الخاصية onEndReachedThreshold. غيِّر شيفرة المكوّن FlatList الموجود ضمن المكوّن RepositoryList لكي يستدعي الدالة حالما يصل المستخدم إلى العنصر الأخير:

export const RepositoryListContainer = ({
  repositories,
  onEndReach,
  /* ... */,
}) => {
  const repositoryNodes = repositories
    ? repositories.edges.map((edge) => edge.node)
    : [];

  return (
    <FlatList
      data={repositoryNodes}
      // ...
      onEndReached={onEndReach}
      onEndReachedThreshold={0.5}
    />
  );
};

const RepositoryList = () => {
  // ...

  const { repositories } = useRepositories(/* ... */);

  const onEndReach = () => {
    console.log('You have reached the end of the list');
  };

  return (
    <RepositoryListContainer
      repositories={repositories}
      onEndReach={onEndReach}
      // ...
    />
  );
};

export default RepositoryList;

جرّب عملية التمرير إلى نهاية قائمة المستودعات، وستظهر رسالةً في سجل العمل مفادها أنك وصلت إلى العنصر الأخير.

علينا الآن أن نحضر مزيدًا من المستودعات في اللحظة التي نصل فيها إلى نهاية العناصر. يمكن إنجاز ذلك باستخدام الدالة fetchMore التي يؤمنها الخطاف useQuery. يمكننا استخدام سياسة الحقل field policy لوصف عميل Apollo وكيفية دمج المستودعات الموجودة في ذاكرة التخزين المؤقت مع المجموعة التالية من المستودعات، إذ تُستخدم سياسات الحقول عمومًا لتخصيص سلوك ذاكرة التخزين المؤقت أثناء عمليات القراءة والكتابة باستخدام دوال القراءة والدمج.

دعنا نضيف سياسة حقل للاستعلام repositories في ملف "apolloClient.js" على النحو التالي:

import { ApolloClient, InMemoryCache, createHttpLink } from '@apollo/client';
import { setContext } from '@apollo/client/link/context';
import Constants from 'expo-constants';
import { relayStylePagination } from '@apollo/client/utilities';

const { apolloUri } = Constants.manifest.extra;

const httpLink = createHttpLink({
  uri: apolloUri,
});

const cache = new InMemoryCache({
  typePolicies: {
    Query: {
      fields: {
        repositories: relayStylePagination(),
      },
    },
  },
});

const createApolloClient = (authStorage) => {
  const authLink = setContext(async (_, { headers }) => {
    try {
      const accessToken = await authStorage.getAccessToken();

      return {
        headers: {
          ...headers,
          authorization: accessToken ? `Bearer ${accessToken}` : '',
        },
      };
    } catch (e) {
      console.log(e);

      return {
        headers,
      };
    }
  });

  return new ApolloClient({
    link: authLink.concat(httpLink),
    cache,
  });
};

export default createApolloClient;

كما ذكرنا سابقًا، يعتمد تنسيق كائن نتيجة ترقيم الصفحات والوسطاء على مواصفات ترقيم الصفحات الخاصة بالترحيل Relay، ولحسن الحظ، يوفر Apollo Client سياسة حقل محددة مسبقًا، relayStylePagination، والتي يمكن استخدامها في هذه الحالة.

غيّر في شيفرة الخطاف useRepositories بحيث يعيد الدالة fetchMore بعد فَكِّ تشفيرها، بحيث تستدعي الدالة fetchMore الفعلية مع الحقل endCursor، ثم يُحدّث بعدها الاستعلام بصورة صحيحة وفقًا للبيانات المُحضرة:

const useRepositories = (variables) => {
  const { data, loading, fetchMore, ...result } = useQuery(GET_REPOSITORIES, {
    variables,
    // ...
  });

  const handleFetchMore = () => {
    const canFetchMore = !loading && data?.repositories.pageInfo.hasNextPage;

    if (!canFetchMore) {
      return;
    }

    fetchMore({
      variables: {
        after: data.repositories.pageInfo.endCursor,
        ...variables,
      },
    });
  };

  return {
    repositories: data?.repositories,
    fetchMore: handleFetchMore,
    loading,
    ...result,
  };
};

تأكد من وجود الحقلين pageInfo و cursor في الاستعلام repositories كما هو موضح في مثال الترقيم. كما ينبغي عليك أن تضيف الوسيطين first و after إلى الاستعلام.

ستستدعي الدالة handleFetchMore الدالة fetchMore العائدة إلى Apollo client إن كان هناك المزيد من العناصر التي ينبغي إحضارها، وذلك بناء على قيمة الخاصية hasNextPage، ومن المفترض أن نمنع إحضار عناصر جديدة طالما أن عملية الإحضار سابقةً لا تزال قيد التنفيذ، إذ ستكون قيمة الحقل loading في هذه الحالة true. سنزود الاستعلام في الدالة fetchMore بالمتغير after الذي يتلقى آخر قيمة endCursor للحقل.

وتكون الخطوة الأخيرة استدعاء الدالة fetchMore ضمن دالة معالجة الحدث onEndReach:

const RepositoryList = () => {
  // ...

  const { repositories, fetchMore } = useRepositories({
    first: 8,
    // ...
  });

  const onEndReach = () => {
    fetchMore();
  };

  return (
    <RepositoryListContainer
      repositories={repositories}
      onEndReach={onEndReach}
      // ...
    />
  );
};

export default RepositoryList;

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

التمرينات 10.25- 10.27

10.15: شريط تمرير لانهائي لقائمة المستودعات المقيّمة

نفذ شريط تمرير لانهائي لقائمة المستودعات المقيّمة. يمتلك الحقل reviews العائد للنوع "Repository" الوسيطينafter و first كما في الاستعلام repositories. ويمتلك النوع "ReviewConnection" الحقل pageInfo كما يمتلكه النوع "RepositoryConnection".

إليك مثالًا عن استعلام:

{
  repository(id: "jaredpalmer.formik") {
    id
    fullName
    reviews(first: 2, after: "WyIxYjEwZTRkOC01N2VlLTRkMDAtODg4Ni1lNGEwNDlkN2ZmOGYuamFyZWRwYWxtZXIuZm9ybWlrIiwxNTg4NjU2NzUwMDgwXQ==") {
      totalCount
      edges {
        node {
          id
          text
          rating
          createdAt
          repositoryId
          user {
            id
            username
          }
        }
        cursor
      }
      pageInfo {
        endCursor
        startCursor
        hasNextPage
      }
    }
  }
}

يمكن أن تتشابه سياسة حقل ذاكرة التخزين المؤقت مع استعلام repositories:

const cache = new InMemoryCache({
  typePolicies: {
    Query: {
      fields: {
        repositories: relayStylePagination(),
      },
    },

   Repository: {
     fields: {
       reviews: relayStylePagination(),
     },
   },
 },
});

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

10.26: واجهة عرض لتقييمات المستخدم

أنجز واجهة تُمكِّن المستخدم من عرض ما قيّمه. ينبغي أن يكون المستخدم قادرًا على الوصول إلى هذه الواجهة من خلال الضغط على النافذة "My reviews" في شريط التطبيق بمجرد أن يسّجل دخوله. يمكنك تطبيق أسلوب التمرير اللانهائي إن أردت في هذا التمرين. وإليك الشكل الذي يمكن أن تظهر عليه هذه الواجهة:

تذكر أنه بإمكانك الحصول على المستخدم الذي سجّل دخول من خادم Apollo مستعينًا بالاستعلام me. سيعيد الاستعلام النوع "User" الذي يمتلك الحقل review. إن كنت قد أنجزت مسبقًا الاستعلام me يمكنك إعادة استخدامه بعد جعله قادرًا على إحضار الحقل review شرطيWh، وذلك بالاستفادة من توجيه GraphQL الذي يُدعى include.

لنفترض أن الاستعلام الحالي قد أنجز بصورةٍ قريبة من التالي:

const GET_CURRENT_USER = gql`
  query {
    me {
      # user fields...
    }
  }
`;

يمكنك تزويد الاستعلام بالوسيط includeReviewواستخدام ذلك مع التوجيه include:

const GET_CURRENT_USER = gql`
  query getCurrentUser($includeReviews: Boolean = false) {
    me {
      # user fields...
      reviews @include(if: $includeReviews) {
        edges {
          node {
            # review fields...
          }
          cursor
        }
        pageInfo {
          # page info fields...
        }
      }
    }
  }
`;

يمتلك الوسيط includeReview القيمة الافتراضية false، لأننا لا نريد أن نسبب حملًا زائدًا على الخادم ما لم نرد صراحةً إحضار المستودعات التي قيّمها المستخدم. إن مبدأ هذا التوجيه بسيط على النحو التالي: إن كانت قيم الوسيط if هي true، أحضر الحقل، وإلا احذفه.

10.27: إضافة أفعال إلى واجهة عرض التقييمات

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

ينبغي أن يلي الضغط على زر الحذف رسالة تأكيد للحذف، فإن أكد المستخدم أمر الحذف ستُنفّذ العملية، وإلا سيُهمل الأمر. يمكنك إنجاز ذلك باستخدام الوحدة البرمجية Alert. وانتبه إلى أن استدعاء التابع Alert.alert لن يفتح رسالة التأكيد في واجهة عرض المنصة Expo، بل عليك استخدام تطبيق جوّال Expo أو المقلّد لترى كيف ستبدو هذه الرسالة.

إليك الرسالة التي ينبغي أن تظهر عند الضغط على زر الحذف:

يمكنك حذف التقييم باستخدام الطفرة deleteReview. تمتلك هذه الطفرة وسيطًا واحدًا وهو المعرّف id للتقييم الذي سيُحذف. ومن السهل بعد تنفيذ الطفرة تحديث استعلام قائمة المستودعات باستدعاء الدالة refetch.

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

مصادر إضافية

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

المكتبة React Native Paper

المكتبة Paper هي مجموعةٌ من المكوّنات المخصصة والجاهزة للاستخدام في React Native، مبنيةٌ على معايير تصميم Material التي وضعتها غوغل Google.

صُممت React Native Paper من أجل لتقدم وظيفة تماثل وظائف المكتبة Material-UI، إذ تقدم مجموعةً واسعةً من مكوّنات واجهة المستخدم UI عالية الجودة التي تدعم إنشاء سمات مخصصة للتطبيق. وتتميز إعدادات استخدام React Native Paper مع تطبيقات React Native المبنية على منصة Expo بالسهولة، حيث يمكنك تجربتها مباشرة في التمارين القادمة إن أردت.

المكتبة Styled-components

سيعطيك استخدام القوالب المعرّفة المجرّدة tagged template literal -وهي إضافةٌ جديدة في JavaScript-، مع المكتبة styled-components إمكانية كتابة شيفرة CSS فعلية لتنسيق المكوّنات، كما يلغي استخدام هذه المكتبة الحاجة إلى الربط بين المكوّنات والتنسيق، وسيكون استخدام المكوّنات مثل وحدات بناءً تنسيقات على المستوى البرمجي المنخفض سهلًا جدًا.

تستخدم المكتبة Styled-components لتنسيق مكوّنات React Native باستخدام تقنية CSS-in-JS. لقد اعتدنا على تعريف تنسيق المكوّنات في React Native باستخدام كائنات JavaScript، وبالتالي لن يكون استخدام CSS-in-JS غريبًا. لكن مقاربة المكتبة Styled-components ستختلف تمامًا عن استخدام التابع StyleSheet.createو الخاصية style.

يُعرّف تسيق المكوّن في Styled-components باستخدام ميزة تُدعى القوالب المعرّفة المجرّدة tagged template literal أو كائنات جافا سكربت JavaScript الصِّرفة، التي تُمكننا من تعريف خصائص تنسيق جديدة للمكونات بناءً على خصائص تلك المكوّنات في زمن التنفيذ. سيتيح ذلك الكثير من الإمكانات مثل الانتقال بين السمات القاتمة والمضيئة، كما أنها تدعم كليًا موضوع السمات. إليك مثالًا عن إنشاء المكوّن Text مع إمكانية تغيير تنسيقه بناءً على خصائصه:

import styled from 'styled-components/native';
import { css } from 'styled-components';

const FancyText = styled.Text`
  color: grey;
  font-size: 14px;

  ${({ isBlue }) =>
    isBlue &&
    css`
      color: blue;
    `}

  ${({ isBig }) =>
    isBig &&
    css`
      font-size: 24px;
      font-weight: 700;
    `}
`;

const Main = () => {
  return (
    <>
      <FancyText>Simple text</FancyText>
      <FancyText isBlue>Blue text</FancyText>
      <FancyText isBig>Big text</FancyText>
      <FancyText isBig isBlue>
        Big blue text
      </FancyText>
    </>
  );
};

وطالما أن المكتبة styled-components ستعالج تعريف التنسيق، يمكننا استخدام أسلوب كتابة الأفعى snake case المشابه لطريقة كتابة CSS لتسمية الخصائص والواحدات (مثل % أو px)، لكن لا أهمية في الواقع للواحدات، لأن قيم خصائص التنسيق لا تقبل ذلك. للاطلاع على مزيدٍ من المعلومات عن استخدام هذه المكتبة، اقرأ التوثيق الخاص بها.

المكتبة React-spring

react-spring هي مكتبة رسوم متحركة أساسها المكتبة spring-physics، تغطي معظم احتياجاتك لواجهات مزودة برسوم متحركة، إذ تؤمن لك هذه المكتبة أدوات بالمرونة الكافية لتحويل جميع أفكارك إلى واجهات متحركة.

تؤمن لك المكتبة React-spring واجهة برمجية ذات خطافات hook API واضحة الاستخدام لتحريك مكونات React Native.

المكتبة React Navigation

تؤمن مكتبة React Navigation التنقل والتوجه في تطبيقات React Native هي مكتبةٌ للتحكم بالتنقلات بين وجهات مختلفة في تطبيقات React Native. تتشابه في بعض النواحي مع المكتبة React Router. لكن وعلى خلاف React Router، تقدم مميزات أكثر قربًا للمنصة الأصيلة مثل الإيماءات الأصيلة والرسوميات الانتقالية التي تظهر عند التنقل بين الواجهات المختلفة للتطبيق.

كلمة ختامية

وهكذا نكون قد أكملنا تطبيقنا وأصبح جاهزًا.

لقد تعلمنا خلال هذه الرحلة العديد من المفاهيم الجديدة، مثل إعداد تطبيقات React Native باستخدام المنصة Expo، وطريقة العمل مع مكوّنات React Native البنيوية، وتنسيق مظهر هذه المكوّنات، إضافةً إلى الاتصال مع الخادم واختبار التطبيقات. ستكون الخطوة الأخيرة هي نشر التطبيق على متجر Apple App أو متجر Google Play.

يبقى موضوع نشر التطبيق خيارًا شخصيًا وليس أمرًا مُلحًّا، لأنك ستحتاج أيضًا إلى نشر وتوزيع الخادم rate-repository-api، أما من أجل تطبيق React Native بحد ذاته، فعليك أن تُنشئ نسخة بناء لمنصة iOS أو لمنصة أندرويد باتباع الإرشادات في توثيق Expo. وبعد ذلك ستتمكن من توزيع هذه النسخ على متجري Apple App أو Google Play، وستجد تفاصيل عن هذه الخطوة أيضًا في توثيق Expo.

ترجمة -وبتصرف- للفصل Testing and extending our application من سلسلة [Deep Dive Into Modern Web Development

اقرأ أيضًا

• المقال السابق: تواصل تطبيق React Native مع الخادم
• أساسيات React Native
• مدخل إلى التحريك في React Native

لقد أضفنا حتى الآن عدة ميزات إلى تطبيقنا لكن دون أي اتصال بالخادم، إذ يستخدم تطبيق قائمة المستودعات المقيَّمة الذي نفذناه في المقال السابق أساسيات React Native -على سبيل المثال- بيانات وهمية، ولا يرسل نموذج تسجيل الدخول بيانات التحقق من المستخدم إلى أية وصلة تخديم endpoint مفوَّضة باستقبال هذه البيانات، لذا سنتعلم في هذا المقال كيف سنتصل بالخادم مستخدمين طلبات HTTP، وكيف سنستخدم المكتبة Apollo Client ضمن تطبيقات React Native، وكذلك طريقة تخزين البيانات في جهاز المستخدم.

سنحتاج قبل الشروع بتعلم تلك النقاط إلى خادم لنتواصل معه، لذلك فقد أنجزنا خادمًا كاملًا ووضعناه في المستودع rate-repository-api. سيلبي الخادم "rate-repository-api" كل ما تحتاجه الواجهة البرمجية لتطبيقنا خلال هذا القسم، إذ يستخدم "rate-repository-api" قاعدة بيانات SQLite والتي لا تحتاج إلى إعدادات، كما يؤمن واجهة برمجية خاصة بالمكتبة Apollo GraphQL، إضافةً إلى بعض وصلات التخديم التي تؤمن واجهة برمجية متوافقة مع REST.

قبل أن تغوص أعمق في مادة هذا المقال، عليك أن تُعدَّ الخادم "rate-repository-api" باتباع الإرشادات الموجودة في ملف README الخاص بالمستودع. ننصحك إن كنت ستستخدم المقلّد emulator لتطوير التطبيق، أن تشغله على نفس الحاسوب الذي يشغّل الخادم، فسيسهل ذلك طلبات الاتصال عبر الشبكة على نحوٍ واضح.

طلبات HTTP

تزودنا React Native بالواجهة البرمجية Fetch API لتنفيذ طلبات HTTP الخاصة بتطبيقنا، كما تدعم أيضًا الواجهة البرمجية القديمة XMLHttpRequest API والتي ستمكننا من استخدام مكتبات خارجية مصدرها طرف ثالث مثل Axios. وهذه الواجهات هي نفسها التي استخدمناها في بيئة المتصفح، كما أنها متاحة لكامل التطبيق ولا حاجة لإدراجها.

قد يتفق المطورون الذين تعاملوا مع الواجهتين البرمجيتين السابقتين، أن Fetch API أسهل استخدامًا وأكثر عصرية، لكن للواجهة XMLHttpRequest API استعمالاتها أيضًا، ولأجل تبسيط الموضوع سنتعامل فقط مع Fetch API في أمثلتنا.

يمكن استخدام Fetch API لإرسال طلبات HTTP باستخدام الدالة fetch وسيكون الوسيط الأول لهذه الدالة عنوان المورد URL وطلب HTTP الافتراضي لها هو GET:

fetch('https://my-api.com/get-end-point');

أما الوسيط الثاني للدالة فهو كائن خيارات يمكنك استعماله لإنشاء طلب HTTP آخر، أو ترويسة طلب، أو متن body طلب:

fetch('https://my-api.com/post-end-point', {
  method: 'POST',
  headers: {
    Accept: 'application/json',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    firstParam: 'firstValue',
    secondParam: 'secondValue',
  }),
});

انتبه إلى أنّ العناوين "URL's" مصطنعة ولن تستجيب لطلباتك غالبًا.

تعمل Fetch API موازنةً بالمكتبة Axios في مستوى أدنى قليلًا، فلا توجد مثلًا أية عمليات تحويل أو تفسير لمتن الطلب أو الاستجابة، فعليك مثلًا أن تحدد نوع المحتوى content-type بنفسك وأن تستخدم التابع JSON.stringify لتحويل متن الطلب إلى نص.

تعيد الدالة fetch وعدًا (promise) يُحَل resolves إلى كائن الاستجابة Response، وانتبه إلى أنّ رموز الحالة للأخطاء التي تحصل مثل 400 أو 500 لن تُرفض كما هو الوضع في Axios مثلًا.

يمكن أن نفسّر متن الاستجابة المنسقة بأسلوب JSON باستخدام التابع Response.json:

const fetchMovies = async () => {
  const response = await fetch('https://reactnative.dev/movies.json');
  const json = await response.json();

  return json;
};

وللاطلاع على أساسيات Fetch API بشيء من التفصيل، اقرأ مقال الواجهة البرمجية fetch في JavaScript ومقال استعمالات متقدمة للواجهة البرمجية Fetch في جافاسكربت وأضف إليهما مقال تتبع تقدم عملية تنزيل البيانات عبر Fetch ومقاطعتها في جافاسكربت.

لنبدأ بالاستخدام التطبيقي للمكتبة Fetch API، إذ يؤمن الخادم rate-repository-api وصلة تخديم تعيد قائمةً مرقمةً من المستودعات المقيَّمة. ستتمكن من الولوج إلى وصلة التخديم الموجودة على العنوان "http://localhost:5000/api/repositories" بمجرد أن يعمل الخادم. تُرقّم البيانات بأسلوب الترقيم المعتمد على المؤشرات cursor based pagination format، وستجد البيانات الفعلية خلف المفتاح "node" في المصفوفة "edges".

لا يمكن، لسوء الحظ، الوصول إلى الخادم rate-repository-api مباشرةً من خلال تطبيقنا بطلب العنوان "http://localhost:5000/api/repositories"، إذ نحتاج لإرسال طلب إلى وصلة التخديم هذه عبر التطبيق الوصول إلى الخادم باستخدام عنوان IP الخاص به في الشبكة المحلية التي ينتمي إليها. ولإيجاد هذا العنوان، افتح أدوات تطوير Expo بتنفيذ الأمر npm start. سترى في أدوات التطوير عنوانًا له بالبادئة "//:exp" فوق شيفرة QR:

انسخ عنوان IP الموجود بين البادئة "//:exp" والنهاية ":"، وسيكون في مثالنا 192.168.100.16. أنشئ بعد ذلك عنوان URL بالتنسيق التالي "http://:5000/api/repositories" ثم توجه إليه من خلال المتصفح، وستحصل على نفس الاستجابة التي حصلت عليها باستخدام عنوان الخادم المحلي "localhost".

بعد أن حددنا عنوان وصل التخديم، سنستخدم البيانات الفعلية التي يزودنا بها الخادم في تطبيق قائمة المستودعات المقيَّمة. أشرنا سابقًا أننا نستخدم بيانات وهمية مخزّنة في المتغير repositories. اِحذف هذا المتغير واستعض عن البيانات الوهمية في الملف "RepositoryList.jsx" الموجود في المجلد "components" بهذه الشيفرة:

import { useState, useEffect } from 'react';
// ...

const RepositoryList = () => {
  const [repositories, setRepositories] = useState();

  const fetchRepositories = async () => {
    // ‫صحح عنوان IP إن كان مختلفًا لديك
    const response = await fetch('http://192.168.100.16:5000/api/repositories');
    const json = await response.json();

    console.log(json);

    setRepositories(json);
  };

  useEffect(() => {
    fetchRepositories();
  }, []);

  // Get the nodes from the edges array
  const repositoryNodes = repositories
    ? repositories.edges.map(edge => edge.node)
    : [];

  return (
    <FlatList
      data={repositoryNodes}
      // Other props
    />
  );
};

export default RepositoryList;

استخدمنا الخطاف useState للحفاظ على حالة قائمة المستودعات، كما استخدمنا الخطاف useEffect لاستدعاء الدالة fetchRepositoriesعندما يُثبّت المكوّن RepositoryList ضمن شجرة المكوّنات. استخلصنا المستودعات الفعلية ووضعناها في المتغير repositoryNode واستبدلنا به المتغير السابق repositories الموجود في الخاصية data العائدة للمكوّن FlatList، وبذلك يمكننا أن نرى البيانات الفعلية التي يعطيها الخادم ضمن التطبيق.

من الجيد عادةً تسجيل استجابة الخادم لتتمكن من تحرّيها كما فعلنا في الدالة fetchRepositories. ينبغي أن تكون قادرًا على الاطلاع على السجلات في أدوات تطوير Expo عن طريق الوصول إلى سجلات جهازك كما تعلمنا في المقال السابق (فقرة عرض سجلات العمل). إن استخدمت تطبيق جوّال Expo وأخفق طلب HTTP، تأكد أن هاتفك وحاسوبك الذي يشغّل الخادم ينتميان إلى نفس الشبكة اللاسلكية. وإن لم تستطع ذلك، استخدم المقلّد على نفس الحاسوب الذي يعمل عليه الخادم أو هيئ نفق توصيل tunnel إلى الخادم المحلي. يمكنك استخدام المكتبة Ngrok مثلًا لإنجاز ذلك.

يمكن إعادة كتابة شيفرة إحضار البيانات الموجودة في المكوّن RepositoryList، إذ يعرف المكوّن مثلًا تفاصيل الطلبات عبر الشبكة كعنوان وصلة التخديم، وبالإضافة إلى ذلك، تحمل شيفرة إحضار البيانات إمكانية لإعادة استخدامها. لنعد إذًا كتابة شيفرة المكوّن بنقل شيفرة إحضار البيانات إلى خطاف خاص بها. سننشئ أولًا مجلدًا باسم "hooks" ضمن المجلد "src" ومن ثم سنضع فيه الملف "useRepositories.js" الذي يحتوي الشيفرة التالية:

import { useState, useEffect } from 'react';

const useRepositories = () => {
  const [repositories, setRepositories] = useState();
  const [loading, setLoading] = useState(false);

  const fetchRepositories = async () => {
    setLoading(true);

    // ‫صحح عنوان IP إن كان مختلفًا لديك
    const response = await fetch('http://192.168.100.16:5000/api/repositories');
    const json = await response.json();

    setLoading(false);
    setRepositories(json);
  };

  useEffect(() => {
    fetchRepositories();
  }, []);

  return { repositories, loading, refetch: fetchRepositories };
};

export default useRepositories;

لنستخدم الآن الخطاف الجديد useRepositories في المكوّن RepositoryList:

// ...
import useRepositories from '../hooks/useRepositories';

const RepositoryList = () => {
  const { repositories } = useRepositories();

  const repositoryNodes = repositories
    ? repositories.edges.map(edge => edge.node)
    : [];

  return (
    <FlatList
      data={repositoryNodes}
      // Other props
    />
  );
};

export default RepositoryList;

وهكذا لن يكون لدى المكوّن RepositoryList أية فكرة عن طريقة الحصول على مستودعات القائمة، وربما سنطلب هذه المستودعات مستقبلًا باستخدام الواجهة البرمجية للمكتبة GraphQL بدلًا من واجهة REST، ونرى ما الذي سيحدث.

العمل مع المكتبتين GraphQL و Apollo client

تعرفنا في القسم 8 على GraphQL وكيفية إرسال استعلامات إلى خادم Apollo في تطبيقات React بالاستفادة من المكتبة Apollo Client. ولحسن الحظ، يمكنك استخدام Apollo client في تطبيقات React Native بنفس الطريقة التي استخدمناها في بناء تطبيقات React الخاصة بالويب.

وكما أشرنا سابقًا، سيزودنا الخادم "rate-repository-api" بواجهة برمجية للمكتبة GraphQL نُفِّذت باستخدام Apollo client، وبالتالي ستتمكن من الولوج إلى أرضية عمل GraphQL بالتوجه إلى العنوان http://localhost:5000/graphq. تمثل أرضية عمل GraphQL أداة تطوير لإرسال استعلامات GraphQL، وتفقد تخطيط الواجهة البرمجية للمكتبة GraphQL، وعرض توثيق هذه المكتبة. ويفضل أن تجرب دائمًا أية استعلامات سيرسلها تطبيقك من خلال أرضية عمل GraphQL قبل تضمينها في الشيفرة. ومن الأسهل أيضًا تنقيح الأخطاء المحتملة في الاستعلامات ضمن أرضية عمل GraphQL موازنةً مع تنقيحها باستخدام التطبيق. وإن لم تكن متأكدًا من الاستعلامات المتاحة أو كيفية استخدامها، انقر على النافذة "docs" لفتح التوثيق:

سنستعمل في تطبيقات React Native المكتبة Apollo Boost، وهو أسلوب لا يتطلب أية قواعد للتهيئة zero-config للبدء باستخدام Apollo client. وللتكامل مع React، سنستخدم المكتبة apollo/react-hooks@ والتي تؤمن خطافات مثل useQuery و useMutation تساعدنا في العمل مع المكتبة Apollo client. لنبدأ بتثبيت الاعتماديات اللازمة:

npm install @apollo/client graphql

سنحتاج قبل البدء باستخدام عميل Apollo إلى إعدادٍ جزئي لمجمّع Metro لمعالجة الملفات ذات الامتداد "cjs." التي يستخدمها عميل Apollo. لنثبّت أولًا الحزمة "expo/metro-config@" التي تحتوي على إعدادات Metro الافتراضية:

npm install @expo/metro-config

يمكننا بعد ذلك إضافة الإعداد التالي إلى الملف "metro.config.js" في المجلد الجذري للمشروع:

const { getDefaultConfig } = require('@expo/metro-config');

const defaultConfig = getDefaultConfig(__dirname);

defaultConfig.resolver.sourceExts.push('cjs');

module.exports = defaultConfig;

أعِد تشغيل أدوات تطوير Expo لتطبيق الإعدادات المُجراة.

لننشئ الآن دالةً خدميّة utility function لتكوين عميل Apollo وتهيئته على النحو المطلوب. أنشئ بدايةً المجلد "utils" ضمن المجلد "src"، وأنشئ ضمنه الملف "apolloClient.js"، ثم هيئ عميل Apollo ضمن هذا الملف ليتصل مع خادم Apollo:

import { ApolloClient, InMemoryCache, createHttpLink } from '@apollo/client';

const httpLink = createHttpLink({
  // ‫صحح عنوان IP إن كان مختلفًا لديك
  uri: 'http://192.168.100.16:4000/graphql',
});

const createApolloClient = () => {
  return new ApolloClient({
    link: httpLink,
    cache: new InMemoryCache(),
  });
};

export default createApolloClient;

يستخدم عميل Apollo للاتصال بخادم Apollo العنوان URL ذاته الذي استخدمناه مع Fetch API ونفس رقم المنفذ 4000، ما عدا أنّ المسار هو "graphql/". وأخيرًا علينا تزويد التطبيق بعميل Apollo وذلك باستخدام سياق العمل ApolloProvider. سنضيفه إذًا إلى المكوّن App في الملف "App.js":

import { NativeRouter } from 'react-router-native';
import { ApolloProvider } from '@apollo/client';

import Main from './src/components/Main';
import createApolloClient from './src/utils/apolloClient';

const apolloClient = createApolloClient();

const App = () => {
  return (
    <NativeRouter>
      <ApolloProvider client={apolloClient}>        
      <Main />
      </ApolloProvider>    
    </NativeRouter>
  );
};

export default App;

تنظيم الشيفرة المتعلقة بالمكتبة GraphQL

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

يمكنك استيراد معرّف القالب المجرّد gql المُستخدم في تعريف استعلامات من مكتبة "apollo/client@". وإن اتبعنا الهيكلية التي اقترحناها منذ قليل، فمن الأفضل إنشاء الملف "queries.js" في المجلد "graphql" ليحتوي الشيفرة اللازمة لتنفيذ استعلامات GraphQL في تطبيقنا. يمكن أن نخزّن كل استعلام ضمن متغّير خاص ثم نصدّره كالتالي:

import { gql } from '@apollo/client';

export const GET_REPOSITORIES = gql`
  query {
    repositories {
      ${/* ... */}
    }
  }
`;

// other queries...

يمكن إدراج تلك المتغيرات واستخدامها بالاستفادة من الخطاف useQuery على النحو التالي:

import { useQuery } from '@apollo/client';

import { GET_REPOSITORIES } from '../graphql/queries';

const Component = () => {
  const { data, error, loading } = useQuery(GET_REPOSITORIES);
  // ...
};

وينطبق على الطفرات ما ينطبق على الاستعلامات. طبعًا لا بدّ من تعريف الطفرات في ملف منفصل مثل "mutations.js"، ويُفضّل استخدام الاجتزاءات (fragments) في الاستعلامات لتفادي تكرار كتابة الحقول نفسها عدة مرات.

تطوير هيكلية التطبيق

عندما يأخذ التطبيق في النمو، سيزداد حجم بعض الملفات لتصبح ربما كبيرة جدًا لإدارتها بصورةٍ صحيحة. لنفترض أنه لدينا مكوّن A سيصيّر مكونين B و C. ستُعرّف جميع هذه المكونات ضمن الملف "A.jsx" والذي سيوضع في المجلد"components". نريد الآن أن ننقل المكونين A و B إلى ملفين مستقلين "B.jsx" و "C.jsx" دون أن نجري تغييرًا كبيرُا في تنظيم الشيفرة. سيكون أمامنا في هذه الحالة خيارين:

الأول، إنشاء الملفين "B.jsx" و"C.jsx" في المجلد "components". وستكون هيكلية التطبيق على النحو التالي:

components/
  A.jsx
  B.jsx
  C.jsx
  ...

الثاني، إنشاء مجلد A في المجلد "components" ثم إنشاء الملفين "B.jsx"و"C.jsx" ضمنه. ولتفادي إخفاق المكونات التي تُدرِج الملف "A.jsx" في شيفرتها، انقل الملف "A.jsx" إلى المجلد "A" وغيّر اسمه إلى "index.jsx". سينتج عن هذا الأسلوب الهيكلية التالية:

components/
  A/
    B.jsx
    C.jsx
    index.jsx
  ...

يُعد الخيار الأول مناسبًا تمامًا إن لم يكن المكونين C وB قابلين للاستخدام خارج حدود المكوّن A، فلا فائدة من وضعهما في ملفات منفصلة في المجلد "components"؛ أما الخيار الثاني فهو مناسبٌ لأسلوب الوحدات المستقلة، إذ أنه لا يسبب أية مشاكل في إدراج المكونات، لأن إدراج مسار مثل "A/." سيطابق إدراج كلا الملفين "A.jsx" و"A/index.jsx".

التمرين 10.11

إحضار المستودعات باستخدام Apollo client

نريد استبدال ما نفذناه ضمن الخطاف useRepositories مستخدمين المكتبة Fetch API باستعلام GraphQL. شغّل أرضية عمل Apollo على العنوان "http://localhost:4000"، ثم افتح توثيق المكتبة بالنقر على النافذة "docs". يستخدم الاستعلام عدة وسطاء اختيارية، فلا حاجة لتحديدها الآن. كوّن استعلامًا ضمن أرضية عمل Apollo لإحضار المستودعات بالاستفادة من قيم الحقول التي تعرضها حاليًا في واجهة التطبيق. ستُرقّم النتائج التي تضم قرابة 30 نتيجة افتراضيًا. يمكنك تجاهل موضوع الترقيم حاليًا.

عندما يعمل الاستعلام ضمن أرضية عمل Apollo، اِستخدمه ليحل مكان شيفرة المكتبة FetchAPI في الخطاف useRepositories. يمكن أن تنفِّذ ذلك باستخدام الخطاف useQuery. أدرج بعدها معّرف القالب المجرّد gql من المكتبة بالطريقة التي شرحناها سابقًا. حاول أن تستخدم الهيكلية التي اقترحناها سابقًا لتنظيم الشيفرة المتعلقة بالمكتبة GraphQL. ولتجنب مشاكل الذاكرة الخبيئة مستقبلًا، استخدم سياسة الإحضار (fetch policy) "cache-and-network"، التي يمكن استخدامها مع الخطاف useQuery على النحو التالي:

useQuery(MY_QUERY, {
  fetchPolicy: 'cache-and-network',
  // خيارات أخرى
});

يجب أن لا تؤثر التغييرات في شيفرة الخطاف useRepositories على أداء المكوّن RepositoryList بأي شكل من الأشكال.

متغيرات البيئة

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

تعلمنا سابقًا أنه بالإمكان تزويد البرامج قيد التشغيل بمتغيرات بيئة، إذ يمكن تعريف هذه المتغيرات من خلال سطر الأوامر أو من خلال ملف تهيئة بيئة التشغيل الذي ينتهي بلاحقة مثل "env." ومكتبات يؤمنها طرف ثالث مثل Dotenv. لكن ولسوء الحظ لا تدعم React Native الاستخدام المباشر لمتغيرات البيئة، لكن يمكننا الوصول إلى إعدادت تهيئة Expo الموجودة في الملف "app.json" في زمن التشغيل من خلال شيفرة JavaScript. وبالتالي يمكن استخدام هذه الإعدادات لتعريف المتغيرات المتعلقة بالبيئة والوصول إليها.

نستطيع الوصول إلى إعدادات التهيئة بإدراج الثابت Constants من الوحدة "expo-constants" كما فعلنا ذلك عدة مرات مسبقًا. وبإدراج هذا الثابت، ستزودنا الخاصية Constants.manifest بكل الإعدادات. لنجرب ذلك بكتابة شيفرة ضمن المكوّن App وظيفتها طباعة محتويات هذه الخاصية في سجل العمل:

import { NativeRouter } from 'react-router-native';
import { ApolloProvider } from '@apollo/client';
import Constants from 'expo-constants';

import Main from './src/components/Main';
import createApolloClient from './src/utils/apolloClient';

const apolloClient = createApolloClient();

const App = () => {
  console.log(Constants.manifest);

  return (
    <NativeRouter>
      <ApolloProvider client={apolloClient}>
        <Main />
      </ApolloProvider>
    </NativeRouter>
  );
};

export default App;

ستجد الآن كل إعدادات التهيئة في سجل العمل.

تقتضي الخطوة الثانية استخدام الإعدادات لتعريف متغيّرات تعتمد على بيئة التشغيل. لنبدأ المهمة بتغير اسم الملف "app.json" إلى "app.config.json". بهذا التغيير سنصبح قادرين على استخدام شيفرة جافا سكريبت داخل ملف التهيئة. غير محتوى الملف بحيث يتحوّل الكائن:

{
  "expo": {
    "name": "rate-repository-app",
    // … بقية الضبط
  }
}

إلى كائن قابل للتصدير، يحتوي على الخاصية expo:

export default {
   name: 'rate-repository-app',
   // … بقية الضبط
};

يتلقى الكائن expo الخاصية extra ضمن إعدادات التهيئة، وذلك لتمرير أية إعدادات خاصة بالتطبيق. ولنرى كيف يعمل هذا الأمر، سنضيف المتغير env إلى إعدادات تهيئة تطبيقنا:

export default {
   name: 'rate-repository-app',
   // … بقية الضبط
   extra: {
     env: 'development'
   },
};

أعد تشغيل أدوات تطوير Expo لتطبيق التغييرات. من المفترض أن تتغير قيمة الخاصية Constans.manifest بحيث تضم الخاصية extra التي تحتوي على إعدادات التهيئة الخاصة بتطبيقنا. يمكننا الآن الوصول إلى المتغير env من خلال الخاصية Constants.manifest.extra.env

ولأن وضع القيم الجاهزة في الشيفرة أمر طائش، سنستخدم متغير بيئة بديلًا لذلك:

export default {
   name: 'rate-repository-app',
   // rest of the configuration...
   extra: {
     env: process.env.ENV,
   },
};

تعلمنا سابقًا كيفية إسناد قيمة لمتغير البيئة من خلال سطر الأوامر، وذلك بتحديد اسم المتغيّر وقيمته قبل الأمر الفعلي. فعلى سبيل المثال، شغل أدوات تطوير Expo، ثم أسند القيمة "test" إلى متغير البيئة ENV:

ENV=test npm start

لو ألقيت نظرةً على سجل العمل، فستجد أن الخاصية Constants.manifest.extra.env قد تغيرت.

يمكننا كذلك تحميل متغيرات البيئة من الملف "env." كما تعلمنا في الأقسام السابقة. لكن علينا أولًا تثبيت المكتبة Dotenv:

npm install dotenv

لنضف الآن الملف "env." إلى المجلد الجذري للمشروع على أن يحتوي ما يلي:

ENV=development

سندرج أخيرًا المكتبة ضمن الملف "app.config.js":

import 'dotenv/config';

export default {
   name: 'rate-repository-app',
   // … بقية الضبط
   extra: {
     env: process.env.ENV,
   },
};

أعد تشغيل أدوات تطوير Expo لتطبيق التغييرات التي أجريتها على الملف "env".

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

التمرين 10.12

متغيرات البيئة

استخدم متغير بيئة ضمن ملف "env." لتحديد عنوان خادم Apollo بدلًا من كتابته ضمن الشيفرة، وذلك عند تهيئة عميل Apollo. يمكنك تسمية هذا المتغير "APOLLO_URI" مثلًا.

لا تحاول الوصول إلى متغير البيئة على النحو التالي: process.env.APOLLO_URI خارج الملف "app.config.js"، بل استخدم الكائن Constants.manifest.extra كما فعلنا في المثال السابق. كذلك لا تدرج المكتبة Dotenv خارج الملف "app.config.js" وإلا قد تواجهك المشاكل.

تخزين البيانات في جهاز المستخدم

قد تحتاج في بعض الأحيان إلى تخزين بعض البيانات في جهاز المستخدم. ومن أبرز السيناريوهات التي تضطرك إلى ذلك هو تخزين شهادة التحقق من المستخدم token لكي تكون قادرًا على الحصول عليها عندما يغلق المستخدم التطبيق ثم يعيد فتحه. لقد استخدمنا عند تطوير تطبيقات الويب الذاكرة المحلية للمتصفح من خلال الكائن localStorage. تؤمن Recat Native بالمقابل ذاكرة تخزين مقيمة هي الذاكرة غير المتزامنة (AsyncStorage).

يمكن استخدام أمر التثبيت في Expo لتثبيت نسخة من الحزمة reactnativecommunity/async-storage@ متوافقة مع نسخة Expo SDK المستخدمة:

expo install @react-native-async-storage/async-storage

تتشابه الواجهة البرمجية للحزمة AsyncStorage مع الواجهة البرمجية للذاكرة المحلية localStorage بعدة نواحٍ، فكلاهما ذاكرة تعتمد مبدأ "مفتاح-قيمة". ويكمن الاختلاف الكبير بينهما، كما يوحي الاسم، أنّ عمليات AsyncStorage غير متزامنة.

من المفيد أن نُجري تجريدًا بسيطًا لشيفرة العمليات، طالما أن AsyncStorage ستعمل مع مفاتيح نصية ضمن فضاء الأسماء العام global namespace. يمكن إنجاز هذا التجريد باستخدام الأصناف class. إذ يمكن، على سبيل المثال، إنشاء صنف لبطاقة تسوق، نخزّن فيها المنتجات التي يريد أن يشتريها مستخدم:

import AsyncStorage from '@react-native-async-storage/async-storage';

class ShoppingCartStorage {
  constructor(namespace = 'shoppingCart') {
    this.namespace = namespace;
  }

  async getProducts() {
    const rawProducts = await AsyncStorage.getItem(
      `${this.namespace}:products`,
    );

    return rawProducts ? JSON.parse(rawProducts) : [];
  }

  async addProduct(productId) {
    const currentProducts = await this.getProducts();
    const newProducts = [...currentProducts, productId];

    await AsyncStorage.setItem(
      `${this.namespace}:products`,
      JSON.stringify(newProducts),
    );
  }

  async clearProducts() {
    await AsyncStorage.removeItem(`${this.namespace}:products`);
  }
}

const doShopping = async () => {
  const shoppingCartA = new ShoppingCartStorage('shoppingCartA');
  const shoppingCartB = new ShoppingCartStorage('shoppingCartB');

  await shoppingCartA.addProduct('chips');
  await shoppingCartA.addProduct('soda');

  await shoppingCartB.addProduct('milk');

  const productsA = await shoppingCartA.getProducts();
  const productsB = await shoppingCartB.getProducts();

  console.log(productsA, productsB);

  await shoppingCartA.clearProducts();
  await shoppingCartB.clearProducts();
};

doShopping();

ومن الجيد أيضًا أن نحدد فضاء أسماء للمفاتيح في AsyncStorage، ذلك أنها قيم نصيّة. وفي هذا السياق، سنجد أن فضاء الأسماء هو بادئة نزوّد بها مفاتيح التخزين، إذ سيمنع استخدام فضاء الأسماء مفاتيح التخزين من التصادم مع مفاتيح أخرى للمكتبة AsyncStorage. عرّفنا فضاء الأسماء في المثال السابق على شكل وسيط للدالة البانية، كما استخدمنا التنسيق "namespace:key مفتاح: فضاء أسماء" من أجل مفاتيح التخزين.

يمكن إضافة عنصر إلى ذاكرة التخزين مستخدمين التابع AsyncStorage.setItem. سيكون مفتاح العنصر هو الوسيط الأول للتابع بينما ستكون قيمة المفتاح هي المعامل الثاني. وطالما أن قيمة المفتاح هي قيمة نصية، فلا بد من تحويل القيم غير النصية إلى نصية باستخدام التابع JSON.stringify. يُستخدَم التابع AsyncStorage.getItem للحصول على عنصر محدد من ذاكرة التخزين، ووسيط هذا التابع هو مفتاح العنصر. أما التابع AsyncStorage.removeItem فيُستخدم لحذف عنصر من ذاكرة التخزين بتحديد مفتاحه.

التمرينان 10.13 - 10.14

10.13: استخدام الطفرات في نموذج تسجيل الدخول

لا يستطيع نموذج تسجيل الدخول حاليًا فعل أي شيء حيال معلومات توثيق المستخدم التي يرسلها، لذلك سنحاول تحسين الوضع قليلًا في هذا التمرين. اطلع أولًا على توثيق الاستيثاق authentication documentation الخاص بالخادم "rate-repository-api"، ثم اختبر الاستعلامات التي تُزوَّد بها ضمن أرضية عمل Apollo. إن لم تحتوي قاعدة البيانات على أي مستخدمين يمكن وضع بعض البيانات فيها، وستجد إرشاداتٍ لذلك في الفقرة "getting started"من الملف "README" الموجود في المستودع "rate-repository-ap".

عندما تتفهم الطريقة التي تعمل بها استعلامات الاستيثاق، أنشئ الملف "useSignIn.js" في المجلد "hooks" وضع فيه شيفرة الخطافuseSignIn الذي يرسل الطفرة باستخدام الخطاف useMutation. تقبل الطفرة authenticate وسيطًا وحيدًا هو credentials من النوع "AuthenticateInput". يحتوي نوع عنصر الإدخال (input type) حقلين لاسم المستخدم وكلمة المرور.

ستكون القيمة التي يعيدها الخطاف على الشكل [signIn, result]، إذ يمثل الوسيط result نتيجة الطفرات كما يعيدها الخطاف useMutation، ويمثل الوسيط signIn دالة تنفيذ الطفرة باستخدام وسيط هو كائن من الشكل {username, password}.

تلميح: لا تمرر دالة الطفرة إلى القيمة المعادة مباشرةً، بل أعد دالة تستدعي دالة الطفرة على النحو التالي:

const useSignIn = () => {
  const [mutate, result] = useMutation(/* mutation arguments */);

  const signIn = async ({ username, password }) => {
    // استدعي دالة الطفرة بالوسطاء المناسبين
  };

  return [signIn, result];
};

بعد إنجاز الخطاف، استخدمه في دالة الاستدعاء onSubmit العائدة للمكوّن SignIn على النحو التالي مثلًا:

const SignIn = () => {
  const [signIn] = useSignIn();

  const onSubmit = async (values) => {
    const { username, password } = values;

    try {
      const { data } = await signIn({ username, password });
      console.log(data);
    } catch (e) {
      console.log(e);
    }
  };

  // ...
};

يمكنك عدُّ التمرين مكتملًا عندما تُسجَّل نتيجة طفرات authenticate في سجل عمل التطبيق بعد إرسال بيانات النموذج. وينبغي أن تتضمن نتيجة الطفرة شهادة التحقق من المستخدم.

10.14: تخزين شهادة التحقق- الخطوة 1

بعد أن حصلنا على شهادة التحقق لا بدّ من تخزينها. أنشئ الملف "authStorage.js" في المجلد "utils" بحيث يحتوي الشيفرة التالية:

import AsyncStorage from '@react-native-async-storage/async-storage';


class AuthStorage {
  constructor(namespace = 'auth') {
    this.namespace = namespace;
  }

  getAccessToken() {
    // احصل على شهادة التحقق
  }

  setAccessToken(accessToken) {
    // أضف الشهادة إلى ذاكرة التخزين
  }

  removeAccessToken() {
    // احذف شهادة التحقق من ذاكرة التخزين
  }
}

export default AuthStorage;

أنجز شيفرة التوابع التالية: AuthStorage.getAccessToken و AuthStorage.setAccessToken و AuthStorage.removeAccessToken. استخدم المتغير namespace لمنح المفاتيح فضاء أسماء كما فعلنا في المثال السابق.

تحسين طلبات المكتبة Apollo Client

بعد أن أنجزنا آلية لتخزين شهادة التحقق من المستخدم، حان الوقت لاستخدامها. هيئ ذاكرة التخزين في المكوّن App:

import { NativeRouter } from 'react-router-native';
import { ApolloProvider } from '@apollo/client';

import Main from './src/components/Main';
import createApolloClient from './src/utils/apolloClient';
import AuthStorage from './src/utils/authStorage';

const authStorage = new AuthStorage();
const apolloClient = createApolloClient(authStorage);

const App = () => {
  return (
    <NativeRouter>
      <ApolloProvider client={apolloClient}>
        <Main />
      </ApolloProvider>
    </NativeRouter>
  );
};

export default App;

مررنا نسخةً من الصنف الذي يتعامل مع ذاكرة التخزين AuthStorage إلى الدالة createApolloClient مثل وسيط، لأننا سنرسل لاحقًا شهادة التحقق إلى خادم Apollo مع كل طلب. يتوقع خادم Apollo أن تكون شهادة التحقق ضمن ترويسة الاستيثاق وبنفس تنسيق حامل الشهادة <ACCESS_TOKEN>. يمكن تحسين طلب Apollo Client باستخدام الدالة setContext. لنرسل شهادة التحقق إلى خادم Apollo من خلال عميل Apollo بتعديل الدالة createApolloClientفي الملف "apolloClient.js":

import { ApolloClient, InMemoryCache, createHttpLink } from '@apollo/client';
import Constants from 'expo-constants';
import { setContext } from '@apollo/client/link/context';

// ‫قد تحتاج إلى تغيير هذا بناءً على كيفية تكوين URI لخادم Apollo
const { apolloUri } = Constants.manifest.extra;

const httpLink = createHttpLink({
  uri: apolloUri,
});

const createApolloClient = (authStorage) => {
  const authLink = setContext(async (_, { headers }) => {
    try {
      const accessToken = await authStorage.getAccessToken();
      return {
        headers: {
          ...headers,
          authorization: accessToken ? `Bearer ${accessToken}` : '',
        },
      };
    } catch (e) {
      console.log(e);
      return {
        headers,
      };
    }
  });
  return new ApolloClient({
    link: authLink.concat(httpLink),
    cache: new InMemoryCache(),
  });
};

export default createApolloClient;

استخدام React Context لتوزيع البيانات

يبقى علينا في النهاية إجراء تكامل بين ذاكرة التخزين والخطاف useSignIn. ولكي ننجز ذلك لا بدّ من السماح للخطاف بولوج شهادة التحقق التي هيئنا نسخة منها في المكوّن App. سنستخدم الواجهة Context التي تزودنا بها React لأداء هذه المهمة. أنشئ المجلد "contexts" ضمن المجلد "src"، ثم أنشئ ضمنه الملف "AuthStorageContext.js" وضع فيه الشيفرة التالية:

import React from 'react';

const AuthStorageContext = React.createContext();

export default AuthStorageContext;

ستتمكن الآن من استخدام المكوّن AuthStorageContext.Provider لتوزيع نسخة من ذاكرة التخزين على المكوّنات الأبناء ضمن سياق التنفيذ context. لنضفه إلى المكوّن App:

import { NativeRouter } from 'react-router-native';
import { ApolloProvider } from '@apollo/client';


import Main from './src/components/Main';
import createApolloClient from './src/utils/apolloClient';
import AuthStorage from './src/utils/authStorage';
import AuthStorageContext from './src/contexts/AuthStorageContext';

const authStorage = new AuthStorage();
const apolloClient = createApolloClient(authStorage);

const App = () => {
  return (
    <NativeRouter>
      <ApolloProvider client={apolloClient}>
        <AuthStorageContext.Provider value={authStorage}>          
            <Main />
        </AuthStorageContext.Provider>
      </ApolloProvider>
    </NativeRouter>
  );
};

export default App;

يمكن الوصول إلى نسخة ذاكرة التخزين في دالة الخطاف useSignIn باستخدام الخطاف useContext العائد للمكتبة React على النحو التالي:

// ...

import { useContext } from 'react';


import AuthStorageContext from '../contexts/AuthStorageContext';

const useSignIn = () => {

 const authStorage = useContext(AuthStorageContext);
 // ...
};

انتبه إلى أنه من غير الممكن الولوج إلى القيمة التي يعيدها سياق العمل باستخدام الخطاف useContext مالم يُستخدم هذا الخطاف في مكوّن ابن للمكون Context.Provider.

يُعد الوصول إلى نسخة ذاكرة التخزين باستخدام (useContext(AuthStorageContext مطولًا تمامًا ويكشف عن تفاصيل التنفيذ. دعنا نحسن هذا من خلال تنفيذ خطاف useAuthStorage في ملف "useAuthStorage.js" في مجلد "hooks":

import { useContext } from 'react'; 

import AuthStorageContext from '../contexts/AuthStorageContext';

const useAuthStorage = () => {
  return useContext(AuthStorageContext);
};

export default useAuthStorage;

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

// ...
import useAuthStorage from '../hooks/useAuthStorage';

const useSignIn = () => {
  const authStorage = useAuthStorage();
  // ...
};

ستجعل إمكانية توزيع البيانات على المكونات الأبناء من React Context مفتاحًا لحل عدد هائل من الحالات. لتطلع أكثر على هذه الحالات، اقرأ المقالة How to use React Context effectively للمؤلف "Kent C. Dodd"، لتعرف كيف توافق بين استخدام الخطاف useReducer وReact context لتنفيذ آلية لإدارة الحالة. وربما ستجد هذا مفيدًا لحل التمارين القادمة.

التمرينان 10.15 و 10.16

10.15: تخزين شهادة التحقق- الخطوة 2

حسّن شيفرة الخطاف useSignIn لكي يخزّن شهادة التحقق التي تنتج عن الطفرة authenticate، بحيث لا تتغير القيمة التي يعيدها الخطاف. ينبغي أن يكون التغيير الوحيد في المكوّن SignIn هو تحويل المستخدم إلى واجهة عرض قائمة المستودعات بعد أن يسجل دخوله بنجاح. يمكنك إنجاز ذلك باستخدام الخطاف useNavigate.

عليك أن تعيد ضبط مخزن عميل Apollo بعد تنفيذ الطفرة authenticate وتخزين شهادة التحقق في ذاكرة التخزين. سيسبب ذلك مسح الذاكرة المؤقتة وإعادة تنفيذ كل الطلبات النشطة. يمكن إنجاز ذلك باستخدام التابع resetStore العائد للمكتبة Apollo Client. يمكن الوصول إلى عميل Apollo عبر الخطاف useSignIn باستخدام الخطاف useApolloClient. وانتبه إلى أنّ ترتيب خطوات التنفيذ مهم جدًا وينبغي أن يكون على النحو التالي:

const { data } = await mutate(/* خيارات */);
await authStorage.setAccessToken(/* شهادة التحقق مأخوذة من البيانات */);
apolloClient.resetStore();

10.16: تسجيل الخروج

ستكون الخطوة الأخيرة هي تنفيذ ميزة تسجيل الخروج. يمكن استخدام الاستعلام me للتحقق من بيانات الشخص الذي سجّل دخوله. فإن كانت نتيجة الاستعلام "null" فلن يكون الشخص مخوّلًا بالوصول. شغّل أرضية عمل Apollo، ثم نفّذ الاستعلام التالي:

{
  me {
    id
    username
  }
}

ستكون النتيجة غالبًا "null"، والسبب في ذلك أنّ أرضية عمل Apollo غير مفوّضة بالوصول. ويعني ذلك أنها لم ترسل شهادة تحقق مع الطلب. راجع توثيق الاستيثاق لتفهم آلية استخلاص شهادة تحقق من الطفرة authenticate. استخدم هذه الشهادة في ترويسة الاستيثاق كما هو موّضح في التوثيق. نفّذ بعد ذلك الاستعلام me من جديد وسترى معلومات المستخدم الذي سجّل دخوله.

افتح الملف "AppBar.jsx" الذي يحتوي على المكوّنAppBar والذي يحتوي بدوره على النافذتين "Sign in" و"Repositories". عدّل النوافذ بحيث تظهر النافذة "Sign out" إن سجل المستخدم دخوله، والنافذة "Sign in" إن سجّل خروجه. يمكنك إنجاز ذلك باستخدام الاستعلام me مع الخطاف useQuery.

من المفترض أن تُحذف شهادة التحقق من ذاكرة التخزين عند الضغط على النافذة "Sign out"، وأن يُعاد ضبط مخزن عميل Apollo باستخدام التابع resetStore، إذ سيُعاد تنفيذ كل الاستعلامات النشطة تلقائيًا عند استدعاء التابع resetStore، ويعني ذلك إعادة تنفيذ الاستعلام me. تذكّر أن ترتيب خطوات التنفيذ مهم جدًا، ويجب إزالة شهادة التحقق من ذاكرة التخزين قبل إعادة ضبط مخزن عميل Apollo.

ترجمة -وبتصرف- للفصل Communicating with server من سلسلة Deep Dive Into Modern Web Development.

اقرأ أيضًا

• المقال السابق: أساسيات React Native
• مدخل إلى React Native
• مدخل إلى التحريك في React Native
• الاتصال مع الخادم في تطبيق React معتمد على Redux

سنزوّدك من خلال هذا المقال بقائمة من مصادر React التي يمكنك استخدامها للمضي قدمًا في مسار تعلّمك تطوير الواجهات الأمامية وبناء تطبيقات الويب.

• المتطلبات الأساسية: الإلمام بأساسيات لغات HTML وCSS وجافاسكربت JavaScript ومعرفة استخدام سطر الأوامر أو الطرفية.
• الهدف: توفير مصادر إضافية لمعرفة المزيد عن مكتبة React.

التنسيقات على مستوى المكون

تُعرِّف العديد من تطبيقات React تنسيقاتها على أساس كل مكوِّن بدلًا من أن تكون في صفحة تنسيقات واحدة متجانسة، إذ تتيح الأداة create-react-app استيراد ملفات CSS إلى وحدات جافاسكربت، بحيث تُرسَل شيفرة CSS إلى المستخدِم فقط عند تصيير Render المكوِّن المقابل، وقد كان بإمكاننا في تطبيقنا مثلًا كتابة ملف Form.css مخصّص ليحتوي على تنسيقات تلك المكونات، ثم استيراد التنسيقات إلى وحداتها كما يلي:

import Form from './Form';
import './Form.css'

تسهِّل هذه الطريقة تحديد وإدارة شيفرة CSS المُخصَّصة لمكوِّن معيَّن، ولكنها تؤدي إلى تجزئة ملف التنسيقات عبر قاعدة شيفرتك البرمجية، كما يمكن ألّا تكون هذه التجزئة مفيدةً، إذ يُعَدّ الحدّ من مقدار الشيفرة التي ليست ذات فائدة والمُرسَلة إلى المستخدِم، أمرًا منطقيًا بالنسبة للتطبيقات الأكبر حجمًا، والتي تحتوي على مئات من العروض الفريدة والكثير من الأجزاء المتحركة، إذ يُحتمَل أن تكون لديك تنسيقات على مستوى التطبيق وتنسيقات مكونات محدَّدة مبنية فوقها.

أدوات تطوير React

استخدمنا التابع console.log()‎ للتحقق من حالة تطبيقنا وخاصياته Props، إذ سترى بعض التحذيرات المفيدة ورسائل الخطأ التي تعطيها React في واجهة سطر الأوامر CLI وطرفية جافاسكربت في المتصفح. ولكن هناك المزيد الذي نستطيع إجراؤه هنا.

تتيح الأداة المساعدة React DevTools فحص الأجزاء الداخلية لتطبيق React مباشرةً في المتصفح، إذ تضيف لوحةً جديدةً إلى أدوات مطور متصفحك، كما يمكنك بواسطتها فحص حالة المكوّنات المختلفة وخاصياتها، وتعديل الحالة والخاصيات لإجراء تغييرات فورية على تطبيقك، إذ تُظهر لقطة الشاشة التالية تطبيقنا النهائي كما يظهر في الأداة React DevTools:

نرى على اليسار جميع المكونات التي يتألف منها تطبيقنا بما في ذلك بعض المفاتيح الفريدة للأشياء المُصيَّرة من المصفوفات، في حين نرى على اليمين الخاصيات والخطّافات Hooks التي يستخدِمها المكوِّن App، ولاحظ أنّ للمكوّنات Form وFilterButton وTodo مسافةً بادئةً إلى اليمين، وهذا يشير إلى أنّ المكوِّن App هو المكوِّن الأب لها، لذا يُعَدّ هذا العرض رائعًا في التطبيقات الأكثر تعقيدًا لفهم العلاقات بين الأبناء والآباء بسهولة، كما تتوفر الأداة React DevTools في عدد من الأشكال مثل:

• امتداد متصفح كروم Chrome.
• امتداد متصفح فايرفوكس Firefox.
• امتداد متصفح Chromium Edge (سيُتاح قريبًا).
• تطبيق مستقل يمكنك تثبيته باستخدام NPM أو Yarn.

جرّب تثبيت إحدى هذه الأدوات، ثم استخدمها لفحص التطبيق الذي أنشأته للتو.

واجهة برمجة تطبيقات السياق Context API

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

توفِّر React واجهة برمجة تطبيقات السياق Context API بوصفها طريقةً لتوفير البيانات للمكوّنات التي تحتاجها دون تمرير الخاصيات إلى أسفل شجرة المكونات، كما يوجد الخطّاف useContext الذي يسهِّل ذلك.

أصناف المكونات

يمكن بناء مكونات React باستخدام أصناف ES6 التي تُسمَّى بأصناف المكونات Class Components، إذ كانت أصناف ES6 قبل ظهور الخطّافات الطريقة الوحيدة لجلب الحالة إلى المكوّنات أو إدارة آثار التصيير الجانبية، ولا تزال الطريقة الوحيدة للتعامل مع بعض الميزات الأخرى في الحالات الطارئة، وهي شائعة جدًا في مشاريع React القديمة، كما يمكنك الاطلاع على المصادر التالية:

• حالة ودورة حياة المكونات في توثيق React.
• توثيق React على موسوعة حسوب.
• تعلّم لغة جافاسكربت من خلال توثيقها على موسوعة حسوب.

الاختبار

توفِّر create-react-app بعض الأدوات لاختبار تطبيقك، كما يغطي توثيق create-react-app بعض أساسيات الاختبار.

التوجيه

يُعالَج التوجيه تقليديًا باستخدام خادم وليس باستخدام تطبيق على حاسوب المستخدِم، ولكن يمكن ضبط تطبيق ويب لقراءة موقع المتصفح وتحديثه، وتصيير واجهات مستخدِم معيّنة، وهذا ما يسمى بالتوجيه من طرف العميل Client-side Routing، كما يمكن إنشاء العديد من المسارات الفريدة لتطبيقك مثل ‎/home أو ‎/dashboard أو login/‎.

أنتج مجتمع React مكتبتين رئيسيتين للتوجيه من طرف العميل هما React Router وReach Router.

• تُعَدّ مكتبة React Router مناسبةً للتطبيقات ذات احتياجات التوجيه المعقَّدة، كما أنها تلبي بعض الحالات الطارئة بطريقة أفضل من مكتبة Reach Router، ولكن تُعَدّ React Router مكتبةً أكبر.
• تُعَدّ مكتبة Reach Router مناسبةً للتطبيقات الأبسط، وتدير التركيز تلقائيًا أثناء تنقل المستخدِم من صفحة إلى أخرى.

تُعَدّ إدارة التركيز أمرًا ضروريًا في التوجيه من طرف العميل، إذ يمكن وقوع مستخدِمي لوحة المفاتيح في مأزق التركيز، ويمكن ألّا يكون لدى مستخدِمي قارئ الشاشة أيّ فكرة عن انتقالهم إلى صفحة جديدة، في حين تُعَدّ مكتبة Reach Router مكانًا جيدًا للبدء، لأنها أفضل من حيث إمكانية الوصول، لكن سيُدمَج هذان المشروعان في المستقبل القريب، وستكون حينها مكتبة React Router هي المشروع الباقي مع إضافة ميزات إدارة التركيز الخاصة بمكتبة Reach.

أخيرًا، لا تنسى الرجوع إلى توثيق React على موسوعة حسوب فضع هذا المرجع في جعبتك (بالإضافة إلى المراجع الأخرى التي توفرها الموسوعة) والذي ستحتاج إلى الرجوع إليه بين الحين والآخر في رحلة سيرك مع مكتبة React لبناء واجهات المواقع والتطبيقات.

ترجمة -وبتصرُّف- للمقال React resources.

اقرأ أيضًا

• مكونات React الأساسية (React Components)
• المصطلحات المستخدمة في React
• تعلم البرمجة

سنركِّز في هذا المقال على الشمولية Accessibility (أو تترجم إلى سهولة وصول أيضًا) بما في ذلك إدارة التركيز Focus Management في React التي يمكنها تحسين قابلية الاستخدام وتقليل الارتباك لكل من مستخدمي لوحة المفاتيح فقط وقارئات الشاشة.

• المتطلبات الأساسية: الإلمام بأساسيات لغات HTML وCSS وجافاسكربت JavaScript ومعرفة استخدام سطر الأوامر أو الطرفية.
• الهدف: تعلّم كيفية تنفيذ إمكانية وصول مستخدِمي لوحة المفاتيح في React.

مستخدمو لوحة المفاتيح

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

استكشاف مشكلة قابلية استخدام لوحة المفاتيح

انقر على حقل الإدخال الموجود أعلى التطبيق كما لو أنك تريد إضافة مهمة جديدة، إذ سترى خطًا سميكًا يمثل حدود العنصر outline حول حقل الإدخال، إذ تُعَدّ هذه الحدود المؤشر المرئي على تركيز المتصفح على هذا العنصر حاليًا، لذا اضغط على مفتاح Tab من لوحة المفاتيح، وسترى ظهور المخطط حول زر الإضافة Add تحت حقل الإدخال، إذ يدل ذلك على انتقال تركيز المتصفح.

اضغط على مفتاح Tab عدة مرات، وسترى مؤشر التركيز المتقطع ينتقل بين أزرار الترشيح، واستمر في الضغط على مفتاح Tab إلى أن يصبح مؤشر التركيز حول زر التعديل Edit الأول، ثم اضغط على مفتاح Enter، إذ سيبدّل المكوِّن <Todo /‎> بين القوالب كما صمّمنا، وسترى نموذجًا يتيح تعديل اسم المهمة.

ولكن قد تتساءل عن مكان وجود مؤشر التركيز حاليًا، إذ تُزال تمامًا العناصر التي كانت موجودةً سابقًا لاستبدال شيء آخر بها عندما نبدِّل بين القوالب في المكوِّن <Todo /‎>، وهذا يعني اختفاء العنصر الذي ركّزنا عليه سابقًا، ولا يوجد شيء نركّز عليه حاليًا، فقد يؤدي ذلك إلى إرباك مجموعة كبيرة من المستخدِمين، وخاصةً المستخدِمين الذين يعتمدون على لوحة المفاتيح أو الذين يستخدِمون قارئ الشاشة، كما يمكن تحسين تجربة مستخدِمي لوحة المفاتيح وقارئ الشاشة من خلال إدارة تركيز المتصفح بأنفسنا.

التركيز بين القوالب

إذا بدَّل المستخدِم قالب <Todo/‎> من قالب العرض إلى قالب التعديل، فيجب علينا التركيز على العنصر <input> المستخدَم لإعادة تسميته، ويجب علينا إعادة التركيز مرةً أخرى إلى زر التعديل Edit عند التبديل مرةً أخرى من قالب التعديل إلى قالب العرض.

استهداف العناصر

يجب علينا إخبار React بالعنصر الذي نريد التركيز عليه في نموذج DOM وكيفية العثور عليه، ويساعدنا في ذلك الخطّاف useRef في React الذي ينشئ كائنًا له الخاصية current، إذ يمكن أن تكون هذه الخاصية مرجعًا لأيّ شيء نريده، ثم يمكننا البحث عن هذا المرجع لاحقًا، وهذا مفيد للإشارة إلى عناصر DOM، لذا عدِّل تعليمة الاستيراد import في الجزء العلوي من الملف Todo.js لتتضمن الخطّاف useRef كما يلي:

import React, { useRef, useState } from "react";

أنشئ بعد ذلك ثابتَين جديدين بعد الخطّافات في الدالة Todo()‎، إذ يجب أن يكون أحد هذين الثابتين مرجعًا لزر التعديل Edit في قالب العرض والآخر لحقل التعديل في قالب التعديل.

const editFieldRef = useRef(null);
const editButtonRef = useRef(null);

تملك هذه المراجع قيمةً افتراضيةً هي null لأنها ستكون بلا قيمة حين ربطها بالعناصر الخاصة بها من خلال إضافة الخاصية ref لكل عنصر، وضبط قيمها على كائنات ref المسماة بأسماء مناسبة، ويجب تعديل مربع النص <input> في قالب التعديل كما يلي:

<input
  id={props.id}
  className="todo-text"
  type="text"
  value={newName}
  onChange={handleChange}
  ref={editFieldRef}
/>

يجب أن يكون زر التعديل Edit في قالب العرض كما يلي:

<button
  type="button"
  className="btn"
  onClick={() => setEditing(true)}
  ref={editButtonRef}
>
  Edit <span className="visually-hidden">{props.name}</span>
</button>

التركيز على عناصر ref باستخدام الخطاف useEffect

يمكننا استخدام عناصر ref للغرض المقصود منها عن طريق استيراد خطّاف React آخر هو useEffect()‎ الذي سُمِّي بهذا الاسم لأنه يعمل بعد أن تصيِّر React مكونًا معينًا، وسيشغّل هذا الخطّاف أيّ أمور إضافية نريد إضافتها إلى عملية التصيير، والتي لا يمكننا تشغيلها ضمن جسم الدالة الرئيسية، إذ يُعَدّ الخطّاف useEffect()‎ مفيدًا في الوضع الحالي لأننا لا نستطيع التركيز على عنصر إلا بعد تصيير المكوِّن <Todo /‎> ومعرفة React مكان عناصر ref، لذا عدِّل تعليمة الاستيراد import في الملف Todo.js مرةً أخرى لإضافة الخطّاف useEffect كما يلي:

import React, { useEffect, useRef, useState } from "react";

يأخذ الخطّاف useEffect()‎ دالةً على أساس وسيط له، إذ تُنفَّذ هذه الدالة بعد تصيير المكوِّن، لذا ضع استدعاء الخطّاف useEffect()‎ التالي قبل تعليمة return مباشرةً في جسم الدالة Todo()‎، ومرّر إليه دالةً تسجّل العبارة "side effect" في الطرفية:

useEffect(() => {
  console.log("side effect");
});

أضف تابع console.log()‎ آخر، لتوضيح الفرق بين عملية التصيير الرئيسية وتشغيل الشيفرة ضمن الخطّاف useEffect()‎، أي ضع التعليمة التالية بعد الإضافة السابقة:

console.log("main render");

افتح الآن التطبيق في متصفحك، إذ يجب أن ترى كلتا الرسالتين في الطرفية مع تكرار كل منهما ثلاث مرات، ولاحظ ظهور عبارة التصيير الرئيسي main render أولًا، ثم عبارة "side effect" ثانيًا، على الرغم من وجود عبارة "side effect" أولًا في الشيفرة.

main render (3)                                     Todo.js:100
side effect (3)                                     Todo.js:98

احذف تعليمة console.log("main render")‎ الآن، ولننتقل إلى تطبيق إدارة التركيز.

التركيز على حقل التعديل

تذكّر أننا نريد التركيز على حقل التعديل عندما ننتقل إلى قالب التعديل، لذا عدِّل الخطّاف useEffect()‎ ليصبح كما يلي:

useEffect(() => {
  if (isEditing) {
    editFieldRef.current.focus();
  }
}, [isEditing]);

إذا كانت قيمة isEditing هي true، فستقرأ React قيمة مرجع editFieldRef الحالية وتنقل تركيز المتصفح إليه، كما سنمرِّر مصفوفةً إلى الخطّاف useEffect()‎ على أساس وسيط ثان، إذ تُعَدّ هذه المصفوفة قائمةً من القيم التي يجب أن يعتمد عليها الخطّاف useEffect()‎، فإذا ضمّنا هذه القيم، فلن يُشغَّل الخطاف useEffect()‎ إلا عند تغيير إحدى هذه القيم، إذ نريد تغيير التركيز عندما تتغير قيمة isEditing فقط، لذا انتقل إلى متصفحك الآن، وسترى انتقال التركيز إلى العنصر <input> المقابل لزر التعديل Edit عند النقر عليه.

نقل التركيز إلى زر التعديل مرة أخرى

يمكن أن يبدو نقل React للتركيز مرةً أخرى إلى زر التعديل Edit عند حفظ التعديل أو إلغائه أمرًا سهلًا للوهلة الأولى، فلنجرّب إضافة شرط إلى الخطّاف useEffect للتركيز على زر التعديل إذا كانت قيمة الحالة isEditing هي false مثلًا، لذا عدِّل استدعاء الخطّاف useEffect()‎ كما يلي:

useEffect(() => {
  if (isEditing) {
    editFieldRef.current.focus();
  } else {
    editButtonRef.current.focus();
  }
}, [isEditing]);

عُد إلى متصفحك وسترى انتقال تركيزك بين تعديل العنصر <input> وزر التعديل Edit مع بدء التعديل وإنهائه، ولكن يركِّز الزر Edit في المكوِّن <Todo /‎> الأخير مباشرةً على تحميل الصفحة قبل تفاعلنا مع التطبيق، وهنا يتصرّف الخطّاف useEffect()‎ كما صممناه تمامًا، فهو يعمل بمجرد تصيير المكوِّن، ويرى أن قيمة الحالة isEditing هي false، كما يركِّز على الزر Edit، وبما أنه يوجد ثلاث نسخ من المكوِّن <Todo /‎>، فإننا نرى التركيز على الزر Edit الأخير، إذ يجب إعادة التفكير ليتغير التركيز عندما تتغير قيمة الحالة isEditing فقط.

إدارة التركيز الصارمة

يجب معرفة قيمة الحالة isEditing ومتى تتغير هذه القيمة، لذا يجب أن نكون قادرين على قراءة قيمة isEditing السابقة، ويجب أن يكون منطق العمل كما يلي باستخدام الشيفرة الوهمية التالية:

if (wasNotEditingBefore && isEditingNow) {
  focusOnEditField()
}
if (wasEditingBefore && isNotEditingNow) {
  focusOnEditButton()
}

ناقش فريق React طرقًا للحصول على حالة المكوِّن السابقة، وقدّم مثالًا عن الخطّاف المُخصَّص الذي يمكننا استخدامه لذلك.

الصق الشيفرة التالية بالقرب من أعلى الملف Todo.js قبل الدالة Todo()‎:

function usePrevious(value) {
  const ref = useRef();
  useEffect(() => {
    ref.current = value;
  });
  return ref.current;
}

سنعرِّف الآن الثابت wasEditing بعد الخطّافات في الجزء العلوي من الدالة Todo()‎، إذ نريد أن يتتبع هذا الثابت قيمة isEditing السابقة، لذلك سنستدعي الدالة usePrevious مع isEditing على أساس وسيط كما يلي:

const wasEditing = usePrevious(isEditing);

يمكننا باستخدام هذا الثابت تحديث الخطّاف useEffect()‎ لتطبيق الشفرة الوهمية التي ناقشناها سابقًاـ لذا عدِّل هذه الشيفرة لتصبح كما يلي:

useEffect(() => {
  if (!wasEditing && isEditing) {
    editFieldRef.current.focus();
  }
  if (wasEditing && !isEditing) {
    editButtonRef.current.focus();
  }
}, [wasEditing, isEditing]);

لاحظ اعتماد منطق useEffect()‎ الآن على الثابت wasEditing، لذلك سنقدِّمه ضمن مصفوفة الاعتماديات، وحاول مرةً أخرى استخدام زرَي التعديل Edit والإلغاء Cancel للتبديل بين قوالب المكوِّن <Todo /‎>، إذ سترى مؤشر تركيز المتصفح يتحرك بطريقة مناسبة دون ظهور المشكلة التي ناقشناها سابقًا.

التركيز عندما يحذف المستخدم مهمة

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

يكون المكان الذي نرغب في إرسال تركيزنا إليه واضحًا في بعض الأحيان، إذ كانت لدينا نقطة أصل للرجوع إليها وهي زر التعديل Edit عند التبديل بين قوالب <Todo /‎>، لكن لا يوجد مكان للرجوع إليه في حالتنا، لأننا نزيل العناصر تمامًا من نموذج DOM، فعنوان القائمة هو أفضل خيار لأنه قريب من عنصر القائمة الذي سيحذفه المستخدِم، كما سيخبر التركيز عليه المستخدِم بعدد المهام المتبقية.

إنشاء المرجع

استورد الخطّافَين useRef()‎ وuseEffect()‎ إلى الملف App.js كما يلي:

import React, { useState, useRef, useEffect } from "react";

صرّح بعد ذلك عن مرجع جديد ضمن الدالة App()‎ قبل تعليمة return مباشرةً كما يلي:

const listHeadingRef = useRef(null);

تحضير العنوان

لا تكون عناصر العنوان مثل <h2> قابلةً للتركيز عادةً، ولكن لا يُعَدّ ذلك مشكلة، إذ يمكننا جعل أيّ عنصر قابلًا للتركيز برمجيًا عن طريق إضافة السمة tabindex="-1"‎ إليه، أي يمكن التركيز عليه باستخدام لغة جافاسكربت فقط، كما لا يمكنك الضغط على مفتاح Tab للتركيز على عنصر له السمة tabindex="-1"‎ باستخدام الطريقة نفسها التي يمكنك اتباعها مع عناصر <button> أو <a>، إذ يمكن تطبيق ذلك باستخدام السمة tabindex="0"‎، ولكنه لا يُعَدّ مناسبًا في هذه الحالة.

لنضِف السمة tabindex المكتوبة بالصورة tabIndex في صيغة JSX إلى العنوان الموجود أعلى قائمة المهام مع المرجع headingRef كما يلي:

<h2 id="list-heading" tabIndex="-1" ref={listHeadingRef}>
  {headingText}
</h2>

ملاحظة: تُعَدّ السمة tabindex رائعةً لحالات إمكانية الوصول الطارئة، ولكن يجب عليك الحرص على عدم الإفراط في استخدامها، إذ يمكنك تطبيقها على عنصر فقط عندما تكون متأكدًا تمامًا من أنّ جعله قابلًا للتركيز سيفيد المستخدِم بطريقة ما، كما يجب عليك استخدام العناصر التي يمكن التركيز عليها طبيعيًا مثل الأزرار وعناصر الروابط وحقول الإدخال، في حين يمكن أن يكون لاستخدام السمة tabindex غير المسؤول تأثيرًا سلبيًا عميقًا على مستخدِمي لوحة المفاتيح وقارئات الشاشة.

الحصول على الحالة السابقة

نريد التركيز على العنصر المرتبط بالمرجع باستخدام السمة ref عندما يحذف المستخدِم مهمةً من القائمة فقط، إذ سيتطلب ذلك الخطّاف usePrevious()‎ الذي استخدمناه سابقًا، لذا أضف هذا الخطّاف في أعلى الملف App.js بعد عبارات الاستيراد مباشرةً كما يلي:

function usePrevious(value) {
  const ref = useRef();
  useEffect(() => {
    ref.current = value;
  });
  return ref.current;
}

أضف الآن ما يلي قبل تعليمة return ضمن الدالة App()‎:

const prevTaskLength = usePrevious(tasks.length);

استدعينا الخطّاف usePrevious()‎ لتتبع طول حالة المهام.

ملاحظة: بما أننا نستخدِم الآن الخطّاف usePrevious()‎ في ملفين، فستتمثّل إعادة البناء الفعالة في نقل الدالة usePrevious()‎ إلى ملفها، وتصديرها من هذا الملف، واستيرادها حيث تريدها.

استخدام الخطاف useEffect()‎ للتحكم في التركيز الرئيسي

يمكننا الآن إعداد الخطّاف useEffect()‎ لتشغيله عندما يتغير عدد المهام، والذي سيركِّز على العنوان إذا كان عدد المهام أقل مما كان عليه سابقًا، أي أننا حذفنا مهمةً.

أضف ما يلي إلى جسم الدالة App()‎ بعد الإضافات السابقة مباشرةً:

useEffect(() => {
  if (tasks.length - prevTaskLength === -1) {
    listHeadingRef.current.focus();
  }
}, [tasks.length, prevTaskLength]);

نحاول التركيز فقط على عنوان القائمة إذا كانت لدينا مهام أقل مما كانت عليه سابقًا، إذ تضمن الاعتماديات Dependencies االمُمرَّرة في هذا الخطّاف محاولة إعادة التشغيل فقط عندما تتغير أيّ من هذه القيم، أي عدد المهام الحالية أو عدد المهام السابقة، وسترى الآن ظهور مخطط التركيز المنقط حول العنوان أعلى القائمة عندما تحذف مهمةً في متصفحك.

الخلاصة

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

يُعَدّ الخطّافان useRef()‎ وuseEffect()‎ ميزات متقدمةً إلى حد ما، ويجب أن تفخر بنفسك لاستخدامها، وابحث عن فرص لممارستها أكثر، مما سيسمح لك بإنشاء تجارب شاملة للمستخدِمين، إذ يمكن تعذُّر الوصول إلى تطبيقنا لمستخدِمي لوحة المفاتيح بدونهما.

ملاحظة: إذا كنت بحاجة إلى التحقق من شيفرتك مقابل نسختنا من الشيفرة، فيمكنك العثور على نسخة نهائية من نموذج شيفرة تطبيق React في المستودع todo-reaction. كما يمكنك الحصول على إصدار مباشر قيد التشغيل من خلال مراجعة todo-react-build.

سنقدِّم في المقال التالي قائمةً بموارد React التي يمكنك استخدامها للمضي قدمًا في مسار تعلّمك.

ترجمة -وبتصرُّف- للمقال Accessibility in React.

اقرأ أيضًا

• تنفيذ التفاعل في تطبيق React: التعديل والترشيح والتصيير الشرطي
• إنشاء تطبيق قائمة مهام باستخدام React
• تقسيم تطبيق React إلى مكونات
• أساسيات بناء تطبيقات الويب

سنضيف في هذا المقال اللمسات الأخيرة على وظائف تطبيق قائمة المهام Todo List الرئيسية -الذي بنيناه في المقالات السابقة- من خلال السماح بتعديل المهام الحالية، وترشيح Filtering قائمة المهام جميعها والمهام المكتملة وغير المكتملة فقط، كما سنتعرّف على التصيير الشرطي Conditional Rendering لواجهة المستخدِم UI.

• المتطلبات الأساسية: الإلمام بأساسيات لغات HTML وCSS وجافاسكربت JavaScript ومعرفة استخدام سطر الأوامر أو الطرفية.
• الهدف: التعرف على التصيير الشرطي في React وتطبيق ترشيح القائمة وتعديل واجهة مستخدِم في تطبيقنا.

تعديل اسم المهمة

لا توجد لدينا واجهة مستخدِم لتعديل اسم المهمة حتى الآن، ولكن يمكننا على الأقل تنفيذ الدالة editTask()‎ في الملف App.js حاليًا، والتي تشبه الدالة deleteTask()‎ لأنها ستأخذ معرِّفًا id للعثور على الكائن الهدف، وستأخذ الخاصية newName التي تحتوي على الاسم الذي سنعدّل اسم المهمة إليه، في حين أننا سنستخدِم التابع Array.prototype.map()‎ بدلًا من التابع Array.prototype.filter()‎ لأننا نريد إعادة مصفوفة جديدة مع بعض التعديلات بدلًا من حذف شيء منها، لذا أضف الدالة editTask()‎ ضمن المكوِّن App مع الدوال الأخرى كما يلي:

function editTask(id, newName) {
  const editedTaskList = tasks.map(task => {
  // إذا كانت هذه المهمة لها معرّف المهمة المعدّلة نفسه
    if (id === task.id) {
      //
      return {...task, name: newName}
    }
    return task;
  });
  setTasks(editedTaskList);
}

مرِّر editTask إلى مكونات <Todo /‎> بوصفها خاصيةً Prop بالطريقة نفسها التي مررنا بها الخاصية deleteTask كما يلي:

const taskList = tasks.map(task => (
  <Todo
    id={task.id}
    name={task.name}
    completed={task.completed}
    key={task.id}
    toggleTaskCompleted={toggleTaskCompleted}
    deleteTask={deleteTask}
    editTask={editTask}
  />
));

افتح الآن الملف Todo.js، إذ سنُجري إعادة بناء.

واجهة مستخدم التعديل

يجب توفير واجهة مستخدِم للمستخدِمين للسماح لهم بتعديل مهمة، لذا استورد أولًا الخطّاف useState إلى المكوِّن Todo كما فعلنا سابقًا مع المكوِّن App عن طريق تعديل تعليمة الاستيراد الأولى إلى ما يلي:

import React, { useState } from "react";

سنضبط الآن الحالة isEditing التي يجب أن تكون قيمتها الافتراضية false، لذا أضف السطر التالي في الجزء العلوي من تعريف المكون Todo(props) { … }‎:

const [isEditing, setEditing] = useState(false);

كما يجب إعادة التفكير في المكوِّن <Todo /‎> من الآن فصاعدًا، إذ نريد منه عرض أحد القالبَين التاليين بدلًا من القالب الوحيد المستخدَم حتى الآن:

• قالب العرض View عند عرض المهام فقط، وهو ما استخدمناه حتى الآن.
• قالب التعديل Editing عند تعديل المهام، وسننشئه بعد قليل.

انسخ الشيفرة التالية في الدالة Todo()‎ بعد الخطّاف useState()‎ وقبل التعليمة return:

const editingTemplate = (
  <form className="stack-small">
    <div className="form-group">
      <label className="todo-label" htmlFor={props.id}>
        New name for {props.name}
      </label>
      <input id={props.id} className="todo-text" type="text" />
    </div>
    <div className="btn-group">
      <button type="button" className="btn todo-cancel">
        Cancel
        <span className="visually-hidden">renaming {props.name}</span>
      </button>
      <button type="submit" className="btn btn__primary todo-edit">
        Save
        <span className="visually-hidden">new name for {props.name}</span>
      </button>
    </div>
  </form>
);
const viewTemplate = (
  <div className="stack-small">
    <div className="c-cb">
        <input
          id={props.id}
          type="checkbox"
          defaultChecked={props.completed}
          onChange={() => props.toggleTaskCompleted(props.id)}
        />
        <label className="todo-label" htmlFor={props.id}>
          {props.name}
        </label>
      </div>
      <div className="btn-group">
        <button type="button" className="btn">
          Edit <span className="visually-hidden">{props.name}</span>
        </button>
        <button
          type="button"
          className="btn btn__danger"
          onClick={() => props.deleteTask(props.id)}
        >
          Delete <span className="visually-hidden">{props.name}</span>
        </button>
      </div>
  </div>
);

أصبح لدينا الآن بنيتا قوالب مختلفتين -"Edit" و"View"- معرّفتان ضمن ثابتين منفصلين، وهذا يعني أنّ التعليمة return الخاصة بالمكوِّن <Todo /‎> مكررة، فهي تحتوي على تعريف قالب العرض View أيضًا، ويمكن تنظيف هذا التكرار باستخدام التصيير الشرطي Conditional Rendering لتحديد القالب الذي يعيده المكوِّن، وبالتالي يُصيَّر في واجهة المستخدِم.

التصيير الشرطي

يمكننا في صيغة JSX استخدام شرط لتغيير ما يصيّره المتصفح، إذ يُكتَب الشرط في صيغة JSX باستخدام معامِل ثلاثي Ternary Operator، فالشرط في حالة المكوِّن <Todo /‎> هو "هل تُعدَّل هذه المهمة؟"، لذا عدِّل التعليمة return ضمن الدالة Todo()‎، بحيث تصبح كما يلي:

return <li className="todo">{isEditing ? editingTemplate : viewTemplate}</li>;

يجب أن يصيّر متصفحك جميع مهامك كما كانت سابقًا، ويمكن مشاهدة قالب التعديل من خلال تغيير القيمة الافتراضية للحالة isEditing من false إلى true في شيفرتك حاليًا، إذ سنجعل زر التعديل Edit يبدِّل هذه القيمة لاحقًا.

التبديل بين قوالب

سنجعل الآن ميزة التعديل تفاعليةً، إذ يجب أولًا استدعاء الدالة setEditing()‎ مع القيمة true عندما يضغط المستخدِم على زر التعديل Edit في قالب العرض viewTemplate لنتمكّن من التبديل بين القوالب، لذا عدِّل زر التعديل Edit في قالب العرض viewTemplate كما يلي:

<button type="button" className="btn" onClick={() => setEditing(true)}>
  Edit <span className="visually-hidden">{props.name}</span>
</button>

سنضيف الآن السمة onClick نفسها إلى زر الإلغاء Cancel في قالب التعديل editingTemplate، ولكن سنضبط الحالة isEditing هذه المرة على القيمة false لتعيدنا إلى قالب العرض، لذا عدِّل زر الإلغاء Cancel في قالب التعديل editingTemplate كما يلي:

<button
  type="button"
  className="btn todo-cancel"
  onClick={() => setEditing(false)}
>
  Cancel
  <span className="visually-hidden">renaming {props.name}</span>
</button>

يجب أن تكون قادرًا الآن على الضغط على زرَي التعديل Edit والإلغاء Cancel في عناصر المهام للتبديل بين القالبين.

الخطوة التالية هي جعل وظيفة التعديل تعمل فعليًا.

التعديل من واجهة المستخدم

ما سنعمل عليه تاليًا مماثل لما عملنا عليه مع المكون Form (انظر المقال السابق تقسيم تطبيق React إلى مكونات).

إذا كتب المستخدِم شيئًا في حقل الإدخال الجديد، فيجب تتبّع النص الذي يدخله، ويجب استخدام خاصية رد النداء Callback Prop بمجرد إرسال النموذج لتحديث الحالة باسم المهمة الجديد، إذ سنبدأ بإنشاء خطّاف Hook جديد لتخزين وضبط الاسم الجديد، لذا ضع ما يلي أسفل الخطّاف الموجود مسبقًا في الملف Todo.js:

const [newName, setNewName] = useState('');

أنشئ بعد ذلك الدالة handleChange()‎ التي تضبط الاسم الجديد، لذا ضع ما يلي بعد الخطافات وقبل القوالب:

function handleChange(e) {
  setNewName(e.target.value);
}

سنعدِّل الآن الحقل <input /‎> الخاص بقالب التعديل editingTemplate بضبط السمة value على newName وربط الدالة handleChange()‎ مع الحدث onChange كما يلي: