با مشارکت و همکاری جناب اقای : p.jazini
فهرست مطالب
مقدمه
نکست جی اس توسط تیم ورسل در اکتبرسال 2016 معرفی و برنامه نویسی شد.Next یک چهارچوب با ویژگی های مختلفی در جهت ساخت وب سایت های JAMstack است .
ویژگی های NextJS :
نکست جی اس توسط JavaScript، TypeScript و Rust نوشته شده است. بسیاری از شرکت ها مانند Netflix، Uber، Github و Start Box از این چارچوب استفاده می کنند.
برنامههای React تمام محتوای خود را در سمت کلاینت ارائه میکنند، NextJS برای گسترش این عملکرد برنامه های سمت سرور را ایجاد و مدریت کنیم (SSR).
در ادامه به بررسی تفاوت نسخه های 12، 13 و آخرین نسخه (NextJS 14) می پردازیم.
ویژگی های جدید در NextJS 14
NextJS 14 سه ویژگی جدید را معرفی کرد. برخی از ویژگی ها بهبود یافته و قابل اطمینان تر شدند.
در پروژهها، به چند دلیل NextJS را جایگزین میکنیم: اول، ما باید صفحات خود را سریعتر بارگذاری کنیم، بنابراین TurboPack برای کمک به ما ایجاد شد.
یک بسته نرم افزاری برای جاوا اسکریپت و تایپ اسکریپت است که توسط Rust (زبان ایمن، سطح پایین و سریع) نوشته شده است.
تیم Vercel از Turbo Pack پشتیبانی می کند. این باندلر مانند Webpack عمل میکند و 5000 تست را برای App Router و Page Router گذرانده است.
برای راهاندازی سرور محلی %53 سریعتر، برای بهروزرسانی کد و رفرش کردن صفحات %94 درصد سریعترعمل می کند.
سیستم AppRoute در نسخه 13 نیز موجود بوده است، اما ما این ویژگی را در نسخه 14 نیز داریم و با ایجاد فایل های خاص پروژه های NextJS را ساختارمند تر کرده است و شاید برای توسعه دهندگان کمی آزاردهنده باشد. در سیستم AppRoute، ما کامپوننت های سروری را مانند نسخه های قبلی Next ولی با کمی با تغییرات داریم. کامپوننت های خاص به عنوان کامپوننت های سروری ارائه میشوند، و ما هیچ چرخه hydration نداریم (ما فقط HTML آنها را داریم) بنابراین ما مجاز به تعریف useEffect، useState ... (ویژگیهایی که در سمت کلاینت اجرا میشوند) نیستیم. در صورت نیاز، باید کامپوننت ها را به کامپوننت های کلاینتی (client)تغییر دهیم.این روش جایگزین روش PageRoute نشده بلکه یک روش جدا است و در آن نیاز است که یک دایرکتوری به نام app داشته باشید و به صورت ساختاری که Next تعیین کرده فایل ها را داخل دایرکتوری app نامگذاری کنید.
این ویژگی به شما اجازه می دهد تا یک HTML ایستا تعریف کنید که بلافاصله پس از وارد شدن درخواست ارائه می شود.
در ورژن 14 Next , سرور اکشن ها به حالت پایدار رسیدند زیرا در ورژن 13 در حال تست و برسی بوده اند. آنها دلایل زیادی برای بحث و گفتگو بوده اند. این ویژگی به شما اجازه می دهد تا توابع سمت سرور را برای کامپوننت های سروری خود بنویسید و نیازی به استفاده از سرویس هایی که از درخواست های HTTP پشتیبانی می کنند مانند Axios و سایر مسیرهای API منفرد نیست. به عنوان مثال، ما می توانیم از server action در ارسال فرم یا سایر داده هایی که قابلیت جابجایی دارند استفاده کنیم. می توانید server action را تعریف کرده و آن را داخل action Attribute در یک تگ فرم فراخوانی کنید. به واسطه server action ها ، چند متد جدید معرفی شدند:
revalidatePath())
or revalidateTag() //importing from next/cache
redirect() //importing from next/navigation
cookies() //importing from next/headers
useOptimistic()
useFormState()
useFormStatus()
async function createForm(formData:FormData){
‘use server’
//you can get data and post it somewhere else
revalidatePath(‘/’)
}
چرا از Server action ها استفاده می کنیم؟
سرور اکشن به ما در مدیریت خطا، اعتبارسنجی مجدد داده ها و نمایش وضعیت انتظار کمک می کند.
اکشن سرور روشی برای اجرای کد ما روی سروراستفاده می شود و می توانید تنها با تعریف یک تابع Asynchronous با دستور "use server" در بالای بدنه تابع ، یک server action ایجاد کنید. ""use server" تضمین می کند که این عملکرد فقط روی سرور اجرا می شود وبه طور خودکار درخواستهای Post را روی سرور برای شما ایجاد میکند. استفاده از این روش نسبت به API Routes سادهتر است و اگر اطلاعات حساس یا هر چیزی که نمیخواهیم کلاینت از آن مطلع شود، میتوانیم از این ویژگی مفید استفاده کنیم.
Server Actions را می توان به دو صورت تعریف کرد :
//روش اول
export default function ServerComponent() { async function myAction() {
'use server'
// ...
}
}
//روش دوم 'use server'
export default function ServerComponent() {
async function myAction() {
// ...
}
}
در Next.js نسخه 12، تمامی کامپوننتها به عنوان کامپوننتهای کلاینت در نظر گرفته میشوند.
در Next.js نسخه 13، یک تغییر جدید و قابل توجه به کامپوننتها اضافه شده است که با نام Server Component شناخته میشود.
عملکرد سرور کامپوننت ها میتواند به صورت زیر شرح داده شود:
۱. دادهها واکشی شده و کد جاوااسکریپت بر روی سرور اجرا میشود.
۲. دادهها به فرمت دادههایی مانند JSON سریالسازی میشوند.
۳. دادههای سریالسازی شده به صورت قطعه قطعه به کلاینت ارسال و استریم میشوند تا به HTML تبدیل شده و سپس در ReactDOM گنجانده شوند.
مهم است بهیاد داشت که کامپوننتهای سرور پشتیبانی از وضعیت (state)، هوکها (hooks) یا event را ندارند، زیرا کل فرآیند رندرینگ در سمت سرور انجام میشود.
سوالی که مطرح میشود این است: چه زمانی نیاز به سرور کامپوننت ها خواهیم داشت؟
برای واکشی دادهها در زمانی که نیازی به تعامل با کاربر نیست.
در تاریخ ۲۶ اکتبر ۲۰۲۱، Next.js نسخه ۱۲ منتشر شد و قابلیتهایی از جمله کامپایلر Rust، کامپایل سریعتر، پشتیبانی از AVIF، Edge Functions & Middleware و Native ESM & URL Imports را به این فریمورک اضافه کرد.
کامپوننتهای کلاینت برای فایلهای ساخته شده در pages directory مورد استفاده قرار میگیرند.
این کامپوننتها از رندرینگ سمت سرور (SSR) با استفاده از تابع getServerSideProps استفاده میکنند.
در Next.js 12، واکشی داده میتواند با استفاده از توابع رندرینگ سمت سرور (SSR) مانند getServerSideProps انجام شود.
سرور کامپوننت ها به صورت انحصاری در دایرکتوری برنامه استفاده میشوند و با کلاینت تعامل ندارند.
در نسخه ۱۳ Next، دایرکتوری برنامه پایدار نبود، بنابراین توسعهدهندگان باید با page directory در پروژههای شرکتی برنامه نویسی کنند.
برای تبدیل یک فایل به یک کامپوننت کلاینت، کافیست در ابتدای فایل "use client" را اضافه کنید.
به جای وابستگی به getServerSideProps و setStaticProps، از سرور کامپوننت ها برای واکشی داده استفاده کنید.
همچنین، بهبودهایی در next/image و next/link وجود دارد.
این کار از طریق استفاده از سرور کامپوننت ها به طور قابل توجهی سادهتر شده است.
با استفاده از سرور کامپوننت ها، اکنون میتوانیم توابع async-await معمولی مانند getData را مستقیماً در کامپوننت داشبورد خود ایجاد و استفاده کنیم، که نیازی به هیچ پراپ خاصی ندارد.
مهم است که توجه کنیم که سرور کامپوننت ها تنها در داخل سرور با یکدیگر تعامل دارند. بنابراین، نمیتوانیم از توابعی مانند headers() استفاده کرده و آنها را به فراخوانی fetch ارسال کنیم زیرا این توابع مربوط به کلاینت هستند.
به جای این کار، یک توکن مخفی به عنوان یک کلید API ارسال میکنیم تا درخواست را تأیید کند. این کلید مخفی به عنوان یک environment variable به طور امن ذخیره میشود.