ترحيل مشاريع Next.js وإنقاذها

حالتان تدفعان معظم الفرق إلى طرق بابنا. إمّا أن يكون تطبيق Next.js قائم قد فاق حدود Pages Router ولم يعد المسار التدريجي واضحًا، وإمّا أن يكون تطبيق بناه آخرون قد صار شيئًا يخشى الفريق الحالي نشره.

كلتا الحالتين قابلة للحل. ولا واحدة منهما تستدعي إعادة الكتابة من الصفر.

من Pages Router إلى App Router

الموجّهان يعملان معًا، وهذه هي الاستراتيجية بأكملها: تطبيق واحد يتعايش فيه app/ وpages/، ويُرحَّل من الأوراق إلى الجذر، وينتقل كل مسار خلف pull request خاص به وتحقّق خاص به.

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

من إطار عمل آخر إلى Next.js

‏Create React App، وتطبيقات Vite أحادية الصفحة، وGatsby، وذيل طويل من إعدادات webpack المفصّلة يدويًا. الجزء الميكانيكي هو التوجيه وإعداد البناء؛ أمّا الجزء الذي يتطلّب حُكمًا فهو تحديد أيّ افتراضات التطبيق كانت آثارًا لإطار العمل وأيّها كان متطلّبًا حقيقيًا.

قواعد الشيفرة الموروثة

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

ونرى في ذلك نتيجة معقولة تمامًا.