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

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

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

من Pages Router إلى App Router

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

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

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

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

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

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

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

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

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

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

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

ما الذي يُبقي الترحيل متماسكًا

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

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

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

تحقّق لكل مسار لا لكل إصدار. كل مسار منتقل يُفحص في وضع العرض وحجم الحزمة والسلوك قبل أن يبدأ الذي يليه.

متى يكون التدقيق الخطوة الأولى الأفضل

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

كيف تُحدَّد

أول مُخرَج خريطة لا ترحيل: أي المسارات موجود، وعلامَ يعتمد كلٌّ منها، وأيها لم يعد أحد يقدر على تفسيره.

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

ثم المراحل، مسارًا بمسار، والموجّهان يعملان حتى ينتقل آخرهما.

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

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

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