بناء تطبيق React من الصفر

الخطوة 1: تثبيت أداة build

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

Vite

Vite هي أداة build تهدف إلى توفير تجربة تطوير أسرع وأبسط لمشاريع الويب الحديثة.

Vite لديها آراء محددة وتأتي مع إعدادات افتراضية معقولة خارج الصندوق. لدى Vite نظام بيئي غني من plugins لدعم fast refresh و JSX و Babel/SWC وميزات شائعة أخرى. راجع React plugin أو React SWC plugin من Vite و مثال مشروع React SSR للبدء.

يتم استخدام Vite بالفعل كأداة build في أحد أطر العمل الموصى بها: React Router.

Parcel

Parcel يجمع بين تجربة تطوير رائعة خارج الصندوق مع بنية قابلة للتوسع يمكن أن تأخذ مشروعك من مجرد البدء إلى تطبيقات إنتاج ضخمة.

يدعم Parcel fast refresh و JSX و TypeScript و Flow والتنسيق خارج الصندوق. راجع وصفة React من Parcel للبدء.

Rsbuild

Rsbuild هي أداة build مدعومة بـ Rspack توفر تجربة تطوير سلسة لتطبيقات React. تأتي مع إعدادات افتراضية مضبوطة بعناية وتحسينات أداء جاهزة للاستخدام.

يتضمن Rsbuild دعمًا مدمجًا لميزات React مثل fast refresh و JSX و TypeScript والتنسيق. راجع دليل React من Rsbuild للبدء.

الخطوة 2: بناء أنماط التطبيقات الشائعة

أدوات build المدرجة أعلاه تبدأ بتطبيق client-only و single-page (SPA)، لكنها لا تتضمن أي حلول أخرى للوظائف الشائعة مثل التوجيه وجلب البيانات أو التنسيق.

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

التوجيه

يحدد التوجيه المحتوى أو الصفحات التي سيتم عرضها عندما يزور المستخدم URL معين. تحتاج إلى إعداد router لربط URLs بأجزاء مختلفة من تطبيقك. ستحتاج أيضًا إلى التعامل مع nested routes و route parameters و query parameters. يمكن تكوين Routers داخل كودك، أو تعريفها بناءً على مجلد المكونات وهياكل الملفات.

Routers هي جزء أساسي من التطبيقات الحديثة، وعادة ما تكون متكاملة مع جلب البيانات (بما في ذلك prefetching البيانات لصفحة كاملة لتحميل أسرع)، و code splitting (لتقليل أحجام حزم client)، وأساليب تصيير الصفحات (لتحديد كيفية إنشاء كل صفحة).

نقترح استخدام:

• React Router
• Tanstack Router

جلب البيانات

جلب البيانات من خادم أو مصدر بيانات آخر هو جزء أساسي من معظم التطبيقات. القيام بذلك بشكل صحيح يتطلب التعامل مع حالات التحميل وحالات الخطأ وتخزين البيانات المجلوبة مؤقتًا، والذي يمكن أن يكون معقدًا.

مكتبات جلب البيانات المصممة لهذا الغرض تقوم بالعمل الشاق لجلب البيانات وتخزينها مؤقتًا نيابة عنك، مما يتيح لك التركيز على البيانات التي يحتاجها تطبيقك وكيفية عرضها. تُستخدم هذه المكتبات عادةً مباشرة في مكوناتك، ولكن يمكن أيضًا دمجها في router loaders لـ pre-fetching أسرع وأداء أفضل، وفي server rendering أيضًا.

لاحظ أن جلب البيانات مباشرة في المكونات يمكن أن يؤدي إلى أوقات تحميل أبطأ بسبب شلالات طلبات الشبكة، لذلك نوصي بـ prefetching البيانات في router loaders أو على server قدر الإمكان! يسمح هذا بجلب بيانات الصفحة دفعة واحدة أثناء عرض الصفحة.

إذا كنت تجلب البيانات من معظم backends أو REST-style APIs، فإننا نقترح استخدام:

• React Query
• SWR
• RTK Query

إذا كنت تجلب البيانات من GraphQL API، فإننا نقترح استخدام:

• Apollo
• Relay

Code-splitting

Code-splitting هي عملية تقسيم تطبيقك إلى حزم أصغر يمكن تحميلها عند الطلب. يزداد حجم كود التطبيق مع كل ميزة جديدة وتبعية إضافية. يمكن أن تصبح التطبيقات بطيئة في التحميل لأن كل الكود للتطبيق بأكمله يحتاج إلى إرساله قبل أن يمكن استخدامه. يمكن أن يساعد Caching وتقليل الميزات/التبعيات ونقل بعض الكود للتشغيل على server في تخفيف التحميل البطيء ولكنها حلول غير كاملة يمكن أن تضحي بالوظائف إذا تم الإفراط في استخدامها.

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

تقسيم الكود حسب route، عند دمجه مع bundling وجلب البيانات، يمكن أن يقلل من وقت التحميل الأولي لتطبيقك والوقت الذي يستغرقه أكبر محتوى مرئي للتطبيق للتصيير (Largest Contentful Paint).

للحصول على تعليمات code-splitting، راجع مستندات أداة build الخاصة بك:

• تحسينات build من Vite
• تقسيم الكود من Parcel
• تقسيم الكود من Rsbuild

تحسين أداء التطبيق

نظرًا لأن أداة build التي تحددها تدعم فقط single page apps (SPAs)، ستحتاج إلى تنفيذ أنماط تصيير أخرى مثل server-side rendering (SSR) و static site generation (SSG) و/أو React Server Components (RSC). حتى إذا لم تكن بحاجة إلى هذه الميزات في البداية، في المستقبل قد تكون هناك بعض routes التي ستستفيد من SSR أو SSG أو RSC.

• Single-page apps (SPA) تحمل صفحة HTML واحدة وتحدّث الصفحة ديناميكيًا مع تفاعل المستخدم مع التطبيق. SPAs أسهل في البدء بها، لكن يمكن أن يكون لها أوقات تحميل أولية أبطأ. SPAs هي البنية الافتراضية لمعظم أدوات build.

• Streaming Server-side rendering (SSR) يصيّر صفحة على server ويرسل الصفحة المصيّرة بالكامل إلى client. يمكن أن يحسن SSR الأداء، لكنه يمكن أن يكون أكثر تعقيدًا في الإعداد والصيانة من تطبيق single-page. مع إضافة streaming، يمكن أن يكون SSR معقدًا جدًا في الإعداد والصيانة. راجع دليل SSR من Vite.

• Static site generation (SSG) ينشئ ملفات HTML ثابتة لتطبيقك في وقت build. يمكن أن يحسن SSG الأداء، لكنه يمكن أن يكون أكثر تعقيدًا في الإعداد والصيانة من server-side rendering. راجع دليل SSG من Vite.

• React Server Components (RSC) يتيح لك مزج مكونات build-time و server-only والمكونات التفاعلية في شجرة React واحدة. يمكن أن يحسن RSC الأداء، لكنه يتطلب حاليًا خبرة عميقة للإعداد والصيانة. راجع أمثلة RSC من Parcel.

تحتاج استراتيجيات التصيير الخاصة بك إلى التكامل مع router الخاص بك حتى تتمكن التطبيقات المبنية بإطار العمل الخاص بك من اختيار استراتيجية التصيير على مستوى كل route. سيمكن هذا من استراتيجيات تصيير مختلفة دون الحاجة إلى إعادة كتابة تطبيقك بالكامل. على سبيل المثال، قد تستفيد الصفحة المقصودة لتطبيقك من كونها مولدة بشكل ثابت (SSG)، بينما قد تعمل صفحة تحتوي على موجز محتوى بشكل أفضل مع server-side rendering.

يمكن أن يقلل استخدام استراتيجية التصيير الصحيحة لـ routes الصحيحة من الوقت الذي يستغرقه تحميل أول بايت من المحتوى (Time to First Byte)، وأول جزء من المحتوى للتصيير (First Contentful Paint)، وأكبر محتوى مرئي للتطبيق للتصيير (Largest Contentful Paint).

والمزيد…

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

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