دمج نظام محتوى بلا واجهة

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

ما نبنيه

محتوى محدَّد الأنواع من طرفه إلى طرفه. مخطّط النظام يولّد أنواع TypeScript، وطبقة الجلب تحلّل ما يعود لا تدّعيه. عندها يفشل الحقل المُعاد تسميته عند البناء أو عند الحافة برسالة تسمّيه - لا بعد ثلاثة مكوّنات على هيئة undefined is not a function.

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

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

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

أي نظام

لسنا مرتبطين بواحد، وسنخبرك إن كان الذي اخترته غير مناسب لما تفعله - لكن هذا نادرًا ما يكون السؤال المهم. الدمج هو معظم العمل، وشكله واحد تقريبًا أيًّا كان اختيارك.

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

ما نحتاجه منك

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