بنية تقنية: بناء محرك مقارنة سفر باستخدام Next.js 14 و TypeScript Strict

المقدمة: لماذا نحتاج إلى بيئة تقنية صارمة للسفر

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

لذلك، لإعادة تصميم منصتنا في عام 2026، اخترنا بنية تعتمد على Next.js 14 مع App Router، مقترنة بإعداد TypeScript في الوضع الصارم. يسمح لنا هذا الجمع بالاستفادة من ميزات العرض من جانب الخادم (Server Components) لتحسين SEO، مع فرض أمان في الأنواع يقلل بشكل كبير من الأخطاء في بيئة الإنتاج. وفقًا للوثائق الرسمية لـ Next.js، يمثل App Router التطور الأساسي لإدارة المسارات والتخطيطات، مما يسمح بدقة细قة في التخزين المؤقت وبث البيانات.

في هذه المقالة، سنفصل الخيارات التقنية التي تدعم محرك المقارنة الخاص بنا، مع التركيز على إعداد TypeScript، وإدارة البيانات عبر Server Actions، وتحسين أداء الويب الأساسي.

Next.js 14 و App Router: قلب النظام

يمثل اعتماد App Router في Next.js 14 تحولًا في النموذج مقارنة بـ Pages Router التاريخي. بالنسبة لمحرك مقارنة سفر، حيث تكون بنية الصفحات هرمية (الرئيسية > الوجهة > النقل > التفاصيل)، يوفر نظام التوجيه القائم على نظام الملفات في App Router وضوحًا لا غنى عنه.

مكونات الخادم (Server Components) افتراضيًا

إحدى المزايا الرئيسية هي استخدام React Server Components (RSC) افتراضيًا. في محرك المقارنة الخاص بنا، يتم عرض قوائم نتائج البحث (قطارات، حافلات، رحلات جوية) على جانب الخادم. هذا يعني أن كود جلب البيانات يتم تنفيذه مباشرة على الخادم، بالقرب من قاعدة البيانات أو واجهات برمجة التطبيقات التابعة لجهات خارجية (SNCF, DB, Eurail). هذا يلغي الحاجة إلى حالة تحميل يراها المستخدم للمحتوى الأولي ويحسن Largest Contentful Paint (LCP)، وهو مقياس أساسي لـ Core Web Vitals الذي تحدده Google.

على عكس الأساليب السابقة حيث كان على العميل جلب البيانات عبر useEffect، نستخدم الآن مكونات غير متزامنة مباشرة في تسلسل المسارات. فيما يلي مثال مبسط لصفحة النتائج الخاصة بنا:

// app/search/results/page.tsx
import { searchTrips } from '@/lib/api';
import { TripList } from './trip-list';

export default async function SearchResults({ searchParams }: { searchParams: { from: string; to: string } }) {
  const trips = await searchTrips(searchParams.from, searchParams.to);
  
  return (
    <main>
      <h1>نتائج من {searchParams.from} إلى {searchParams.to}</h1>
      <TripList trips={trips} />
    </main>
  );
}

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

إدارة التخطيطات المتداخلة (Nested Layouts)

تتطلب بنية تطبيقنا تخطيطات persistent، مثل شريط التنقل وتذييل الصفحة، والتي لا يجب إعادة تحميلها أثناء التنقل بين صفحات النتائج. يدير App Router هذا بشكل أصلي عبر ملف layout.tsx. بالإضافة إلى ذلك، يمكن أن يكون لدينا تخطيطات محددة لأقسام معينة، مثل قسم "Nightjet" أو "Eurail"، مما يسمح بحقن نصوص برمجية أو أنماط محددة دون التأثير على بقية التطبيق.

TypeScript Strict: أمان لا غنى عنه

استخدام TypeScript أمر، واستخدامه في الوضع strict أمر آخر. في ملف tsconfig.json الخاص بنا، نقوم بتفعيل جميع خيارات الصرامة. يتضمن ذلك noImplicitAny، و strictNullChecks، و strictFunctionTypes. بالنسبة لمحرك مقارنة يجمع بيانات من واجهات برمجة تطبيقات متعددة غير متجانسة، فإن أمان الأنواع هو خط دفاعنا الأول.

إعدادات tsconfig.json

فيما يلي أساس إعدادات TypeScript الخاصة بنا، المتوافقة مع توصيات عام 2026 لمشاريع المؤسسات:

{
  "compilerOptions": {
    "target": "ES2022",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "bundler",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true,
    "plugins": [{ "name": "next" }]
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"],
  "exclude": ["node_modules"]
}

يجبر الخيار strict: true المطور على التعامل صراحة مع الحالات التي قد تكون فيها المتغيرات undefined أو null. في سياق السفر، قد يكون السعر صفرًا (عرض مجاني)، وقد缺少 وقت المغادرة (رحلة غير مكتملة). يجبرنا TypeScript على التعامل مع هذه الحالات صراحة، مما يتجنب الأخطاء الكلاسيكية من نوع Cannot read property of undefined.

تحديد أنواع متغيرات البيئة

خطأ شائع في مشاريع Next.js هو الاستخدام غير المحدد الأنواع لمتغيرات البيئة. نستخدم مكتبة مثل t3-env أو مخطط Zod مخصص للتحقق من صحة المتغيرات عند بدء تشغيل الخادم. يضمن ذلك أنه إذا كان مفتاح API لمزود قطار (مثال: API DB أو SNCF) مفقودًا، فإن التطبيق يرفض البدء بدلاً من الفشل بصمت في بيئة الإنتاج.

// env.ts
import { createEnv } from "@t3-oss/env-nextjs";
import { z } from "zod";

export const env = createEnv({
  server: {
    DATABASE_URL: z.string().url(),
    RAIL_API_KEY: z.string().min(1),
  },
  client: {
    NEXT_PUBLIC_ANALYTICS_ID: z.string().min(1),
  },
  runtimeEnv: {
    DATABASE_URL: process.env.DATABASE_URL,
    RAIL_API_KEY: process.env.RAIL_API_KEY,
    NEXT_PUBLIC_ANALYTICS_ID: process.env.NEXT_PUBLIC_ANALYTICS_ID,
  },
});

هذه الممارسة، الموصى بها من قبل مجتمع Vercel ومشغلي Next.js، تضمن أن إعداداتنا قوية مثل كودنا.

التحقق من صحة البيانات مع Zod و Server Actions

في بنية App Router، تستبدل Server Actions غالبًا واجهات برمجة تطبيقات API التقليدية لطفرات البيانات (مثل الحجز أو حفظ تنبيه سعر). ومع ذلك، فإن الوسيطات الممررة إلى Server Action لا يتم تحديد أنواعها افتراضيًا أثناء استدعاء العميل. هنا يصبح التحقق من المخطط أمرًا بالغ الأهمية.

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

مثال على Server Action محددة النوع

// actions/search.ts
'use server';

import { z } from 'zod';
import { db } from '@/lib/db';

const SearchSchema = z.object({
  origin: z.string().length(3), // كود IATA أو UIC
  destination: z.string().length(3),
  date: z.string().regex(/^\d{4}-\d{2}-\d{2}$/),
  passengers: z.number().min(1).max(9),
});

export async function searchTrip(formData: FormData) {
  const rawData = {
    origin: formData.get('origin'),
    destination: formData.get('destination'),
    date: formData.get('date'),
    passengers: Number(formData.get('passengers')),
  };

  const result = SearchSchema.safeParse(rawData);

  if (!result.success) {
    return { error: 'بيانات غير صالحة', details: result.error.flatten() };
  }

  // معالجة أعمال آمنة
  const trips = await db.trip.findMany({
    where: {
      origin: result.data.origin,
      // ... فلاتر أخرى
    }
  });

  return { success: true, data: trips };
}

من خلال الجمع بين TypeScript strict و Zod، نحصل على تحقق ثابت (عند التجميع) وديناميكي (عند التشغيل). هذا ما نسميه "أمان الأنواع من طرف إلى طرف". وفقًا لأفضل ممارسات TypeScript 2026، هذا التحقق المزدوج ضروري للتطبيقات الحرجة.

الأداء و SEO: تحديات محرك المقارنة

يعيش محرك مقارنة السفر من خلال تحسين محركات البحث العضوي (SEO). يبحث المستخدمون عن "قطار باريس برلين" أو "Nightjet بروكسل". يتفوق Next.js 14 في هذا المجال بفضل توليد الموقع الثابت (Static Site Generation) والعرض الديناميكي الهجين.

تحسين الصور والخطوط

نستخدم مكون next/image لتحسين visuals القطارات والوجهات تلقائيًا. يسمح هذا بتقديم تنسيقات حديثة مثل WebP أو AVIF وفقًا لمتصفح المستخدم. بالإضافة إلى ذلك، فإن استخدام next/font لتحميل الخطوط (مثل Inter أو Roboto) يلغي إزاحة التخطيط (CLS)، مما يضمن عدم تحرك النص أثناء التحميل.

البث و Suspense

بالنسبة لصفحات النتائج المعقدة، نستخدم React Suspense. يسمح هذا بعرض هيكل الصفحة فورًا (رأس الصفحة، الفلاتر) بينما يتم تحميل نتائج البحث، التي قد تستغرق بضع ثوانٍ للتجميع من عدة مزودين (Ouigo, TGV Inoui, DB)، في الخلفية. يمكن للمستخدم البدء في التفاعل مع الفلاتر حتى قبل عرض القائمة الكاملة للقطارات.

تحسن هذه التقنية بشكل كبير Time to Interactive (TTI). في سياق تنافسي حيث كل ثانية مهمة للتحويل، تترجم هذه التحسينات التقنية مباشرة إلى زيادة في معدل الحجز.

التدويل (i18n) والصيانة

يستهدف محرك المقارنة الخاص بنا جمهورًا أوروبيًا. إدارة لغات متعددة (الفرنسية، الألمانية، الإنجليزية، الإسبانية) هي أصلية في بنية المسارات الخاصة بنا. يسمح Next.js ببادئة المسارات حسب اللغة (/fr/search, /de/search).

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

كما يتم تسهيل صيانة الكود من خلال نمطية App Router. كل ميزة (بحث، دفع، حساب مستخدم) معزولة في مجلد خاص بها مع اختبارات خاصة بها. نستخدم Vitest للاختبارات الوحدوية و Playwright لاختبارات end-to-end، مما يضمن أن تحديثات التبعيات (مثل الترحيل إلى React 19 المخطط له في نظام Next.js البيئي) لا تكسر الميزات الموجودة.

الخاتمة: أساس متين للمستقبل

إن اختيار Next.js 14 و TypeScript strict ليس مجرد اتجاه تقني، بل هو ضرورة تشغيلية لمحرك مقارنة سفر في عام 2026. تعقيد بيانات السكك الحديدية والجوية يتطلب دقة يفرضها التحديد الثابت للأنواع بشكل طبيعي. يوفر App Router المرونة اللازمة لتكوين واجهات غنية مع الحفاظ على أداء من الدرجة الأولى.

باتباع توصيات وثائق Next.js وتطبيق معايير صارمة لجودة الكود، قمنا ببناء منصة قادرة على التطور. سواء لدمج مزودين جدد مثل خطوط Nightjet الموسعة أو لدعم لوائح أوروبية جديدة بشأن بيانات المسافرين، فإن بنيتنا جاهزة. تخدم التقنية هنا تجربة المستخدم: موقع أسرع وأكثر موثوقية وأمانًا لإعداد رحلاتك القادمة عبر أوروبا.

للتعمق أكثر، نوصيك بالرجوع إلى الوثائق الرسمية لـ Next.js حول App Router ودليل إعداد TypeScript للحصول على تحديثات منتظمة حول أفضل الممارسات الناشئة.