الترحيل من React إلى Next.js

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

هذا هو الترحيل للفرق على Create React App أو Vite أو إعداد React مصنوع يدويًا - لا للفرق التي هي أصلًا على Pages Router، فتلك مشكلة أخرى بمسار آخر.

ما الذي يتغيّر فعلًا

التوجيه. مسارات React Router القائمة على المكوّنات تصير شجرة ملفات. فـ <Route path="/products/:id"> تصير app/products/[id]/page.tsx. والمسارات المتداخلة ذات الإطار المشترك تصير تخطيطات متداخلة، وهو أبسط عادةً ممّا كان.

جلب البيانات. هنا معظم العمل. تطبيق الصفحة الواحدة يجلب في useEffect بعد التركيب، ما يعني مؤشّر تحميل، وشلّالًا، ولا شيء يقرأه الزاحف. وفي Next.js يعمل الجلب نفسه على الخادم قبل إرسال الاستجابة. فيكفّ المكوّن عن إدارة حالة التحميل ويصير دالّة async.

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

افتراضات المتصفّح. window وlocalStorage وdocument على مستوى الوحدة تنهار على الخادم. إيجادها عمل آلي؛ أما تقرير أيّها ينتمي إلى مكوّن عميل وأيّها لم يكن لازمًا أصلًا فهو الحكم.

الترتيب الذي نعمل به

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

1. الهيكل ومسار طرفي واحد. يُرسي التخطيط ومساعد البيانات الوصفية وأعراف البيانات على شيء قليل الخطر.
2. المسارات التي تهمّ محرّكات البحث. الصفحات التسويقية وصفحات المنتجات وكل ما هو عام. هنا العائد، لأن هذه تحديدًا هي الصفحات التي لم يكن لها HTML معروض على الخادم إطلاقًا.
3. المسارات المُوثَّقة. لوحات التحكّم والإعدادات. وغالبًا تبقى معروضة في جهة العميل، وهذا صحيح - فلا قيمة سيو خلف تسجيل دخول، وApp Router لا يمانع بقاءها تفاعلية.
4. البناء القديم، محذوفًا. لا قبل ذلك.

ما ينبغي أن تتوقّع كسبه

النسخة الصادقة: مكسب الأداء حقيقي لكنه متفاوت، ومكسب السيو أكبر عادةً.

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

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

ما نحتاج رؤيته أولًا

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

ما الذي تحصلون عليه

التطبيق على Next.js، منقولًا مسارًا بمسار، بمراحل وعدد مسارات لكل مرحلة متفق عليهما قبل البدء. وكل مرحلة قابلة للمراجعة وحدها وتترك خلفها تطبيقًا يعمل.

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