"إذا أراد العامل أن يؤدي عمله بشكل جيد، فعليه أولاً أن يشحذ أدواته." - كونفوشيوس، "مختارات كونفوشيوس. لو لينجونج"
الصفحة الأمامية > برمجة > SSR في Next.js ما الجديد في توجيه التطبيقات مقارنةً بتوجيه الصفحة

SSR في Next.js ما الجديد في توجيه التطبيقات مقارنةً بتوجيه الصفحة

تم النشر بتاريخ 2024-11-09
تصفح:646

SSR in Next.js  What’s New in App Routing Compared to Page Routing

مقدمة

لطالما كان Next.js خيارًا شائعًا لبناء تطبيقات React المقدمة من الخادم. بفضل دعمه المدمج للعرض من جانب الخادم (SSR)، يمكن للمطورين إنشاء تطبيقات ديناميكية وصديقة لمحركات البحث (SEO). ومع ذلك، فقد أدى إدخال جهاز توجيه التطبيقات في Next.js 13 والتحسينات في Next.js 14 إلى تبسيط وتحسين SSR بشكل كبير.

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

SSR في توجيه الصفحة (Pre-Next.js 13)

قبل تقديم جهاز توجيه التطبيقات، تمت معالجة SSR في نظام توجيه الصفحة باستخدام وظائف محددة مثل getServerSideProps. تم استدعاء هذه الوظيفة عند كل طلب، مما يسمح للمطورين بجلب البيانات من جانب الخادم قبل عرض الصفحة.

مثال على SSR في توجيه الصفحة باستخدام getServerSideProps:

export default function Blogs({ data }) {
  // Render the fetched data
  return (
    
{data.map((item) => (

{item.title}

{item.content}

))}
); } // This function runs on every request export async function getServerSideProps() { // Fetch data from an external API const res = await fetch('https://api.example.com/blogs'); const data = await res.json(); // Pass the data as props to the page component return { props: { data } }; }

هنا، getServerSideProps هو مفتاح SSR في نظام توجيه الصفحة. فهو يسمح لك بجلب البيانات من واجهة برمجة التطبيقات (أو أي مصدر بيانات آخر) عند كل طلب، وتمريرها إلى مكون الصفحة كدعائم. هذا النمط، على الرغم من قوته، يمكن أن يؤدي إلى قواعد تعليمات برمجية معقدة عند التعامل مع الكثير من المنطق من جانب الخادم والمسارات المختلفة.

توجيه التطبيق وSSR في Next.js 14

مع Next.js 14، أصبح SSR أكثر انسيابية وتكاملًا في نظام توجيه التطبيقات. يقدم هذا النظام الجديد مكونات الخادم ومكونات العميل، حيث يكون SSR أكثر سهولة.

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

مثال على SSR في توجيه التطبيق مع مكونات الخادم:

"use server";

export async function getBlogs() {
  try {
    const response = await fetch('https://api.example.com/posts');
    return response.json();
  } catch (error) {
    return { error: error.message };
  }
}

// This component runs on the server and fetches data
export default async function Blog() {
  const blogs = await getBlogs();

  return (
    
{(blogs || []).map((blog) => (

{blog.name}

{blog.content}

))}
); }

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

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

الفوائد الرئيسية لإجراءات الخادم:

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

SSR in Next.js  What’s New in App Routing Compared to Page Routing

الترطيب في Next.js

في سياق Next.js والعرض من جانب الخادم (SSR)، يشير الترطيب إلى العملية التي يتم فيها تحويل صفحة HTML المعروضة بشكل ثابت (المرسلة من الخادم) إلى تطبيق React تفاعلي بالكامل في المتصفح. إنه "يرطب" HTML الثابت باستخدام JavaScript من جانب عميل React لجعل الصفحة تفاعلية.

الترطيب في توجيه التطبيق مقابل توجيه الصفحة

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

في توجيه التطبيق، باستخدام مكونات الخادم، يتم ترطيب مكونات العميل فقط (تلك التي تتعامل مع التفاعل). هذا الترطيب الانتقائي يقلل من كمية جافا سكريبت المرسلة إلى العميل، مما يؤدي إلى تحسين الأداء.

مثال لمكونات العميل في توجيه التطبيق:

'use client';  // Mark this as a client component

export default function Button() {
  return (
    
  );
}

هنا، يتم وضع علامة على مكون الزر باعتباره مكون عميل باستخدام "عميل الاستخدام". فهو يسمح بالتفاعل ويعمل على جانب العميل، بينما تظل المكونات الأخرى غير التفاعلية بمثابة مكونات الخادم، مما يؤدي إلى تحسين الأداء.

المزيد عن الترطيب في توجيه التطبيق

إليك كيفية العمل:

المكونات الرئيسية كمكونات الخادم:

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

مكونات العميل للتفاعل:

المكونات التابعة، التي تتعامل مع التفاعل (مثل الأزرار والنماذج وما إلى ذلك)، هي مكونات العميل. يمكن لهذه المكونات استخدام خطافات React (useState، useEffect، وما إلى ذلك) ويتم ترطيبها من جانب العميل.
تقوم مكونات الخادم بتمرير البيانات إلى مكونات العميل هذه عبر الدعائم.
بمجرد تحميل HTML في المتصفح، يقوم Next.js بترطيب مكونات العميل، وربط مستمعي الأحداث الضروريين وجعل الصفحة تفاعلية.

// Server Component (Parent Component)
export default async function ParentComponent() {
  // Fetch data on the server
  const data = await fetch('https://api.example.com/data').then(res => res.json());

  return (
    

This is Server-Side Rendered

); } // Client Component (Child Component) 'use client'; import { useState } from 'react'; function ClientComponent({ data }) { const [count, setCount] = useState(0); return (

Data from server: {JSON.stringify(data)}

Client-side counter: {count}

); }

خاتمة

Next.js 14 يجعل العرض من جانب الخادم (SSR) أسهل وأكثر قوة من خلال تقديم إجراءات الخادم في جهاز توجيه التطبيق. من خلال السماح للمطورين بجلب البيانات مباشرة داخل ملفات المكونات، يعمل هذا النظام الجديد على تبسيط المنطق من جانب الخادم، وتبسيط قواعد التعليمات البرمجية، وتقليل الحاجة إلى مسارات API منفصلة. إلى جانب الترطيب الانتقائي، أصبح SSR في Next.js 14 الآن أسرع وأكثر كفاءة، مما يساعدك على إنشاء تطبيقات ديناميكية للغاية وصديقة لكبار المسئولين الاقتصاديين بسهولة.

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

SSR in Next.js  What’s New in App Routing Compared to Page Routing

بيان الافراج تم إعادة إنتاج هذه المقالة على: https://dev.to/asim_khan_cbe65e41bcbbc65/understanding-nextjs-page-routing-vs-app-routing-and-ssr-changes-in-nextjs-14-2cge?1 إذا كان هناك أي انتهاك يرجى الاتصال بـ Study_golang @163.comdelete
أحدث البرنامج التعليمي أكثر>

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

Copyright© 2022 湘ICP备2022001581号-3