نوشته های مصطفی رستگار

06- Mocking در تست‌ها (ماژول‌ها، API calls، توابع تاریخ/زمان)Mocking در تست‌ها (ماژول‌ها، API calls، توابع تاریخ/زمان)

مصطفی رستگار — Sat, 15 Aug 2026 13:28:21 +0330

پاسخ به سوال Mocking در تست‌هاسلام. بگذارید این موضوع را با یک مثال ساده و قابل لمس توضیح بدهم. فرض کنید می‌خواهیم کیفیت یک خودرو را تست کنیم. برای تست موتور، نیازی نداریم کل خودرو را در جاده ببریم. می‌توانیم موتور را روی یک پایه قرار دهیم و آن را به صورت جداگانه تست کنیم. در دنیای نرم‌افزار، به این کار می‌گوییم Mocking.تعریف ساده و مفهومیMocking یعنی جایگزین کردن یک بخش واقعی از کد با یک نسخه ساختگی و کنترل شده در زمان تست. این کار را انجام می‌دهیم تا تست‌هایمان:وابسته به منابع خارجی نباشند (مثل اینترنت، دیتابیس، یا ساعت سیستم)سریع اجرا شوندقابل پیش‌بینی و تکرارپذیر باشندفقط منطق خودمان را تست کنند، نه منطق کتابخانه‌های دیگر راسناریوی اول: Mocking ماژول‌هافرض کنید یک تابع داریم که از یک ماژول دیگر برای ارسال ایمیل استفاده می‌کند:javascript// services/emailService.js import { sendEmail } from './emailProvider'; export function notifyUser(email) { const result = sendEmail(email, 'خوش آمدید'); return result.success; }در زمان تست، ما نمی‌خواهیم واقعا ایمیل بفرستیم. پس ماژول emailProvider را به صورت ساختگی در می‌آوریم:javascript// tests/emailService.test.js import { notifyUser } from './emailService'; import * as emailProvider from './emailProvider'; // این کار باعث می‌شود که تابع sendEmail یک نسخه ساختگی بگیرد jest.mock('./emailProvider'); test('وقتی ایمیل با موفقیت ارسال شود، true برمی‌گرداند', () => { // نسخه ساختگی را طوری تنظیم می‌کنیم که همیشه موفق باشد emailProvider.sendEmail.mockReturnValue({ success: true }); const result = notifyUser('test@example.com'); expect(result).toBe(true); }); test('وقتی ایمیل با خطا مواجه شود، false برمی‌گرداند', () => { emailProvider.sendEmail.mockReturnValue({ success: false }); const result = notifyUser('test@example.com'); expect(result).toBe(false); });نکته کلیدی این است که ما واقعا کاری به نحوه کار sendEmail نداریم. فقط می‌خواهیم بدانیم که تابع خودمان در شرایط مختلف چه رفتاری از خود نشان می‌دهد.سناریوی دوم: Mocking درخواست‌های شبکه (API Calls)این مورد در برنامه‌های React و Next.js بسیار رایج است. فرض کنید یک کامپوننت داریم که اطلاعات کاربر را از سرور می‌گیرد:javascript// components/UserProfile.jsx import { useEffect, useState } from 'react'; import axios from 'axios'; export function UserProfile({ userId }) { const [user, setUser] = useState(null); const [loading, setLoading] = useState(true); useEffect(() => { axios.get(`/api/users/${userId}`) .then(response => { setUser(response.data); setLoading(false); }); }, [userId]); if (loading) return

در حال بارگذاری...

; return

{user?.name}

; }برای تست این کامپوننت، هرگز نباید به سرور واقعی متصل شویم. به جای آن، axios را با یک نسخه ساختگی جایگزین می‌کنیم:javascript// tests/UserProfile.test.jsx import { render, screen } from '@testing-library/react'; import axios from 'axios'; import { UserProfile } from './UserProfile'; // کل کتابخانه axios را با نسخه ساختگی جایگزین می‌کنیم jest.mock('axios'); test('پس از دریافت اطلاعات، نام کاربر را نشان می‌دهد', async () => { // تنظیم پاسخ ساختگی برای درخواست GET const mockUser = { id: 1, name: 'علی رضایی' }; axios.get.mockResolvedValue({ data: mockUser }); render(); // ابتدا باید متن بارگذاری را ببینیم expect(screen.getByText('در حال بارگذاری...')).toBeInTheDocument(); // سپس منتظر می‌مانیم تا نام کاربر ظاهر شود const userName = await screen.findByText('علی رضایی'); expect(userName).toBeInTheDocument(); // اطمینان از اینکه درخواست با آدرس درست زده شده expect(axios.get).toHaveBeenCalledWith('/api/users/1'); });سناریوی سوم: Mocking توابع تاریخ و زماناین مورد یکی از چالش‌برانگیزترین موارد است چون تاریخ و زمان همیشه در حال تغییر هستند. فرض کنید یک تابع داریم که تخفیف ویژه را بر اساس روز هفته محاسبه می‌کند:javascript// utils/discount.js export function getSpecialDiscount() { const today = new Date(); const day = today.getDay(); // 0 = یکشنبه, 6 = شنبه if (day === 5) { // جمعه return 0.3; // تخفیف ۳۰ درصدی } return 0.1; // تخفیف معمولی ۱۰ درصدی }برای تست این تابع، باید بتوانیم تاریخ را کنترل کنیم. در جاوااسکریپت، این کار را با جایگزین کردن Date اصلی انجام می‌دهیم:javascript// tests/discount.test.js import { getSpecialDiscount } from './discount'; // قبل از همه تست‌ها، یک تاریخ ثابت تنظیم می‌کنیم beforeAll(() => { // تاریخ را روی یک جمعه خاص تنظیم می‌کنیم jest.useFakeTimers(); jest.setSystemTime(new Date('2026-08-15')); // این تاریخ یک شنبه است }); afterAll(() => { // بعد از تست‌ها، حالت عادی را برمی‌گردانیم jest.useRealTimers(); }); test('در روزهای جمعه تخفیف ویژه اعمال می‌شود', () => { // برای این تست، تاریخ را روی جمعه تنظیم می‌کنیم jest.setSystemTime(new Date('2026-08-14')); // این تاریخ جمعه است const discount = getSpecialDiscount(); expect(discount).toBe(0.3); }); test('در روزهای غیر جمعه تخفیف معمولی است', () => { jest.setSystemTime(new Date('2026-08-15')); // شنبه const discount = getSpecialDiscount(); expect(discount).toBe(0.1); });نکات کلیدی و تفاوت سطح Seniorیک توسعه‌دهنده ارشد در بحث Mocking به این موارد توجه می‌کند:اول: همیشه از تست‌های واقعی در کنار تست‌های ساختگی استفاده می‌کند. مثلا یک تست مجزا برای اتصال واقعی به API دارد که هر شب اجرا می‌شود.دوم: زیاد Mock نمی‌کند. اگر چیزی خیلی ساده است، نیازی به ساختگی کردن ندارد.سوم: کد را طوری می‌نویسد که Mock کردن آسان باشد. مثلا وابستگی‌ها را به جای اینکه داخل تابع بسازد، به عنوان پارامتر یا از طریق تزریق وابستگی دریافت می‌کند.چهارم: در Next.js با App Router، برای تست کردن Server Components از mock کردن ماژول‌های سروری استفاده می‌کند و برای Client Components از mock کردن fetch یا axios.پنجم: همیشه بعد از هر تست، mockها را پاک می‌کند تا تست بعدی تحت تاثیر قرار نگیرد (jest.clearAllMocks()).در پاسخ به مصاحبه‌کننده، این را هم اضافه کنید که هدف از Mocking، تست کردن منطق کسب و کار است، نه تست کردن کتابخانه‌های شخص ثالث یا سرویس‌های خارجی. اگر مجبور هستید خیلی از چیزها را Mock کنید، احتمالا طراحی کد شما مشکل دارد و باید وابستگی‌ها را کاهش دهید.

05- Testing (Unit با Jest/Vitest، Integration با RTL، E2E با Playwright)

مصطفی رستگار — Sat, 15 Aug 2026 13:11:12 +0330

پاسخ به سوال تست‌نویسی (Unit, Integration, E2E)برای شروع، اجازه دهید یک دید کلی به شما بدهم. در پروژه‌های React و Next.js، ما تست‌نویسی را به سه لایه اصلی تقسیم می‌کنیم. هر لایه هدف مشخصی دارد و جایگزین لایه دیگر نمی‌شود. به این سه لایه مثل یک هرم نگاه کنید که پهنای آن در پایین بیشتر است.لایه اول: تست واحد (Unit Test) با Jest یا Vitestتست واحد، کوچکترین بخش تست‌نویسی است. در اینجا ما یک تابع، یک هوک سفارشی، یا یک کامپوننت کوچک را به صورت کاملا ایزوله تست می‌کنیم. یعنی هیچ وابستگی به شبکه، دیتابیس، یا کامپوننت‌های دیگر نداریم.من در پروژه‌های جدید از Vitest استفاده می‌کنم چون سرعت بیشتری دارد و با Vite هماهنگ است. اما مفهوم هر دو یکی است.مثال عملی: فرض کنید یک تابع داریم که قیمت را با تخفیف محاسبه می‌کند. من برای این تابع سه سناریو می‌نویسم: حالت عادی، حالت با تخفیف صفر، و حالت با اعداد منفی که باید خطا بدهد.javascript// مثال ساده از تست واحد test('should calculate discount price correctly', () => { expect(calculateDiscount(100, 10)).toBe(90); expect(calculateDiscount(100, 0)).toBe(100); expect(() => calculateDiscount(-10, 10)).toThrow(); });نکته مهم این است که در تست واحد، من هیچ وقت رندر واقعی انجام نمی‌دهم. فقط منطق خالص را تست می‌کنم. این تست‌ها باید خیلی سریع اجرا شوند، معمولا کمتر از چند میلی ثانیه برای هر تست.لایه دوم: تست یکپارچه‌سازی (Integration Test) با React Testing Libraryاینجا جایی است که من به عنوان یک توسعه‌دهنده ارشد، بیشترین زمان را صرف می‌کنم. تست یکپارچه‌سازی به معنای تست کردن تعامل چند بخش با هم است. مثلا یک کامپوننت فرم که با یک هوک سفارشی و یک سرویس API کار می‌کند.با React Testing Library، ما از دید کاربر تست می‌کنیم. یعنی دنبال متن‌ها، دکمه‌ها، و المان‌های قابل مشاهده می‌گردیم و کلیک کردن و تایپ کردن را شبیه‌سازی می‌کنیم.مثال عملی: یک فرم ورود کاربر را در نظر بگیرید. من در تست این فرم، سناریوی موفقیت و خطا را هر دو تست می‌کنم.javascript// مثال از تست یکپارچه‌سازی test('should show error message when login fails', async () => { // شبیه‌سازی درخواست ناموفق server.use( rest.post('/api/login', (req, res, ctx) => { return res(ctx.status(401), ctx.json({ message: 'Invalid credentials' })); }) ); render(); // کاربر ایمیل و پسورد را تایپ می‌کند await userEvent.type(screen.getByLabelText(/email/i), 'test@example.com'); await userEvent.type(screen.getByLabelText(/password/i), 'wrongpass'); // روی دکمه ورود کلیک می‌کند await userEvent.click(screen.getByRole('button', { name: /login/i })); // پیام خطا را می‌بیند expect(await screen.findByText(/invalid credentials/i)).toBeInTheDocument(); });نکته کلیدی اینجا این است که ما هیچ وقت کامپوننت را به صورت مجزا تست نمی‌کنیم. بلکه کل رفتار کاربر را شبیه‌سازی می‌کنیم. این تست‌ها کمی کندتر از تست واحد هستند اما بسیار ارزشمندترند چون اعتماد ما را به عملکرد صحیح برنامه بالا می‌برند.لایه سوم: تست سرتاسری (E2E) با Playwrightتست E2E مانند یک ربات است که مرورگر واقعی را باز می‌کند و دقیقا مثل یک کاربر واقعی با برنامه تعامل می‌کند. این تست‌ها در محیطی مشابه محیط تولید اجرا می‌شوند.با Playwright، من می‌توانم همزمان در کروم، فایرفاکس و وب‌کیت تست کنم. این تست‌ها گران‌ترین و کندترین تست‌ها هستند، بنابراین تعداد آنها را محدود نگه می‌دارم.معمولا سناریوهای اصلی کسب‌وکار را با E2E پوشش می‌دهم. مثلا:ثبت‌نام کاربر جدیدورود به سیستمخرید یک محصولخروج از سیستمjavascript// مثال از تست E2E با Playwright test('user can complete purchase flow', async ({ page }) => { // باز کردن صفحه اصلی await page.goto('/'); // انتخاب محصول await page.click('text=Product X'); await page.click('button:has-text("Add to Cart")'); // رفتن به سبد خرید await page.click('a:has-text("Cart")'); await page.click('button:has-text("Checkout")'); // پر کردن فرم await page.fill('input[name="email"]', 'test@example.com'); await page.fill('input[name="address"]', '123 Main St'); await page.click('button:has-text("Confirm Purchase")'); // تایید موفقیت await expect(page.locator('text=Order Confirmed')).toBeVisible(); });نسبت و تعادل بین این سه لایهمن به عنوان یک توسعه‌دهنده ارشد، از قانون هرم تست پیروی می‌کنم. نسبت تست‌ها به این شکل است:تست واحد: حدود 70 درصد تست‌هاتست یکپارچه‌سازی: حدود 20 درصد تست‌هاتست E2E: حدود 10 درصد تست‌هاچرا؟ چون تست‌های واحد سریع و ارزان هستند و هر تغییری را سریع نشان می‌دهند. تست‌های یکپارچه‌سازی ارزش بالایی دارند اما کندترند. و تست‌های E2E گران‌ترین هستند و فقط برای مسیرهای اصلی استفاده می‌شوند.نکات پیشرفته برای مصاحبهاگر می‌خواهید در مصاحبه بدرخشید، این نکات را به خاطر داشته باشید:۱. من همیشه تست‌ها را همزمان با توسعه می‌نویسم، نه بعد از آن. این کار باعث می‌شود کد من از ابتدا تست‌پذیر طراحی شود.۲. برای کامپوننت‌هایی که به Next.js متکی هستند (مثل useRouter یا usePathname)، من از Mock کردن استفاده می‌کنم. در Next.js 13 و بالاتر، از NextRouter مخصوص تست استفاده می‌کنم.۳. من هرگز از snapshot testing به عنوان تست اصلی استفاده نمی‌کنم. اسنپ‌شات‌ها فقط برای بررسی تغییرات ناخواسته در UI مفیدند، نه برای تایید منطق.۴. در پروژه‌های بزرگ، من تست‌ها را بر اساس پوشش کد (code coverage) ارزیابی نمی‌کنم. به جای آن، کیفیت سناریوهای تست شده را بررسی می‌کنم. ۱۰۰ درصد پوشش کد به معنای ۱۰۰ درصد کیفیت نیست.۵. من از فیکسچرها (fixtures) و فکتوری‌ها برای ساخت داده‌های تست استفاده می‌کنم تا تست‌ها خواناتر و قابل نگهداری‌تر باشند.یک سناریوی واقعی برای مصاحبهفرض کنید یک کامپوننت لیست کاربران داریم که داده‌ها را از API می‌گیرد و با Zustand مدیریت state می‌کند. من برای این کامپوننت، سه نوع تست می‌نویسم:۱. تست واحد برای خود تابع fetchUsers۲. تست یکپارچه‌سازی برای کامپوننت UserList که نشان می‌دهد در حالت loading، حالت error، و حالت موفقیت چه رفتاری دارد۳. تست E2E برای کل فرآیند لاگین و مشاهده لیست کاربران

04- Lighthouse و Web Vitals (اندازه‌گیری در Production)

مصطفی رستگار — Tue, 11 Aug 2026 16:16:09 +0330

سناریو: مدیر محصول به شما می گوید "کاربران می گویند سایت کند است، اما من که تست می کنم سریع است!" شما چطور این مسئله را با استفاده از Lighthouse و Web Vitals در محیط Production ریشه یابی می کنید؟پاسخ جامع و روان برای مصاحبه:برای پاسخ به این سوال، باید قضیه را از دو زاویه متفاوت نگاه کنیم: یکی ابزارهای اندازه گیری در محیط آزمایشگاهی (Lab) و دیگری اندازه گیری در محیط واقعی (Field). تفاوت این دو، کلید تشخیص مشکل است.۱. تفاوت اساسی را توضیح می دهم (سناریو محور):اول از همه به مدیر محصول توضیح می دهم که تست من روی دستگاه خودم با اینترنت پرسرعت و پردازنده قوی، یک تست Lab محسوب می شود. اما کاربران من با گوشی های میان رده و شبکه اینترنت ضعیف در حال استفاده هستند. اینجاست که Web Vitals در محیط Production وارد بازی می شود.۲. ابزار دقیق (Instrumentation) در Production:به جای اینکه فقط یک بار سایت را با Lighthouse در مرورگر خودم تست کنم، باید یک سیستم پایش (Monitoring) راه بیندازم. کار من به عنوان مهندس ارشد این است که کدهای اندازه گیری را به صورت مستقیم در برنامه Next.js تزریق کنم.من از کتابخانه رسمی web-vitals استفاده می کنم.این کتابخانه را در فایل _app.tsx یا layout.tsx قرار می دهم تا تمامی مسیرها را پوشش دهد.سپس این داده ها را به یک سرویس تحلیلی مانند Google Analytics 4، New Relic یا DataDog می فرستم. هدف من این است که ببینم ۷۵ درصد کاربران من (Percentile 75) چه تجربه ای دارند، نه اینکه فقط یک کاربر خاص چه تجربه ای دارد.۳. سه متریک طلایی (Core Web Vitals) را رصد می کنم:من دقیقا به سه عدد کلیدی که گوگل تعیین کرده است نگاه می کنم و برای هر کدام یک سناریو تعریف می کنم:LCP (Largest Contentful Paint) یا بزرگترین محتوای قابل مشاهده: اگر این عدد بالای ۲.۵ ثانیه باشد، یعنی تصویر اصلی یا هدر سایت دیر بارگذاری می شود. در Next.js این مشکل را با استفاده از کامپوننت next/image با ویژگی priority برای مهم ترین تصاویر حل می کنم.FID (First Input Delay) یا تاخیر در اولین ورودی: این متریک نشان می دهد که وقتی کاربر برای اولین بار روی دکمه ای کلیک می کند، چقدر طول می کشد تا مرورگر پاسخ دهد. اگر این عدد بالا باشد، نشان می دهد که ترد اصلی (Main Thread) مرورگر قفل شده است. در Next.js این یعنی من باید کدهای سنگین را با استفاده از useEffect یا کتابخانه هایی مانند next/dynamic برای بارگذاری غیرهمزمان (Lazy Loading) به تعویق بیندازم تا پردازنده آزاد شود.CLS (Cumulative Layout Shift) یا جابه جایی ناگهانی اجزای صفحه: این بدترین تجربه کاربری است. یعنی کاربر در حال خواندن مطلب است که ناگهان یک بنر پایین می پرد و صفحه پایین می رود. من در Production این را رصد می کنم تا ببینم آیا ابعاد تصاویر و ویدیوها را به درستی مشخص کرده ام یا اینکه تبلیغات متفرقه باعث این لرزش می شوند.۴. از قدرت Next.js در Production استفاده می کنم:به عنوان کسی که با Next.js کار می کند، من فقط منتظر داده های کاربران نمی مانم. من از قابلیت های خود فریم ورک برای بهبود این اعداد استفاده می کنم:مقایسه استاتیک و داینامیک: اگر صفحه ای کاملا استاتیک است، حتما آن را ssg به صورت کامل در زمان Build تولید می کنم تا زمان LCP به حداقل برسد.استفاده از Incremental Static Regeneration (ISR): برای صفحاتی که داده هایشان هر چند دقیقه یک بار تغییر می کند، از ISR استفاده می کنم تا همیشه یک فایل HTML آماده برای اولین بازدید وجود داشته باشد و نیازی به اجرای کد سمت سرور نباشد.۵. جمع بندی نهایی برای مصاحبه:در نهایت به کارفرما یا تیم می گویم که Lighthouse (تست آزمایشگاهی) برای من یک چراغ راهنما است که به من می گوید "ممکن است" مشکل داشته باشم. اما Web Vitals در Production (با استفاده از داده های واقعی RUM - Real User Monitoring) به من می گوید که "واقعا" کدام کاربران و در کدام منطقه جغرافیایی دچار مشکل هستند. من با اتکا به این داده ها، تصمیم می گیرم که مثلا از CDN بهتری استفاده کنم، یا اسکریپت های تحلیلی شخص ثالث را به روش defer یا lazyOnload در Next.js بارگذاری کنم تا تداخلی با رندر اصلی سایت نداشته باشند.این روش نشان می دهد که من فقط یک کدنویس نیستم، بلکه به UX و عملکرد محصول در دنیای واقعی فکر می کنم.

03- Performance Metrics (LCP, FID, CLS, TTI, TBT)

مصطفی رستگار — Tue, 11 Aug 2026 16:06:40 +0330

عملکرد وب و معیارهای کلیدی (Core Web Vitals)اجازه بدهید این مفاهیم را با یک تشبیه ساده شروع کنم. فرض کنید کاربر وارد یک رستوران (وبسایت) می‌شود:LCP (Largest Contentful Paint) - بزرگترین محتوای قابل مشاهدهاین معیار زمان بارگذاری بزرگترین المان قابل مشاهده در صفحه را اندازه می‌گیرد. مثل این می‌ماند که مشتری تا کی باید منتظر بماند تا غذای اصلی اش روی میز بیاید. در یک وبسایت، این المان معمولا تصویر اصلی (Hero Image) یا عنوان بزرگ است. استاندارد خوب یعنی زیر ۲.۵ ثانیه. اگر بالاتر باشد، کاربر حس می‌کند سایت کند است.FID (First Input Delay) - تاخیر اولین ورودیاین معیار فاصله زمانی بین اولین تعامل کاربر (مثلا کلیک روی دکمه) تا زمانی که مرورگر بتواند به آن واکنش نشان دهد را اندازه می‌گیرد. مثل این است که مشتری به پیشخدمت علامت می‌دهد اما پیشخدمت چند ثانیه طول می‌کشد تا متوجه شود و پاسخ دهد. استاندارد خوب زیر ۱۰۰ میلی ثانیه است. این معیار نشان می‌دهد که مرورگر چقدر مشغول پردازش کارهای سنگین است.CLS (Cumulative Layout Shift) - تغییرات ناگهانی چیدماناین معیار میزان جابجایی غیرمنتظره المان‌های صفحه را اندازه می‌گیرد. فرض کنید مشتری می‌خواهد دکمه سفارش را بزند اما ناگهان یک بنر تبلیغاتی پایین می‌آید و دکمه جابجا می‌شود و مشتری روی چیز دیگری کلیک می‌کند. استاندارد خوب زیر ۰.۱ است.TTI (Time to Interactive) - زمان تا تعامل‌پذیریاین معیار نشان می‌دهد صفحه از چه زمانی کاملا آماده تعامل با کاربر است. یعنی هم محتوا نشان داده شده و هم event listener ها متصل شده‌اند و کاربر می‌تواند با همه المان‌ها کار کند. استاندارد خوب زیر ۵ ثانیه است.TBT (Total Blocking Time) - زمان کل مسدودیتاین معیار مجموع زمانی است که صفحه به دلیل پردازش‌های سنگین جاوااسکریپت، قادر به پاسخ‌گویی به ورودی‌های کاربر نیست. هر بخش از پردازش که بیش از ۵۰ میلی ثانیه طول بکشد، به عنوان زمان مسدودیت محسوب می‌شود. استاندارد خوب زیر ۳۰۰ میلی ثانیه است.سناریوی مصاحبه: چطور این معیارها را در Next.js بهبود می‌دهیم؟فرض کنید مدیر محصول به شما می‌گوید که LCP سایت ما ۴ ثانیه است و CLS هم ۰.۲۵ است. راه‌حل شما چیست؟برای بهبود LCP:۱. از Image کامپوننت Next.js با priority استفاده کنید تا تصاویر اصلی زودتر بارگذاری شوند۲. از SSR یا ISR به جای CSR برای صفحات اصلی استفاده کنید۳. فایل‌های جاوااسکریپت را با dynamic import به بخش‌های کوچک تقسیم کنید۴. از CDN برای بارگذاری assets استفاده کنیدبرای بهبود FID و TBT:۱. کدهای سنگین را با استفاده از Web Workers به ترد جداگانه ببرید۲. از useDeferredValue و useTransition در React برای اولویت‌بندی رندرها استفاده کنید۳. اجرای کدهای غیرضروری را به بعد از بارگذاری صفحه موکول کنید (با useEffect و setTimeout)برای بهبود CLS:۱. برای همه تصاویر و ویدیوها، width و height مشخص کنید۲. از placeholder های skeleton استفاده کنید تا فضای المان‌ها قبل از بارگذاری مشخص باشد۳. از font-display: optional برای فونت‌ها استفاده کنید تا متن با فونت سیستمی نشان داده شود و بعدا جایگزین شودمثال عملی در Next.js:jsx// بهبود LCP با اولویت تصویر import Image from 'next/image'

// بهبود TTI با dynamic import const HeavyComponent = dynamic(() => import('./HeavyComponent'), { loading: () => , ssr: false // اگر نیازی به SSR نداشته باشد }) // بهبود FID با useTransition const [isPending, startTransition] = useTransition() const handleSearch = (value) => { startTransition(() => { setSearchResults(filterData(value)) // این عملیات سنگین را به اولویت پایین‌تر می‌دهد }) }نکته مهم این است که این معیارها به هم وابسته هستند. مثلا اگر TBT بالا باشد، FID هم بد می‌شود چون مرورگر مشغول است. یا اگر تصاویر با اندازه مشخص نباشند، CLS بالا می‌رود.در نهایت برای اندازه‌گیری این معیارها از ابزارهای زیر استفاده می‌کنیم:Lighthouse در DevToolsCore Web Vitals گزارش شده در Google Search Consoleکتابخانه web-vitals در Next.js که می‌تواند داده‌های واقعی کاربران را جمع‌آوری کند

02- Code Splitting استراتژیها (Route-based, Component-based)

مصطفی رستگار — Tue, 11 Aug 2026 15:21:16 +0330

پاسخ پیشنهادی (برای بیان در مصاحبه):۱. تعریف کلی (جلب توجه مصاحبهگر):«Code Splitting یعنی به جای اینکه کل برنامه را یک جا به کاربر بفرستیم، آن را به چند تکه کوچکتر تقسیم میکنیم و فقط همان چیزی را میفرستیم که کاربر در همان لحظه به آن نیاز دارد. این کار باعث میشود صفحه اول خیلی سریعتر بارگذاری شود.»۲. استراتژی اول: Route-based Splitting (مهمترین و رایجترین)«در این روش، براساس آدرسهای برنامه (صفحات) کد را تقسیم میکنیم. مثلاً وقتی کاربر وارد صفحه «داشبورد» میشود، کد مربوط به صفحه «تنظیمات» را اصلاً دریافت نمیکند. در Next.js این کار به صورت پیشفرض با استفاده از ساختار pages یا app انجام میشود. یعنی هر صفحه، یک chunk مجزا دارد.»مثال عملی در Next.js:javascript// در Next.js، خودِ سیستم این کار را میکند // اما اگر بخواهیم دستی در React پیاده کنیم: const Dashboard = React.lazy(() => import('./pages/Dashboard')); const Settings = React.lazy(() => import('./pages/Settings')); // حالا وقتی کاربر به /dashboard میرود، فقط Dashboard بارگذاری میشود۳. استراتژی دوم: Component-based Splitting (جزئی تر و هوشمندانه تر)«اینجا دیگر براساس صفحه نیست، بلکه براساس کامپوننت های سنگین یا کم استفاده تقسیم میکنیم. مثلاً یک مودال بزرگ، یک چارت سنگین یا یک ویرایشگر متن که شاید اصلاً همه کاربران از آن استفاده نکنند. این کامپوننت را فقط وقتی بارگذاری میکنیم که کاربر واقعاً به آن نیاز داشته باشد (مثلاً با کلیک دکمه).»مثال عملی:javascript// بارگذاری یک کامپوننت سنگین فقط هنگام کلیک const HeavyChart = React.lazy(() => import('./HeavyChart')); function Dashboard() { const [showChart, setShowChart] = useState(false); return (

{showChart && ( در حال بارگذاری...

}> )} ); }۴. تفاوت کلیدی این دو استراتژی (نکته طلایی برای تمایز):Route-basedComponent-basedدر سطح صفحه در سطح کامپوننت هنگام تغییر آدرس هنگام رویداد (مثل کلیک)بیشتر برای LCP مفید است بیشتر برای تعاملات ثانویه مفید است در Next.js پیشفرض است باید با dynamic import پیاده سازی کنیم۵. نکته پیشرفته تر (برای نشان دادن دانش عمیق):«در Next.js میتوانیم با استفاده از next/dynamic کنترل بیشتری داشته باشیم. مثلاً میتوانیم مشخص کنیم که یک کامپوننت فقط در سمت کلاینت بارگذاری شود (برای کتابخانههایی که با SSR مشکل دارند) یا اینکه در حین بارگذاری، یک حالت Loading نمایش دهیم.»javascriptimport dynamic from 'next/dynamic'; const DynamicChart = dynamic( () => import('../components/HeavyChart'), { ssr: false, // فقط کلاینت loading: () =>

در حال بارگذاری نمودار...

} );۶. جمع بندی نهایی (با نگاه مهندسی):«انتخاب استراتژی به این بستگی دارد که بزرگترین مشکل عملکردی ما چیست. اگر صفحه اول کند است → Route-based. اگر تعاملات داخلی کند است → Component-based. در پروژه های بزرگ معمولاً از ترکیب هر دو استفاده میکنیم. همچنین با ابزارهایی مثل @next/bundle-analyzer مدام سایز باندل را چک میکنیم تا مطمئن شویم که تقسیمبندی درست کار کرده است.»نکات اضافه برای مصاحبه (اگر سوال عمقی پرسیدند):ابزارهای مکمل: Webpack (با SplitChunksPlugin)، @next/bundle-analyzerچالشها: مدیریت حالت Loading با Suspense، جلوگیری از Flicker (پرش صفحه)معیار موفقیت: کاهش First Load JS در گزارش Lighthouse

01- State Management Strategy (کدام ابزار برای چه سناریویی؟)

مصطفی رستگار — Tue, 11 Aug 2026 12:59:12 +0330

State Management Strategy (کدام ابزار برای چه سناریویی؟)اینجا یک پاسخ کاملاً روان، ساختاریافته و قابل‌ارائه در مصاحبه فنی برای سطح Senior آماده شده است. این پاسخ را طوری طراحی کرده‌ام که هم تسلط فنی شما را نشان دهد، هم تجربه‌ی عملی و هم قدرت تصمیم‌گیری معماری شما.پاسخ پیشنهادی برای مصاحبه (سناریو محور):«برای انتخاب ابزار مدیریت state، من هیچ‌وقت یک گزینه را به‌عنوان «برنده‌ی مطلق» در نظر نمی‌گیرم. استراتژی من بر اساس سه محور تصمیم‌گیری است: Scope (حوزه‌ی استفاده)، Frequency (تناوب تغییرات) و Complexity (پیچیدگی روابط داده‌ها).بیایید سناریوها را از ساده به پیچیده مرور کنم:۱. State محلی (Local State) – نیازی به ابزار نیستاگر data فقط در یک کامپوننت یا فرزندان مستقیم آن استفاده می‌شود (مثل وضعیت باز/بستن مودال یا مقدار یک فرم ساده)، من از useState یا useReducer خود React استفاده می‌کنم.نکته‌ی Senior: حتی برای فرم‌های پیچیده‌تر، اگر نیاز به اعتبارسنجی همزمان داشته باشم، از useReducer به‌همراه useContext محدود به همان زیردرخت استفاده می‌کنم تا از رندر مجدد کل اپلیکیشن جلوگیری کنم.۲. State اشتراکی بین چند کامپوننت (Shared / Global State) – دو ابزار اصلیاینجا بسته به سناریو، بین Redux Toolkit و Zustand یکی را انتخاب می‌کنم:اگر اپلیکیشن بزرگ است، تیم بزرگ است، و نیاز به رویدادنگاری (Logging)، زمان‌سفر (Time-travel) و میان‌افزار (Middleware) برای درخواست‌های غیرهمزمان داریم → Redux Toolkit را انتخاب می‌کنم.مثال: پنل مدیریتی با ده‌ها صفحه، تعداد زیادی API موازی، و نیاز به دیباگ دقیق اتفاقاتی که در طول زمان رخ داده.دلیل Senior: RTK به‌خاطر ساختار اجباری خود، باعث یکنواختی کد در تیم‌های بزرگ می‌شود و createAsyncThunk به‌خوبی وضعیت‌های loading/error را مدیریت می‌کند.اگر اپلیکیشن کوچک‌تر یا متوسط است، تیم چابک دارد، و بیشتر به سادگی و کاهش Boilerplate نیاز داریم → Zustand را ترجیح می‌دهم.مثال: یک داشبورد تحلیلی یا فروشگاه اینترنتی با تعداد محدودی اسلایس.دلیل Senior: Zustand نیازی به Provider ندارد، مستقیماً استفاده می‌شود، و به‌خاطر استفاده از subscribe، می‌توانم به‌راحتی از رندر مجدد اضافی جلوگیری کنم.۳. State سمت سرور (Server State) – کاملاً جداستاینجا کاملاً از React Query (یا TanStack Query) استفاده می‌کنم، نه Redux.دلیلش این است که: کش کردن، بازپرس‌گیری خودکار (Re-fetch)، مدیریت وضعیت‌های Stale-While-Revalidate، و همگام‌سازی با سرور، وظایفی هستند که Redux برایشان طراحی نشده و باعث می‌شود کدمان سرشار از Boilerplate و باگ شود.سناریوی عملی:اگر کاربری یک لیست را مشاهده می‌کند و سپس به صفحه‌ی جزئیات می‌رود، React Query به‌طور پیش‌فرض داده‌ها را کش می‌کند و در بازگشت، بدون درخواست مجدد، نمایش می‌دهد. این کار با Redux نیاز به نوشتن منطق کش و زمان‌انقضا دارد که اصلاً به‌صرفه نیست.۴. State مبتنی بر URL (Route State) – متعلق به Next.js استدر Next.js، من از URL Parameters، Search Params و Server Components به‌عنوان منبع حقیقت (Single Source of Truth) استفاده می‌کنم.مثال: فیلترهای جستجو یا شماره‌ی صفحه‌بندی را در useSearchParams ذخیره می‌کنم، چون کاربر می‌تواند لینک را به اشتراک بگذارد و صفحه با همان حالت بارگذاری شود.نکته‌ی مهم Senior: هرگز این داده‌ها را در Redux کپی نمی‌کنم تا از عدم هماهنگی (Out of Sync) جلوگیری کنم.۵. استراتژی ترکیبی (فراتر از ابزار) – اصل تفکیک وظایفدر پروژه‌های بزرگ، من از معماری لایه‌ای استفاده می‌کنم:لایه‌ی سرور: داده‌ها از طریق Server Components در Next.js و React Query (در سمت کلاینت) تأمین می‌شوند.لایه‌ی کلاینت جهانی: Zustand یا Redux فقط برای State های UI (مثل تم، وضعیت سایدبار، یا انتخاب‌های موقت کاربر) استفاده می‌شود.لایه‌ی فرم: از React Hook Form به‌همرافـت Zustand برای مدیریت State موقت فرم قبل از ارسال استفاده می‌کنم.جمع‌بندی نهایی برای مصاحبه‌گر:«به‌عنوان یک Senior، من مخالف استفاده از یک ابزار برای همه‌چیز هستم. استراتژی من این است:Server State → React QueryClient Global State → Zustand (برای سرعت توسعه) یا Redux Toolkit (برای مقیاس‌پذیری و دیباگ)URL State → Next.js RouterLocal State → React Hooks خالصمهم‌تر از انتخاب ابزار، تعیین مرزهای هر لایه و جلوگیری از نشت داده‌ها (Data Leakage) بین این لایه‌هاست. این کار باعث می‌شود تست‌پذیری افزایش یابد، پرفورمنس بهینه شود و تیم بتواند به‌صورت موازی روی بخش‌های مختلف کار کند.»

28- Cache Invalidation استراتژی‌ها (بر اساس tags و paths)

مصطفی رستگار — Tue, 11 Aug 2026 12:48:32 +0330

برای مصاحبه فنی، بهترین روش این است که اول مسئله را توضیح دهی، بعد راه‌حل را، و در آخر مثال عملی بزنی. در ادامه یک متن آماده و روان برای بیان شفاهی آماده کرده‌ام:متن آماده برای مصاحبه (بیان شفاهی)«در Next.js، ما برای افزایش سرعت، داده‌ها را کش (Cache) می‌کنیم. اما مشکل اینجاست که وقتی داده‌ها در بک‌اند تغییر می‌کنند، کش ما قدیمی می‌شود. به این مشکل Stale Data می‌گوییم. برای حل این مشکل، از استراتژی‌های Cache Invalidation استفاده می‌کنیم که یعنی «چه زمانی کش را باطل و داده‌های تازه را جایگزین کنیم».»«در Next.js دو رویکرد اصلی داریم: بر اساس مسیر (Path-based) و بر اساس تگ (Tag-based).»۱. استراتژی بر اساس مسیر (Path-based Revalidation)«در این روش، به Next.js می‌گوییم که هر چند ثانیه یک‌بار، یک صفحه‌ی خاص را دوباره بساز. این کار با دو مقدار انجام می‌شود:»time-based در fetch یا revalidate در صفحه:«مثلاً اگر بنویسم revalidate: 60، یعنی هر ۶۰ ثانیه یک‌بار، این صفحه در پس‌زمینه ری‌جنریت می‌شود و دفعه‌ی بعد که کاربر بیاید، نسخه‌ی تازه را می‌بیند.»revalidatePath در سرور اکشن‌ها:«وقتی کاربر کاری انجام می‌دهد (مثل ثبت نظر)، من با revalidatePath('/posts') به Next.js می‌گویم که مسیر مربوطه را پاک کن و در دفعه‌ی بعد که درخواست شد، از نو بساز.»«مزیتش سادگی است، اما عیبش این است که اگر مسیرهای زیادی داشته باشیم، باید تک‌تک آن‌ها را مدیریت کنیم.»۲. استراتژی بر اساس تگ (Tag-based Revalidation)«روش دقیق‌تر، استفاده از تگ است. من هنگام دریافت داده، یک برچسب (تگ) به آن attach می‌کنم. مثلاً:»javascriptfetch('https://api.example.com/posts', { next: { tags: ['posts'] } })«حالا هر جا که داده‌ی مربوط به پست‌ها تغییر کند، مثلاً یک پست جدید اضافه شود، من با دستور revalidateTag('posts') به Next.js می‌گویم: هر درخواستی که این تگ را دارد، کشش را باطل کن.»«مزیت بزرگ این روش این است که من نیازی نمی‌دانم داده در کدام مسیر استفاده شده است. Next.js خودش تمام مسیرهایی که از این تگ استفاده کرده‌اند را پیدا کرده و آن‌ها را ری‌جنریت می‌کند.»«این روش برای اپلیکیشن‌های بزرگ خیلی مناسب‌تر است، چون کش را به‌صورت دانه‌دانه (Granular) و بر اساس موضوع داده مدیریت می‌کنیم، نه بر اساس صفحه.»نکته‌ی کلیدی برای مصاحبه (جمع‌بندی)«نکته‌ی مهم این است که در Next.js 14 به‌بعد، هر دو روش در سرور کامپوننت‌ها و سرور اکشن‌ها قابل استفاده هستند. انتخاب بین این دو به این بستگی دارد که: اگر داده‌ی ما در چندین صفحه پراکنده است، Tag-based بهتر است و اگر فقط یک صفحه‌ی خاص را داریم، Path-based کافی است. همچنین می‌توانیم هر دو را با هم ترکیب کنیم.»اگر مصاحبه‌کننده سوال عمیق‌تر پرسید:تفاوت revalidatePath و revalidateTag چیست؟revalidatePath یک مسیر خاص را پاک می‌کند، ولی revalidateTag تمام مسیرهایی که از آن تگ استفاده کرده‌اند را پیدا کرده و پاک می‌کند.آیا می‌توانیم درخواست‌های client-side را هم مدیریت کنیم؟در سمت کلاینت، از کتابخانه‌هایی مثل React Query یا SWR استفاده می‌کنیم که با useQuery و invalidateQueries کار مشابهی را انجام می‌دهند، اما در Next.js بحث ما روی کش سرور است.

26- Streaming SSR و Suspense در Next.js (رندر تدریجی HTML و TTFB)

مصطفی رستگار — Tue, 11 Aug 2026 10:53:06 +0330

قسمت Streaming SSR و Suspense۱. شروع مکالمه (بیان مشکل قدیمی):"اگر بخواهم خیلی ساده توضیح بدهم، قبلاً در خیلی از فریمورک‌ها، وقتی کاربر درخواست یک صفحه را می‌داد، سرور باید تمام اطلاعات آن صفحه (مثل دیتای API) را از بیرون می‌گرفت، صبر می‌کرد تا همه چیز آماده شود، بعد کل HTML را یکجا تولید می‌کرد و برای کاربر می‌فرستاد. به این حالت SSR کلاسیک می‌گوییم."۲. مشکل این روش (مقدمه‌ای برای Streaming):"مشکل اینجا بود که اگر یکی از اطلاعات سنگین یا کند بود، کل صفحه متوقف می‌شد و کاربر تا رسیدن کامل HTML، یک صفحه سفید می‌دید. این موضوع باعث می‌شد زمان اولین بایت (TTFB) خیلی بالا برود، چون مرورگر باید صبر می‌کرد تا کل کار سرور تمام شود."۳. راه‌حل Next.js (معرفی Streaming SSR):"اینجاست که Next.js با قابلیت Streaming SSR وارد می‌شود. یعنی سرور دیگر منتظر نمی‌ماند تا همه چیز آماده شود. به محض اینکه بخش‌های سریع صفحه (مثل هدر و فوتر) آماده شدند، آنها را به صورت پاره‌پاره (Stream) و همان لحظه برای مرورگر می‌فرستد."۴. نقش Suspense (چگونه این کار ممکن می‌شود؟):"این کار با کمک کامپوننت در React انجام می‌شود. ما بخش‌های کند صفحه را درون یک Suspense می‌پیچیم و یک fallback (مثل یک اسکلت‌لودینگ) برای آن تعریف می‌کنیم."۵. سناریوی اجرا (بیان روند گام‌به‌گام):"وقتی کاربر صفحه را باز می‌کند:۱. سرور فوراً بخش‌های سریع را می‌فرستد و کاربر بلافاصله اسکلت اصلی صفحه را می‌بیند (TTFB خیلی پایین می‌آید).۲. برای بخشی که درون Suspense است، سرور یک placeholder (همان fallback) را در همان استریم اولیه می‌فرستد.۳. بعد از اینکه دیتای آن بخش خاص روی سرور آماده شد، Next.js قطعه HTML مربوط به همان بخش را به صورت جداگانه در همان استریم باز به مرورگر می‌فرستد.۴. React در مرورگر این قطعه جدید را تشخیص می‌دهد و جایگزین fallback می‌کند."۶. مزیت نهایی (جمع‌بندی برای مصاحبه‌کننده):"نتیجه این کار دو مزیت بزرگ دارد:اولاً TTFB به شدت کاهش پیدا می‌کند، چون کاربر خیلی زودتر از قبل محتوای اولیه را می‌بیند.ثانیاً ما یک رندر تدریجی (Incremental Rendering) داریم. یعنی صفحه به مرور و قطعه‌قطعه کامل می‌شود، بدون اینکه کاربر احساس کند صفحه قفل شده است. این یعنی تجربه کاربری خیلی روان‌تر و شاخص‌های Core Web Vitals بهتری داریم."نکته طلایی برای مصاحبه‌کننده (اگر خیلی حرفه‌ای باشد):اگر مصاحبه‌کننده بپرسد: "مگه فرقش با CSR چیه؟" می‌توانید این را اضافه کنید:"در CSR، همه چیز در مرورگر اتفاق می‌افتد و یک صفحه خالی می‌بینیم تا همه جاوااسکریپت لود شود. اما در Streaming SSR، محتوای HTML واقعی را از همان ابتدا به صورت جزیی دریافت می‌کنیم، که برای SEO و سرعت درک محتوا توسط کاربر خیلی حیاتی است."

25- Turbopack vs Webpack (تفاوت معماری و زمان بیلد)

مصطفی رستگار — Mon, 10 Aug 2026 16:42:55 +0330

مقدمه:"هر دو Webpack و Turbopack، ابزارهای bundler (بسته‌ساز) هستند؛ یعنی کدهای ما (ماژول‌ها، کامپوننت‌ها، فایل‌های CSS و تصاویر) را گرفته و آنها را به فایل‌های بهینه‌شده برای مرورگر تبدیل می‌کنند. اما تفاوت اصلی در این است که Turbopark توسط تیم Vercel و مخصوص اکوسیستم Next.js ساخته شده تا جایگزین سریع‌تری برای Webpack باشد، مخصوصاً در محیط توسعه (Development)."۱. تفاوت در معماری (چطور کار می‌کنند):Webpack (معماری قدیمی و مبتنی بر Node.js):Webpack در زمان اجرا، تمام فایل‌های پروژه را اسکن می‌کند، یک گراف وابستگی (Dependency Graph) می‌سازد و سپس هر فایل را یکی‌یکی با استفاده از لودرهای مختلف پردازش (ترنسفورم) می‌کند. این پردازش به صورت همزمان (synchronous) و با استفاده از تابع‌های JavaScript در محیط Node.js انجام می‌شود. به همین دلیل با افزایش تعداد فایل‌ها، زمان بیلد به شدت افزایش می‌یابد.Turbopack (معماری مدرن و مبتنی بر Rust):Turbopack با زبان Rust نوشته شده که بسیار سریع‌تر از JavaScript است. اما مهم‌تر از آن، از یک معماری Lazy Bundling یا بسته‌بندی تنبل استفاده می‌کند. یعنی فقط فایل‌هایی که در مرورگر درخواست می‌شوند یا تغییر کرده‌اند را پردازش می‌کند، نه کل پروژه را. همچنین از تکنیک‌های موازی‌سازی (Parallel Processing) و کش‌کردن بسیار هوشمندانه بهره می‌برد.۲. تفاوت در زمان بیلد (Build Time):Webpack:زمان بیلد در Webpack معمولاً با رشد پروژه، خطی (Linear) یا حتی نمایی افزایش می‌یابد. یعنی اگر تعداد فایل‌های شما دو برابر شود، زمان بیلد تقریباً دو برابر یا بیشتر می‌شود. در پروژه‌های بزرگ، زمان شروع سرور توسعه (Cold Start) ممکن است چندین دقیقه طول بکشد که برای تیم‌های بزرگ خسته‌کننده است.Turbopack:Turbopack زمان بیلد را به شدت کاهش می‌دهد. طبق تست‌های رسمی، در پروژه‌های بزرگ، Turbopack می‌تواند تا ۱۰ برابر سریع‌تر از Webpack باشد. دلیلش این است که فقط فایل‌های تغییر داده‌شده را بازسازی (Rebuild) می‌کند و از کش سخت‌افزاری سطح پایین (OS-level caching) استفاده می‌کند. نتیجه این می‌شود که سرور توسعه در کسری از ثانیه راه‌اندازی می‌شود و تجربه توسعه (Developer Experience) بسیار لذت‌بخش‌تری داریم.۳. جمع‌بندی نهایی برای مصاحبه:"اگر بخواهم خیلی ساده بگویم:Webpack مثل یک کارگر خسته‌ای است که هر بار کل انبار را برای پیدا کردن یک جعبه می‌گردد، ولی Turbopack مثل یک ربات هوشمند است که فقط جعبه‌ای که نیاز داریم را از قبل آماده کرده و بقیه را تا وقتی نیاز نشوند، دست نمی‌زند. به همین دلیل Turbopack برای پروژه‌های جدید Next.js توصیه می‌شود، اما باید توجه داشت که در حال حاضر (نسخه ۱۳ به بالا) بیشتر برای محیط توسعه (Development) بهینه شده است و برای بیلد نهایی (Production) همچنان از Webpack استفاده می‌شود، هرچند که در آینده این تغییر خواهد کرد."نکات کلیدی که حتماً در مصاحبه بگویید:زبان Rust در مقابل JavaScript.معماری Lazy bundling در Turbopack.کاهش زمان Cold Start و Hot Reload.مناسب برای محیط توسعه، نه الزاماً تولید نهایی (تا الان).

24- Module Federation در Next.js (Micro-frontend)

مصطفی رستگار — Mon, 10 Aug 2026 16:35:09 +0330

«ماژول فدریشن یک تکنیک در دنیای جاوااسکریپت است که به ما اجازه می‌دهد چند اپلیکیشن مجزا را در حین اجرا (Runtime) به هم متصل کنیم. یعنی بدون اینکه نیاز به دیپلوی همزمان داشته باشیم، یک اپلیکیشن می‌تواند کامپوننت‌ها یا صفحات را از اپلیکیشن دیگر بخواند و استفاده کند.در Next.js، این قابلیت به کمک پلاگین‌هایی مثل @module-federation/nextjs-mf پیاده‌سازی می‌شود. این یعنی تیم‌های مختلف می‌توانند هرکدام روی یک بخش از سایت کار کنند (مثل صفحه محصول، سبد خرید یا پنل کاربری) و این بخش‌ها را به صورت مستقل توسعه و دیپلوی کنند.در نهایت، یک اپلیکیشن هاست (Host) این بخش‌ها را کنار هم قرار می‌دهد و به کاربر نشان می‌دهد. مزیت اصلی این کار این است که اگر تیم سبد خرید، تغییر جدیدی دهد، فقط همان بخش آپدیت می‌شود و نیازی به دیپلوی کل پروژه نیست. به این معماری، میکرو-فرانت‌اند می‌گوییم.»نکات کلیدی که در ادامه می‌توانید اضافه کنیداگر مصاحبه‌کننده سوالات بیشتری پرسید، این نکات را هم مطرح کنید:یک مثال عینی برای توضیح بهتر«فرض کنید یک فروشگاه اینترنتی داریم. تیم A روی صفحه محصول کار می‌کند، تیم B روی سبد خرید و تیم C روی بخش نظرات. هر تیم به صورت جداگانه کد می‌زند و دیپلوی می‌کند. اما وقتی کاربر وارد سایت می‌شود، اپلیکیشن اصلی (Host) این سه بخش را از سرورهای مختلف دریافت کرده و در کنار هم نمایش می‌دهد. این کار باعث می‌شود سرعت توسعه بالا برود و ریسک دیپلوی کاهش پیدا کند.»

23- React Server Components Payload (انتقال داده سرور به کلاینت)

مصطفی رستگار — Sun, 09 Aug 2026 15:12:50 +0330

سناریو: نمایش لیست محصولات با قیمتگذاری لحظهایفرض کنید اپلیکیشن فروشگاهی داریم که قیمت محصولات باید از دیتابیس خوانده شود و با تخفیفهای سروری محاسبه گردد.1. کامپوننت اصلی (صفحه) - (Server Component)tsx// app/products/page.tsx (این یک Server Component است) import { getProducts } from '@/lib/database'; import { ProductListClient } from './ProductListClient'; // این تابع فقط در سرور اجرا میشود و هرگز به مرورگر نمیرود async function calculateDiscountedPrice(basePrice: number) { 'use server'; // محاسبات سنگین روی سرور (مثلاً اعمال تخفیف ویژه) return basePrice * 0.8; } export default async function ProductsPage() { // 1. گرفتن داده از دیتابیس در سمت سرور const products = await getProducts(); // 2. پردازش سنگین روی سرور (محاسبه قیمت نهایی) const processedProducts = await Promise.all( products.map(async (p) => ({ ...p, finalPrice: await calculateDiscountedPrice(p.price) })) ); // 3. ارسال دادههای پردازششده به کامپوننت کلاینت return ; }2. کامپوننت سمت کلاینت (برای تعامل با کاربر)tsx// app/products/ProductListClient.tsx (این یک Client Component است) 'use client'; import { useState } from 'react'; // این کامپوننت در مرورگر اجرا میشود export function ProductListClient({ initialProducts }: { initialProducts: any[] }) { const [sortOrder, setSortOrder] = useState('asc'); // مرتبسازی فقط در سمت کلاینت انجام میشود (بدون رفتن به سرور) const sortedProducts = [...initialProducts].sort((a, b) => { return sortOrder === 'asc' ? a.finalPrice - b.finalPrice : b.finalPrice - a.finalPrice; }); return (

{product.name} - قیمت: {product.finalPrice} تومان

); }حالا بریم سراغ توضیح Payload در این مثال:در مصاحبه، دقیقاً به این کدها اشاره کنید و بگویید:"وقتی کاربر درخواست میدهد، سرور تابع getProducts و calculateDiscountedPrice را اجرا میکند. اما سوال اینجاست که چه چیزی برای مرورگر فرستاده میشود؟"سپس این تصویر را ترسیم کنید:سرور یک Payload میسازد که شامل این موارد است:HTML اولیه: ساختار

}> {/* این کامپوننت به صورت غیرهمزمان (Stream) بارگذاری میشود */}

22- Concurrent Rendering و Transitions useTransition, useDeferredValue)

مصطفی رستگار — Sun, 09 Aug 2026 14:39:01 +0330

متن پیشنهادی برای مصاحبه«برای شروع بهتر است بگویم که هدف اصلی قابلیتهای جدید React، یعنی Concurrent Rendering و Transitions، بهبود تجربه کاربری (UX) و حفظ واکنشگرایی (Responsiveness) برنامه است، مخصوصاً وقتی با دادههای سنگین یا پردازشهای زمانبر مواجه میشویم.»۱. مشکل قدیمی (همزمانی blocking)«در نسخههای قدیمی React، رندرینگ به صورت همزمان (Synchronous) و غیرقابل وقفه بود. یعنی اگر کاربر دکمهای را میزد که باعث فیلتر شدن یک لیست ۱۰۰۰ تایی میشد، صفحه تا وقتی که این پردازش و رندرینگ تمام نشود، قفل (Block) میشد. در این حالت، کاربر نمیتوانست تایپ کند، اسکرول کند یا دکمه دیگری بزند. این یعنی تجربه کاربری ضعیف.»۲. راهحل: رندرینگ همزمان (Concurrent Rendering)«React 18 با معرفی Concurrent Rendering این مشکل را حل کرد. یعنی موتور رندرینگ React دیگر یک پروسه یکباره نیست؛ بلکه میتواند کار را متوقف کند، به عقب برگردد یا اولویتها را جابهجا کند. در واقع React به ما این امکان را میدهد که بهش بگوییم: "این آپدیت جدید خیلی فوری نیست، اگر کار فوریتری پیش آمد، اول آن را انجام بده."»۳. ابزار اصلی: useTransition«برای پیادهسازی این قابلیت، از هوک useTransition استفاده میکنیم. این هوک دو چیز به ما میدهد: یک isPending (برای نمایش اسپینر یا حالت بارگذاری) و یک تابع startTransition.»نکته کلیدی برای گفتن: «همه آپدیتهایی که داخل startTransition قرار میدهیم، به عنوان آپدیت غیرفوری (Low-priority) در نظر گرفته میشوند.»مثال عملی:«فرض کنید یک اپلیکیشن جستجوی محصولات داریم. وقتی کاربر در اینپوت تایپ میکند، ما تابع setKeyword را داخل startTransition میگذاریم. با این کار، وقتی کاربر تایپ میکند، واکنش صفحه (تغییرات اینپوت) سریع انجام میشود، ولی لیست محصولات با کمی تأخیر و وقتی CPU آزاد شد، آپدیت میشود. در همین حین، با استفاده از isPending به کاربر یک لودینگ ساده نشان میدهیم تا متوجه شود که برنامه بیکار نشده است.»۴. ابزار دوم: useDeferredValue«ابزار دیگر، هوک useDeferredValue است. این هوک شبیه useTransition عمل میکند، با این تفاوت که به جای اینکه ما تصمیم بگیریم کدام عملیات غیرفوری باشد، یک مقدار (State) را به آن میدهیم و از React میخواهیم که یک کپی از آن مقدار را با اولویت پایینتر برای ما نگه دارد.»مثال تفاوت:useTransition: برای زمانی که کنترل اجرا را در دست دارید (مثل یک Event Handler).useDeferredValue: برای زمانی که مقدار از بیرون (مثل Props) به شما میرسد و شما میخواهید رندر آن را به تأخیر بیندازید، بدون اینکه خودتان تابع آپدیت را صدا بزنید.جمعبندی نهایی برای مصاحبه (نکته طلایی)«به طور خلاصه، مهمترین نکتهای که در مصاحبهها باید به آن اشاره کنم این است که قرار نیست همه چیز را Non-blocking کنیم؛ بلکه هدف، اولویتبندی هوشمندانه است. ما میگوییم که تعاملات کاربر (User Interactions) همیشه اولویت بالایی دارند و هر عملیات سنگین دیگری باید به تعویق بیفتد تا برنامه همیشه چابک (Snappy) و زنده به نظر برسد.»یک دیاگرام ذهنی برای خودتان (برای حفظ کردن)مشکل: رندر سنگین = صفحه قفل میشود.راهحل: رندرینگ قابل وقفه (Concurrent).ابزار ۱ (useTransition): کنترل عملیات غیرفوری توسط خودمان.ابزار ۲ (useDeferredValue): دریافت مقدار با اولویت پایینتر از Props.نتیجه نهایی: کاربر میتواند تایپ/کلیک کند، درحالی که کار سنگین در پسزمینه داره انجام میشه.نکته اجرایی: هنگام گفتن این متن، حتماً روی کلمه "اولویت" و "وقفه پذیری" تأکید کنید. این دو واژه، کلید درک Concurrent Rendering هستند.۱. مثال کاربردی برای useTransition (جستجوی محصولات)سناریو: یک اپلیکیشن فروشگاهی که کاربر در باکس جستجو تایپ میکند و لیست محصولات فیلتر میشود.jsximport { useState, useTransition } from 'react'; // تابع سنگین شبیهسازی فیلتر کردن لیست بزرگ (مثلاً ۱۰۰۰۰ آیتم) function filterProducts(searchTerm) { const bigList = Array.from({ length: 10000 }, (_, i) => `Product ${i}`); // اگر کاربر چیزی تایپ نکرده باشد، همه را برگردان if (!searchTerm) return bigList; // شبیهسازی یک پردازش سنگین با فیلتر return bigList.filter(item => item.toLowerCase().includes(searchTerm.toLowerCase()) ); } function SearchComponent() { const [keyword, setKeyword] = useState(''); const [filteredList, setFilteredList] = useState([]); // ۱. صدا زدن هوک useTransition const [isPending, startTransition] = useTransition(); // تابعی که هنگام تایپ کاربر صدا زده میشود const handleSearch = (e) => { const newKeyword = e.target.value; setKeyword(newKeyword); // <-- این آپدیت فوری است (برای اینپوت) // ۲. شروع Transition startTransition(() => { // کار سنگین را داخل Transition قرار میدهیم const result = filterProducts(newKeyword); setFilteredList(result); // <-- این آپدیت اولویت پایین دارد }); }; return (

{/* ۳. نمایش وضعیت pending به کاربر */} {isPending &&

در حال جستجو...

}

{item}

); } export default SearchComponent;توضیح شفاهی هنگام ارائه کد در مصاحبه:«در اینجا خط setKeyword خارج از Transition قرار دارد تا ورودی کاربر بیدرنگ آپدیت شود. ولی خط setFilteredList داخل Transition است. بنابراین اگر کاربر خیلی سریع تایپ کند، React کار قبلی فیلتر کردن را نیمهکاره رها میکند و به جای آن، روی تایپ جدید تمرکز میکند. isPending هم به ما کمک میکند تا یک اسپینر نشان دهیم و کاربر بداند که برنامه هنگ نکرده است.»۲. مثال کاربردی برای useDeferredValue (نمایش لیست بر اساس Props)سناریو: یک کامپوننت فرزند که یک props سنگین دریافت میکند و ما نمیخواهیم که والد، تابع آپدیت را در دست بگیرد (مثل استفاده در مسیریابی یا Redux).jsximport { useState, useDeferredValue, useMemo } from 'react'; // تابع سنگین برای مرتبسازی یا فیلتر function processLargeData(inputText) { const fakeData = Array.from({ length: 20000 }, (_, i) => `Item ${i}`); if (!inputText) return fakeData; return fakeData.filter(item => item.includes(inputText)); } // کامپوننت فرزند که داده را از والد میگیرد function ListComponent({ searchTerm }) { // ۱. گرفتن یک نسخه با اولویت پایین از props const deferredSearchTerm = useDeferredValue(searchTerm); // ۲. استفاده از useMemo برای اینکه فقط وقتی مقدار deferred تغییر کرد، دوباره محاسبه کند const items = useMemo(() => { console.log('محاسبه سنگین با مقدار:', deferredSearchTerm); return processLargeData(deferredSearchTerm); }, [deferredSearchTerm]); return (

{/* اگر مقدار واقعی با مقدار deferred متفاوت است، یعنی یک آپدیت در حال انجام است */} {searchTerm !== deferredSearchTerm ? 'در حال بهروزرسانی...' : 'نمایش دادهها'}

{item}

); } // کامپوننت والد function ParentComponent() { const [inputValue, setInputValue] = useState(''); return (

جستجو (useDeferredValue)

setInputValue(e.target.value)} placeholder="متن مورد نظر را وارد کنید..." /> {/* ارسال props به فرزند */}

); } export default ParentComponent;توضیح شفاهی هنگام ارائه کد در مصاحبه:«در این مثال، والد اصلاً از Transition استفاده نمیکند. والد هر چه کاربر تایپ میکند، همان را به searchTerm پاس میدهد. اما در کامپوننت فرزند، با useDeferredValue یک کپی با تأخیر از آن مقدار میگیرم. نکته مهم این است که اگر کاربر سریع تایپ کند، کامپوننت چند بار با مقدار قدیمی رندر میشود تا زمانی که CPU آزاد شود و در نهایت مقدار جدید جایگزین گردد. این روش برای زمانی عالی است که ما کنترلگر Event Handler نیستیم (مثلاً داده از Redux یا Context میآید).»۳. مقایسه کنار هم (برای جمعبندی نهایی کدنویسی)اگر مصاحبهکننده پرسید "کدام را کی استفاده کنم؟"، این جدول ذهنی را توضیح دهید:موقعیتابزار مناسبدکمهای که عملیات سنگین انجام میدهد (مثل خروجی گرفتن گزارش)useTransitionسرچ باکس که میخواهید ورودی فوری باشد ولی نتایج با تأخیر بیایندuseTransitionداده از طریق props از بیرون میآید و شما کنترلی روی تابع آپدیت نداریدuseDeferredValueمیخواهید دقیقاً وضعیت loading را کنترل کنید (اسپینر دستی)useTransition (چون isPending دارد)یک نکته طلایی برای مصاحبه (با کد فرضی):اگر خواستند تفاوت را ثابت کنید، بگویید:«اگر کد مثال اول را با مثال دوم مقایسه کنید، در مثال اول setKeyword (آپدیت اینپوت) و setFilteredList (آپدیت لیست) هر دو در یک تابع هستند، اما با Transition از هم جدا شدند. ولی در مثال دوم، ما اصلاً تابع setter را اجرا نمیکنیم؛ React خودش تفاوت بین searchTerm فعلی و deferredSearchTerm را مدیریت میکند و رندرهای اضافی را انجام میدهد.»نکته اجرایی: حت

راهنمای جامع CRUD با Server Actions در Next.js 16 - نسخه معماری لایه ای

مصطفی رستگار — Sun, 09 Aug 2026 14:35:46 +0330

فهرست مطالبمقدمهساختار پروژهلایه Utilsلایه Repositoryلایه Services (Server Actions)کامپوننتهای مستقلجمعبندیمقدمهدر این نسخه، کدها را به صورت لایهای و کاملاً جدا از هم سازماندهی میکنیم تا خوانایی، قابلیت نگهداری و تست پذیری افزایش یابد.معماری لایهای:text┌─────────────────────────────────────────────┐ │ Presentation Layer │ │ (React Components) │ └──────────────────┬──────────────────────────┘ │ ┌──────────────────▼──────────────────────────┐ │ Service Layer │ │ (Server Actions) │ └──────────────────┬──────────────────────────┘ │ ┌──────────────────▼──────────────────────────┐ │ Repository Layer │ │ (API Communication) │ └──────────────────┬──────────────────────────┘ │ ┌──────────────────▼──────────────────────────┐ │ Utils Layer │ │ (HTTP Client, Helpers) │ └─────────────────────────────────────────────┘ساختار پروژهtextapp/ ├── categories/ │ ├── page.tsx # صفحه اصلی │ └── _components/ │ ├── CategoryList.tsx │ ├── CategoryCreateForm.tsx │ ├── CategoryEditForm.tsx │ └── CategoryDeleteButton.tsx ├── lib/ │ ├── utils/ │ │ ├── http-client.ts # کلاینت HTTP │ │ └── token-manager.ts # مدیریت توکن │ ├── repositories/ │ │ └── category.repository.ts # Repository دستهبندی │ └── services/ │ └── category.service.ts # Server Actions └── types/ └── category.ts # Typesلایه Utils1. مدیریت Tokentypescript// lib/utils/token-manager.ts import { cookies } from 'next/headers'; export class TokenManager { static async getAccessToken(): Promise { const cookieStore = cookies(); return cookieStore.get('access_token')?.value; } static async getRefreshToken(): Promise { const cookieStore = cookies(); return cookieStore.get('refresh_token')?.value; } static async getHeaders(): Promise { const token = await this.getAccessToken(); return { 'Content-Type': 'application/json', ...(token && { Authorization: `Bearer ${token}` }), }; } }2. HTTP Clienttypescript// lib/utils/http-client.ts import { TokenManager } from './token-manager'; export interface HttpClientOptions extends RequestInit { baseURL?: string; } export interface ApiResponse { success: boolean; data?: T; message?: string; errors?: Record; statusCode?: number; } export class HttpClient { private baseURL: string; constructor(baseURL?: string) { this.baseURL = baseURL || process.env.API_BASE_URL || 'http://localhost:8000/api'; } private async request( endpoint: string, options: HttpClientOptions = {} ): Promise> { const url = `${this.baseURL}${endpoint}`; const headers = await TokenManager.getHeaders(); try { const response = await fetch(url, { ...options, headers: { ...headers, ...options.headers, }, }); const data = await response.json(); if (!response.ok) { return { success: false, message: data.message || 'An error occurred', errors: data.errors, statusCode: response.status, }; } return { success: true, data: data.data || data, message: data.message, statusCode: response.status, }; } catch (error) { return { success: false, message: error instanceof Error ? error.message : 'Network error', }; } } // ============ HTTP Methods ============ async get(endpoint: string, options?: HttpClientOptions): Promise> { return this.request(endpoint, { ...options, method: 'GET' }); } async post(endpoint: string, data?: any, options?: HttpClientOptions): Promise> { return this.request(endpoint, { ...options, method: 'POST', body: data ? JSON.stringify(data) : undefined, }); } async put(endpoint: string, data?: any, options?: HttpClientOptions): Promise> { return this.request(endpoint, { ...options, method: 'PUT', body: data ? JSON.stringify(data) : undefined, }); } async patch(endpoint: string, data?: any, options?: HttpClientOptions): Promise> { return this.request(endpoint, { ...options, method: 'PATCH', body: data ? JSON.stringify(data) : undefined, }); } async delete(endpoint: string, options?: HttpClientOptions): Promise> { return this.request(endpoint, { ...options, method: 'DELETE' }); } } // ============ Singleton Instance ============ let httpClientInstance: HttpClient | null = null; export function getHttpClient(): HttpClient { if (!httpClientInstance) { httpClientInstance = new HttpClient(); } return httpClientInstance; }لایه Repositorytypescript// lib/repositories/category.repository.ts import { getHttpClient } from '../utils/http-client'; import type { Category, CreateCategoryDto, UpdateCategoryDto, ApiResponse } from '@/types/category'; export class CategoryRepository { private readonly endpoint = '/categories'; // ============ CRUD Operations ============ async getAll(): Promise> { const http = getHttpClient(); return http.get(this.endpoint); } async getById(id: string): Promise> { const http = getHttpClient(); return http.get(`${this.endpoint}/${id}`); } async create(data: CreateCategoryDto): Promise> { const http = getHttpClient(); return http.post(this.endpoint, data); } async update(id: string, data: UpdateCategoryDto): Promise> { const http = getHttpClient(); return http.put(`${this.endpoint}/${id}`, data); } async delete(id: string): Promise> { const http = getHttpClient(); return http.delete(`${this.endpoint}/${id}`); } // ============ Additional Methods ============ async getBySlug(slug: string): Promise> { const http = getHttpClient(); return http.get(`${this.endpoint}/slug/${slug}`); } async search(query: string): Promise> { const http = getHttpClient(); return http.get(`${this.endpoint}/search?q=${encodeURIComponent(query)}`); } } // ============ Singleton Instance ============ let categoryRepositoryInstance: CategoryRepository | null = null; export function getCategoryRepository(): CategoryRepository { if (!categoryRepositoryInstance) { categoryRepositoryInstance = new CategoryRepository(); } return categoryRepositoryInstance; }لایه Services (Server Actions)typescript// lib/services/category.service.ts 'use server'; import { revalidateTag } from 'next/cache'; import { getCategoryRepository } from '../repositories/category.repository'; import type { Category, CreateCategoryDto, UpdateCategoryDto, FormState } from '@/types/category'; // ============ Query Services ============ export async function getCategories(): Promise> { 'use server'; try { const repository = getCategoryRepository(); const result = await repository.getAll(); if (!result.success) { return { success: false, message: result.message, errors: result.errors, }; } return { success: true, data: result.data || [], }; } catch (error) { return { success: false, message: 'Failed to fetch categories', }; } } export async function getCategoryById(id: string): Promise> { 'use server'; try { const repository = getCategoryRepository(); const result = await repository.getById(id); if (!result.success) { return { success: false, message: result.message, errors: result.errors, }; } return { success: true, data: result.data, }; } catch (error) { return { success: false, message: 'Failed to fetch category', }; } } // ============ Mutation Services ============ export async function createCategory( prevState: FormState, formData: FormData ): Promise> { 'use server'; // Extract data const data: CreateCategoryDto = { name: formData.get('name') as string, description: formData.get('description') as string, }; // Client-side validation (optional) if (!data.name?.trim()) { return { success: false, errors: { name: ['Name is required'] }, }; } try { const repository = getCategoryRepository(); const result = await repository.create(data); if (!result.success) { return { success: false, message: result.message, errors: result.errors, }; } // Revalidate cache revalidateTag('categories'); if (result.data) { revalidateTag(`category_${result.data.id}`); } return { success: true, data: result.data, message: 'Category created successfully', }; } catch (error) { return { success: false, message: 'Failed to create category', }; } } export async function updateCategory( id: string, prevState: FormState, formData: FormData ): Promise> { 'use server'; // Extract data const data: UpdateCategoryDto = { id, name: formData.get('name') as string, description: formData.get('description') as string, }; try { const repository = getCategoryRepository(); const result = await repository.update(id, data); if (!result.success) { return { success: false, message: result.message, errors: result.errors, }; } // Revalidate cache revalidateTag('categories'); revalidateTag(`category_${id}`); return { success: true, data: result.data, message: 'Category updated successfully', }; } catch (error) { return { success: false, message: 'Failed to update category', }; } } export async function deleteCategory( id: string, prevState: FormState ): Promise { 'use server'; try { const repository = getCategoryRepository(); const result = await repository.delete(id); if (!result.success) { return { success: false, message: result.message, }; } // Revalidate cache revalidateTag('categories'); revalidateTag(`category_${id}`); return { success: true, message: 'Category deleted successfully', }; } catch (error) { return { success: false, message: 'Failed to delete category', }; } } // ============ Bulk Operations ============ export async function deleteMultipleCategories( ids: string[] ): Promise { 'use server'; try { const repository = getCategoryRepository(); const results = await Promise.all( ids.map(id => repository.delete(id)) ); const allSuccess = results.every(r => r.success); if (!allSuccess) { return { success: false, message: 'Failed to delete some categories', }; } revalidateTag('categories'); ids.forEach(id => revalidateTag(`category_${id}`)); return { success: true, message: 'Categories deleted successfully', }; } catch (error) { return { success: false, message: 'Failed to delete categories', }; } }کامپوننت های مستقل1. کامپوننت Createtsx// app/categories/_components/CategoryCreateForm.tsx 'use client'; import { useActionState, useEffect, useRef } from 'react'; import { useRouter } from 'next/navigation'; import { createCategory } from '@/lib/services/category.service'; import type { FormState } from '@/types/category'; interface CategoryCreateFormProps { onSuccess?: () => void; ?: () => void; } export function CategoryCreateForm({ onSuccess, }: CategoryCreateFormProps) { const router = useRouter(); const formRef = useRef(null); const [state, formAction, isPending] = useActionState( createCategory, {} as FormState ); useEffect(() => { if (state.success) { formRef.current?.reset(); onSuccess?.(); router.refresh(); } }, [state.success, onSuccess, router]); return ( ); }2. کامپوننت Edittsx// app/categories/_components/CategoryEditForm.tsx 'use client'; import { useActionState, useEffect } from 'react'; import { useRouter } from 'next/navigation'; import { updateCategory } from '@/lib/services/category.service'; import type { Category, FormState } from '@/types/category'; interface CategoryEditFormProps { category: Category; onSuccess?: () => void; } export function CategoryEditForm({ category, onSuccess }: CategoryEditFormProps) { const router = useRouter(); const [state, formAction, isPending] = useActionState( updateCategory.bind(null, category.id), {} as FormState ); useEffect(() => { if (state.success) { onSuccess?.(); router.refresh(); } }, [state.success, onSuccess, router]); return ( ); }3. کامپوننت Deletetsx// app/categories/_components/CategoryDeleteButton.tsx 'use client'; import { useActionState, useEffect, useState } from 'react'; import { useRouter } from 'next/navigation'; import { deleteCategory } from '@/lib/services/category.service'; import type { FormState } from '@/types/category'; interface CategoryDeleteButtonProps { categoryId: string; categoryName: string; onDeleted?: () => void; } export function CategoryDeleteButton({ categoryId, categoryName, onDeleted, }: CategoryDeleteButtonProps) { const router = useRouter(); const [isModalOpen, setIsModalOpen] = useState(false); const [state, formAction, isPending] = useActionState( deleteCategory.bind(null, categoryId), {} as FormState ); useEffect(() => { if (state.success) { setIsModalOpen(false); onDeleted?.(); router.refresh(); } }, [state.success, onDeleted, router]); return ( <> setIsModalOpen(true)} className="px-3 py-1 text-sm bg-red-100 text-red-700 rounded hover:bg-red-200 transition-colors" > 🗑️ Delete {isModalOpen && (

Delete Category

Are you sure you want to delete "{categoryName}"? This action cannot be undone.

{state.message && !state.success && (

{state.message}

)}

)} ); }4. کامپوننت Listtsx// app/categories/_components/CategoryList.tsx 'use client'; import { useState } from 'react'; import { CategoryCreateForm } from './CategoryCreateForm'; import { CategoryEditForm } from './CategoryEditForm'; import { CategoryDeleteButton } from './CategoryDeleteButton'; import type { Category } from '@/types/category'; interface CategoryListProps { initialData: Category[]; } export function CategoryList({ initialData }: CategoryListProps) { const [categories] = useState(initialData); const [editingCategory, setEditingCategory] = useState(null); const [showCreateForm, setShowCreateForm] = useState(false); const handleDataChange = () => { setShowCreateForm(false); setEditingCategory(null); }; return (

{/* Header */}

Category Management

); }جمعبندیمزایای معماری لایه ای:✅ Separation of Concerns: هر لایه مسئولیت مشخصی دارد✅ خوانایی بالا: کدها سازماندهی شده و قابل فهم هستند✅ قابلیت نگهداری: تغییر در هر لایه بدون تأثیر بر لایه های دیگر✅ تستپذیری: هر لایه به راحتی قابل تست است✅ Reusability: کلاس ها و توابع در جای دیگر قابل استفاده✅ Dependency Injection: استفاده از Singleton Pattern✅ Type Safety: استفاده از TypeScript در تمام لایه هاساختار لایه ها:بهترین Practices:استفاده از Singleton Pattern برای کلاس هااستفاده از 'use server' در لایه Serviceاستفاده از revalidateTag برای مدیریت کشاستفاده از useActionState در کامپوننت هامدیریت خطا در هر لایه

21- React Fiber معماری (تقسیم کار و Concurrent Mode)

مصطفی رستگار — Sun, 09 Aug 2026 14:26:11 +0330

متن آماده برای مصاحبه (بخش اول: معماری و تقسیم کار)«برای درک ری‌اکت فایبر، بهتر است اول ببینیم که ری‌اکت قدیم (Stack) چه مشکلی داشت. قبلاً وقتی وضعیت یک کامپوننت تغییر می‌کرد، ری‌اکت یک کارخانه بود که تمام مراحل ساخت را یک‌جا و پشت سر هم انجام می‌داد. یعنی می‌گفت: «برو، همه جا را بگرد، هر تغییری هست را محاسبه کن، بلافاصله در DOM واقعی اعمال کن و تمام!» اگر این محاسبات طول می‌کشید، مرورگر یخ می‌زد و کاربر کلیک کردن یا تایپ کردن را احساس نمی‌کرد.اما فایبر، معماری جدید ری‌اکت، این کارخانه را به یک تیم مدیریت پروژه تبدیل کرد. در اینجا، کار به واحدهای کوچک‌تری به نام «یونیت‌های کاری» یا Fiber nodes تقسیم می‌شود. به جای اینکه یک‌باره همه کارها را انجام دهد، فایبر این کارها را اولویت‌بندی می‌کند.مهم‌ترین نکته این است که فایبر دو فاز مجزا دارد:فاز Render (هماهنگی): در این مرحله، ری‌اکت یک «درخت مجازی» از تغییرات می‌سازد و محاسبه می‌کند که چه چیزی باید عوض شود. اما هنوز هیچ چیزی را در صفحه واقعی نشان نمی‌دهد. این فاز قابل وقفه است.فاز Commit (اعمال): این فاز کوتاه و غیرقابل‌وقفه است. یعنی ری‌اکت تغییرات نهایی را برمی‌دارد و یک‌جا به DOM واقعی می‌زند تا صفحه به‌روز شود.»متن آماده برای مصاحبه (بخش دوم: Concurrent Mode و تفاوت آن)«حالا این معماری به ما اجازه می‌دهد که ویژگی فوق‌العاده‌ای به نام Concurrent Mode یا «حالت هم‌روند» داشته باشیم. کلمه Concurrent به معنی «هم‌زمان» نیست؛ بلکه به معنی «تداخل در اولویت‌ها» است.فرض کنید در حال تایپ کردن در یک فیلد جستجو هستیم و همزمان، لیست عظیمی از نتایج باید فیلتر شود. در حالت عادی، تایپ کردن ما کند می‌شود چون ری‌اکت مشغول رندر کردن لیست است.در Concurrent Mode، ری‌اکت مثل یک منشی هوشمند عمل می‌کند. وقتی من دارم تایپ می‌کنم، فایبر به رندرینگ سنگین لیست می‌گوید: «صبر کن، فعلاً اولویت با کاربر است، کارت را متوقف کن و به من بده تا کی‌برد را پردازش کنم.» بعد که تایپ من تمام شد، دوباره کار رندر لیست را از همان جایی که متوقف کرده بود، ادامه می‌دهد.به این قابلیت، زمان‌بندی (Scheduling) می‌گوییم. یعنی ری‌اکت خودش تصمیم می‌گیرد کدام آپدیت اورژانسی‌تر است (مثل ورودی کاربر) و کدام آپدیت را می‌تواند به تعویق بیندازد (مثل رندر کردن لیست‌های سنگین).»جمع‌بندی نهایی برای مصاحبه‌کننده«در کل، فایبر به ری‌اکت یک موتور هوشمند داده که دیگر کورکورانه همه چیز را دوباره نمی‌سازد. بلکه کارها را به قطعات کوچک تقسیم می‌کند، اولویت‌بندی می‌کند و در صورت لزوم، کار سنگین را متوقف کرده تا تجربه کاربری نرم‌تر و روان‌تری داشته باشیم. این معماری پایه‌ای برای قابلیت‌های مدرن Next.js مانند Server Components هم هست، چون به ری‌اکت اجازه می‌دهد که منتظر داده‌های سرور بماند بدون اینکه کل صفحه را مسدود کند.»نکات طلایی برای بیان آن در مصاحبه:از کلمه «وقفه» استفاده کنید: بگویید «قابل وقفه» بودن، مهم‌ترین تفاوت فایبر با معماری قبلی است.تفاوت Concurrent با Parallel را بدانید: اگر مصاحبه‌کننده پرسید، بگویید Parallel یعنی همزمان اجرا شدن روی چند هسته (که در جاوااسکریپت تک‌رشته‌ای نداریم)، ولی Concurrent یعنی مدیریت تداخل و اولویت‌بندی چند کار در یک زمان.به Next.js ربط دهید: اگر از Next.js 13 یا 14 استفاده می‌کنید، اضافه کنید که Suspense و Streaming در Next.js دقیقاً از همین قابلیت فایبر برای منتظر ماندن و ادامه‌دادن استفاده می‌کنند.

نوشتن crud ساده با nextjs (prisma, zod, route handlers)

مصطفی رستگار — Sat, 08 Aug 2026 11:49:05 +0330

یک مثال کامل و روان از CRUD (Create, Read, Update, Delete) برای موجودیت Category در Next.js App Router با Route Handlers آماده کردم. فرض می‌کنیم از Prisma به عنوان ORM استفاده می‌کنیم و اعتبارسنجی با Zod انجام می‌شود.ساختار فایل‌هاtextapp/ ├── api/ │ └── categories/ │ ├── route.ts // GET (لیست همه) + POST (ساخت جدید) │ └── [id]/ │ └── route.ts // GET (یک مورد) + PUT (بروزرسانی) + DELETE (حذف) ├── lib/ │ ├── prisma.ts // کلاینت Prisma │ └── validations/ │ └── category.ts // اسکیماهای Zod۱. اسکیماهای اعتبارسنجی (Zod)lib/validations/category.tstypescriptimport { z } from "zod"; // اسکیما برای ساخت و بروزرسانی export const categorySchema = z.object({ name: z.string().min(2, "نام دسته‌بندی حداقل ۲ کاراکتر باشد"), description: z.string().optional(), slug: z.string().min(2, "اسلاگ حداقل ۲ کاراکتر باشد"), parentId: z.string().uuid("آیدی والد نامعتبر است").optional().nullable(), isActive: z.boolean().default(true), order: z.number().int().min(0).default(0), }); // تایپ استخراج شده از اسکیما (برای TypeScript) export type CategoryInput = z.infer; // اسکیما برای آپدیت (همه فیلدها آپشنال) export const categoryUpdateSchema = categorySchema.partial();۲. Route Handler اصلی (همه دسته‌بندی‌ها)app/api/categories/route.tstypescriptimport { NextRequest, NextResponse } from "next/server"; import { prisma } from "@/lib/prisma"; import { categorySchema, type CategoryInput } from "@/lib/validations/category"; import { z } from "zod"; // ============================================ // GET: دریافت لیست همه دسته‌بندی‌ها (با فیلتر و مرتب‌سازی) // ============================================ export async function GET(request: NextRequest) { try { // دریافت پارامترهای کوئری (مثلاً برای فیلتر یا صفحه‌بندی) const searchParams = request.nextUrl.searchParams; const page = parseInt(searchParams.get("page") || "1"); const limit = parseInt(searchParams.get("limit") || "10"); const isActive = searchParams.get("isActive"); const search = searchParams.get("search"); // ساخت شرط‌های فیلتر const where: any = {}; if (isActive !== null) { where.isActive = isActive === "true"; } if (search) { where.OR = [ { name: { contains: search, mode: "insensitive" } }, { slug: { contains: search, mode: "insensitive" } }, ]; } // دریافت داده‌ها از دیتابیس const [categories, totalCount] = await Promise.all([ prisma.category.findMany({ where, skip: (page - 1) * limit, take: limit, orderBy: { order: "asc" }, include: { parent: { select: { id: true, name: true, slug: true, }, }, children: { select: { id: true, name: true, slug: true, }, take: 5, // فقط ۵ فرزند اول برای جلوگیری از سنگین شدن }, _count: { select: { children: true, products: true }, }, }, }), prisma.category.count({ where }), ]); return NextResponse.json( { data: categories, pagination: { page, limit, totalCount, totalPages: Math.ceil(totalCount / limit), }, }, { status: 200 } ); } catch (error) { console.error("Error in GET /api/categories:", error); return NextResponse.json( { message: "خطا در دریافت دسته‌بندی‌ها" }, { status: 500 } ); } } // ============================================ // POST: ایجاد دسته‌بندی جدید // ============================================ export async function POST(request: NextRequest) { try { // ۱. دریافت و پارس کردن بدنه const body = await request.json(); // ۲. اعتبارسنجی با Zod const result = categorySchema.safeParse(body); if (!result.success) { return NextResponse.json( { message: "داده‌های ارسالی نامعتبر هستند", errors: result.error.issues.map((issue) => ({ field: issue.path.join("."), message: issue.message, })), }, { status: 400 } ); } const data: CategoryInput = result.data; // ۳. بررسی یکتا بودن اسلاگ const existingCategory = await prisma.category.findUnique({ where: { slug: data.slug }, }); if (existingCategory) { return NextResponse.json( { message: "این اسلاگ قبلاً استفاده شده است" }, { status: 409 } // Conflict ); } // ۴. بررسی وجود والد (اگر parentId ارسال شده) if (data.parentId) { const parent = await prisma.category.findUnique({ where: { id: data.parentId }, }); if (!parent) { return NextResponse.json( { message: "دسته‌بندی والد وجود ندارد" }, { status: 404 } ); } } // ۵. ایجاد در دیتابیس const newCategory = await prisma.category.create({ data: { name: data.name, description: data.description || null, slug: data.slug, parentId: data.parentId || null, isActive: data.isActive ?? true, order: data.order ?? 0, }, include: { parent: true, }, }); // ۶. پاسخ موفق return NextResponse.json( { message: "دسته‌بندی با موفقیت ایجاد شد", data: newCategory, }, { status: 201 } ); } catch (error) { console.error("Error in POST /api/categories:", error); return NextResponse.json( { message: "خطای داخلی سرور" }, { status: 500 } ); } }۳. Route Handler برای یک دسته‌بندی خاص (با آیدی)app/api/categories/[id]/route.tstypescriptimport { NextRequest, NextResponse } from "next/server"; import { prisma } from "@/lib/prisma"; import { categoryUpdateSchema } from "@/lib/validations/category"; // ============================================ // GET: دریافت یک دسته‌بندی با آیدی // ============================================ export async function GET( request: NextRequest, { params }: { params: { id: string } } ) { try { const { id } = params; // بررسی وجود دسته‌بندی const category = await prisma.category.findUnique({ where: { id }, include: { parent: { select: { id: true, name: true, slug: true, }, }, children: { select: { id: true, name: true, slug: true, isActive: true, }, orderBy: { order: "asc" }, }, _count: { select: { products: true }, }, }, }); if (!category) { return NextResponse.json( { message: "دسته‌بندی مورد نظر یافت نشد" }, { status: 404 } ); } return NextResponse.json({ data: category }, { status: 200 }); } catch (error) { console.error("Error in GET /api/categories/[id]:", error); return NextResponse.json( { message: "خطا در دریافت دسته‌بندی" }, { status: 500 } ); } } // ============================================ // PUT: بروزرسانی کامل یا جزئی دسته‌بندی // ============================================ export async function PUT( request: NextRequest, { params }: { params: { id: string } } ) { try { const { id } = params; // ۱. بررسی وجود دسته‌بندی const existingCategory = await prisma.category.findUnique({ where: { id }, }); if (!existingCategory) { return NextResponse.json( { message: "دسته‌بندی مورد نظر یافت نشد" }, { status: 404 } ); } // ۲. دریافت و اعتبارسنجی داده‌ها const body = await request.json(); const result = categoryUpdateSchema.safeParse(body); if (!result.success) { return NextResponse.json( { message: "داده‌های ارسالی نامعتبر هستند", errors: result.error.issues.map((issue) => ({ field: issue.path.join("."), message: issue.message, })), }, { status: 400 } ); } const data = result.data; // ۳. بررسی یکتا بودن اسلاگ (اگر تغییر کرده) if (data.slug && data.slug !== existingCategory.slug) { const slugExists = await prisma.category.findUnique({ where: { slug: data.slug }, }); if (slugExists) { return NextResponse.json( { message: "این اسلاگ قبلاً استفاده شده است" }, { status: 409 } ); } } // ۴. جلوگیری از اینکه خودش والد خودش شود! if (data.parentId && data.parentId === id) { return NextResponse.json( { message: "یک دسته‌بندی نمی‌تواند والد خودش باشد" }, { status: 400 } ); } // ۵. بررسی وجود والد جدید (اگر تغییر کرده) if (data.parentId && data.parentId !== existingCategory.parentId) { const parent = await prisma.category.findUnique({ where: { id: data.parentId }, }); if (!parent) { return NextResponse.json( { message: "دسته‌بندی والد وجود ندارد" }, { status: 404 } ); } } // ۶. بروزرسانی در دیتابیس const updatedCategory = await prisma.category.update({ where: { id }, data: { name: data.name, description: data.description, slug: data.slug, parentId: data.parentId, isActive: data.isActive, order: data.order, }, include: { parent: true, children: { select: { id: true, name: true, slug: true, }, }, }, }); return NextResponse.json( { message: "دسته‌بندی با موفقیت بروزرسانی شد", data: updatedCategory, }, { status: 200 } ); } catch (error) { console.error("Error in PUT /api/categories/[id]:", error); return NextResponse.json( { message: "خطای داخلی سرور" }, { status: 500 } ); } } // ============================================ // DELETE: حذف دسته‌بندی (با بررسی وابستگی‌ها) // ============================================ export async function DELETE( request: NextRequest, { params }: { params: { id: string } } ) { try { const { id } = params; // ۱. بررسی وجود دسته‌بندی const category = await prisma.category.findUnique({ where: { id }, include: { _count: { select: { children: true, products: true, }, }, }, }); if (!category) { return NextResponse.json( { message: "دسته‌بندی مورد نظر یافت نشد" }, { status: 404 } ); } // ۲. بررسی وابستگی‌ها (اگر فرزند یا محصول دارد) if (category._count.children > 0) { return NextResponse.json( { message: "این دسته‌بندی دارای زیردسته است. ابتدا زیردسته‌ها را حذف کنید", childrenCount: category._count.children, }, { status: 409 } // Conflict ); } if (category._count.products > 0) { return NextResponse.json( { message: "این دسته‌بندی دارای محصول است. ابتدا محصولات را جابجا یا حذف کنید", productsCount: category._count.products, }, { status: 409 } ); } // ۳. حذف از دیتابیس await prisma.category.delete({ where: { id }, }); return NextResponse.json( { message: "دسته‌بندی با موفقیت حذف شد", deletedId: id, }, { status: 200 } ); } catch (error) { console.error("Error in DELETE /api/categories/[id]:", error); return NextResponse.json( { message: "خطای داخلی سرور" }, { status: 500 } ); } }۴. مثال Prisma Schema (برای مرجع)prisma/schema.prismaprismamodel Category { id String @id @default(cuid()) name String description String? slug String @unique isActive Boolean @default(true) order Int @default(0) parentId String? createdAt DateTime @default(now()) updatedAt DateTime @updatedAt parent Category? @relation("CategoryParent", fields: [parentId], references: [id]) children Category[] @relation("CategoryParent") products Product[] @@index([parentId]) @@index([slug]) @@index([isActive]) }نکات مهم برای مصاحبه (برای درخشیدن بیشتر)مدیریت خطاهای معنادار: به جای try-catch کلی، خطاهای خاص مثل 409 Conflict برای تکراری بودن یا وابستگی‌ها برگردانده می‌شود.اعتبارسنجی دو مرحله‌ای: اول Zod برای ساختار داده، سپس چک‌های Business Logic مثل یکتا بودن اسلاگ یا وجود والد.بهینه‌سازی کوئری‌ها: استفاده از include برای روابط و select برای فیلدهای خاص (کم کردن حجم پاسخ).صفحه‌بندی و فیلتر: در GET همه دسته‌بندی‌ها، قابلیت جستجو، فیلتر و صفحه‌بندی پیاده‌سازی شده.جلوگیری از خطاهای منطقی: مثل جلوگیری از اینکه یک دسته‌بندی، والد خودش شود.حذف ایمن: قبل از حذف، وابستگی‌ها (فرزندان و محصولات) چک می‌شوند تا از خطای دیتابیس جلوگیری شود.استفاده از Promise.all: برای کوئری‌های موازی (مثل دریافت لیست و تعداد کل) برای بهبود performance.خلاصه برای گفتن در مصاحبه"برای پیاده‌سازی CRUD دسته‌بندی، از Route Handlerهای Next.js استفاده کردم. در مسیر api/categories، متد GET لیست با صفحه‌بندی و فیلتر و متد POST برای ایجاد جدید. در مسیر api/categories/[id]، متد GET برای دریافت یک مورد، PUT برای بروزرسانی (با اعتبارسنجی جزئی با partial()) و DELETE با چک وابستگی‌ها. همه ورودی‌ها با Zod اعتبارسنجی می‌شوند و خطاهای واضح به کلاینت برمی‌گردد. همچنین از Prisma برای ارتباط با دیتابیس و مدیریت روابط (والد-فرزند) استفاده کردم."

18- API Routes و Route Handlers (اعتبارسنجی با Zod)

مصطفی رستگار — Sat, 08 Aug 2026 11:44:33 +0330

۱. معرفی کلی (چرا از API Routes استفاده می‌کنیم؟)«در پروژه‌های Next.js، وقتی نیاز داریم یک Backend کوچک و یکپارچه داشته باشیم، به جای اینکه یک سرور جداگانه با Express یا Flask راه بیندازیم، از قابلیت خود Next.js به نام API Routes استفاده می‌کنیم. این یعنی توی همین پروژه فرانت‌اند، توی پوشه‌ی api، فایل‌هایی می‌نویسیم که نقش سرور رو برای ما بازی می‌کنند. در نسخه‌های جدید Next.js (مخصوصاً اپ روتینگ)، به جای فایل‌های pages/api، از Route Handlers استفاده می‌کنیم که داخل پوشه app قرار می‌گیرند.»۲. تفاوت API Routes قدیم و Route Handlers جدید (اگر سوال کنند)«در نسخه‌های قدیمی‌تر، API‌ها را در پوشه‌ی pages/api می‌نوشتیم و هر فایل، یک تابع handler داشت که با req و res کار می‌کرد. اما در App Router جدید، روش عوض شده. حالا به جای pages/api، داخل پوشه app یک پوشه به نام api می‌سازیم و داخل آن، برای هر مسیر، یک فایل route.js یا route.ts داریم که متدهای مختلف مثل GET، POST، PUT و DELETE را به صورت توابع جداگانه صادر می‌کند. مثلاً توی فایل app/api/users/route.ts، تابع export async function POST(request) { ... } رو می‌نویسیم.»۳. ساختار یک Route Handler ساده (با مثال)«یک مثال خیلی ساده: فرض کنید می‌خواهیم یک API برای ثبت‌نام کاربر بسازیم. توی مسیر app/api/register/route.ts یک تابع POST می‌نویسیم. داخل این تابع، اول با await request.json()، بدنه‌ی درخواست رو می‌گیریم. بعد داده‌ها رو اعتبارسنجی می‌کنیم، و در نهایت یا کاربر رو ذخیره می‌کنیم یا خطا برمی‌گردونیم. در نهایت با NextResponse.json() یک پاسخ JSON برمی‌گردانیم.»۴. اعتبارسنجی با Zod (قسمت اصلی و جذاب)«برای اعتبارسنجی داده‌ها، من از کتابخانه‌ی Zod استفاده می‌کنم. دلیلش اینه که Zod به ما اجازه می‌ده با یک سینتکس خیلی تمیز و شبیه به TypeScript، اسکیما یا قالب داده‌ها رو تعریف کنیم. مثلاً برای ثبت‌نام، یک اسکیما می‌سازم به این شکل:»typescriptconst registerSchema = z.object({ name: z.string().min(3, "نام حداقل ۳ کاراکتر باشد"), email: z.string().email("ایمیل معتبر نیست"), password: z.string().min(6, "رمز حداقل ۶ کاراکتر باشد") });«حالا تابع POST من، داده‌های دریافتی رو با متد safeParse بررسی می‌کنه. safeParse به جای اینکه خطا پرتاب کنه، یک آبجکت برمی‌گردونه که شامل success و data یا error است. اگر success برابر false بود، یعنی داده‌ها نامعتبر هستند و من خطاهای مربوطه رو استخراج کرده و با وضعیت ۴۰۰ برمی‌گردونم. اما اگر اعتبارسنجی موفق بود، ادامه کار رو انجام می‌دم.»۵. کد نهایی (اگر بخواهند دقیق بگویید)«اگر بخوام خلاصه بگم، کد نهایی من به این شکله:»typescriptimport { NextResponse } from "next/server"; import { z } from "zod"; const registerSchema = z.object({ name: z.string().min(3), email: z.string().email(), password: z.string().min(6), }); export async function POST(request: Request) { try { const body = await request.json(); const result = registerSchema.safeParse(body); if (!result.success) { return NextResponse.json( { errors: result.error.issues.map((issue) => issue.message) }, { status: 400 } ); } // اینجا منطق ذخیره‌سازی در دیتابیس // const newUser = await saveUser(result.data); return NextResponse.json( { message: "کاربر با موفقیت ثبت شد", user: result.data }, { status: 201 } ); } catch (error) { return NextResponse.json( { message: "خطای داخلی سرور" }, { status: 500 } ); } }۶. مزایایی که می‌توانید اضافه کنید (نشان دادن تسلط)«از مزایای این کار، جداسازی منطق اعتبارسنجی از منطق اصلی بیزینس است. همچنین اگر توی جای دیگری از پروژه نیاز به اعتبارسنجی مشابه داشته باشم (مثلاً توی فرم‌های کلاینت‌ساید)، می‌توانم همان اسکیما رو دوباره استفاده کنم. با این کار، هم Frontend و هم Backend من از یک قانون واحد پیروی می‌کنند و کد تمیزتر و قابل نگهداری‌تری داریم.»نکات مهم برای مصاحبه (جوری که بدرخشید)تاکید بر safeParse به جای parse: بگویید از safeParse استفاده می‌کنم چون کنترل خطا را خودم به دست می‌گیرم و سرور کرش نمی‌کند.ارسال خطاهای معنادار: به جای ارسال یک پیام کلی، خطاهای دقیق (مثلاً «ایمیل نامعتبر است») را از result.error.issues استخراج می‌کنم.یکپارچگی با TypeScript: اگر اسکیما را با z.infer استفاده کنید، تایپ خروجی هم به صورت خودکار استخراج می‌شود که نشان‌دهنده‌ی استفاده حرفه‌ای است.تفاوت NextResponse و Response معمولی: بگویید از NextResponse استفاده می‌کنم چون امکانات بیشتری مثل تنظیم cookies و headers را دارد.

راهنمای جامع مدیریت Token و Cache در Next.js 16

مصطفی رستگار — Wed, 05 Aug 2026 14:38:51 +0330

فهرست مطالبمقدمهمعماری کلیمدیریت Token با Middlewareمدیریت Cache با Next.js Cacheاجرای Refresh در Frontendنکات امنیتی و بهینهسازیجمعبندیمقدمهدر اپلیکیشنهای مدرن Next.js، مدیریت توکنهای احراز هویت و کش دادهها از چالشهای اساسی هستند. در این مقاله، یک راهحل یکپارچه برای مدیریت خودکار refresh token و کش دادهها در Next.js 16 ارائه میدهیم.پیشنیازهاآشنایی با Next.js App Routerدانش پایه از React Server Componentsآشنایی با JWT و مفاهیم احراز هویتمعماری کلیمعماری پیشنهادی شامل سه لایه اصلی است:text┌─────────────────────────────────────────────┐ │ Client Components │ │ (UI, Interactions, Refresh Button) │ └──────────────────┬──────────────────────────┘ │ ┌──────────────────▼──────────────────────────┐ │ Server Components │ │ (Data Fetching, Caching) │ └──────────────────┬──────────────────────────┘ │ ┌──────────────────▼──────────────────────────┐ │ Middleware Layer │ │ (Token Management, Authentication) │ └──────────────────┬──────────────────────────┘ │ ┌──────────────────▼──────────────────────────┐ │ External API │ │ (Backend Services) │ └─────────────────────────────────────────────┘مدیریت Token با Middleware1. ساختار Middlewaretypescript// middleware.ts import { NextResponse } from 'next/server'; import type { NextRequest } from 'next/server'; export async function middleware(request: NextRequest) { // 1. دریافت توکنها از کوکی const accessToken = request.cookies.get('access_token')?.value; const refreshToken = request.cookies.get('refresh_token')?.value; // 2. بررسی و تمدید توکن if (accessToken && await needsRefresh(accessToken)) { const newTokens = await refreshTokens(refreshToken); if (newTokens) { // 3. بهروزرسانی کوکیها و هدرها return updateRequestWithNewTokens(request, newTokens); } } // 4. ادامه درخواست با توکن موجود return addTokenToRequest(request, accessToken); } export const config = { matcher: ['/api/:path*', '/dashboard/:path*'], };2. بررسی اعتبار توکنtypescriptasync function needsRefresh(token: string): Promise { try { // دیکود کردن JWT برای بررسی زمان انقضا const payload = JSON.parse(atob(token.split('.')[1])); const expiryTime = payload.exp * 1000; const timeToExpiry = expiryTime - Date.now(); // اگر کمتر از 5 دقیقه به انقضا باقی مانده، تمدید کن return timeToExpiry < 5 * 60 * 1000; } catch { return true; // در صورت خطا، توکن را نامعتبر در نظر بگیر } }3. تمدید توکنtypescriptclass TokenManager { private static refreshPromises = new Map>(); static async refreshToken(refreshToken: string): Promise { // جلوگیری از درخواستهای همزمان if (this.refreshPromises.has(refreshToken)) { return this.refreshPromises.get(refreshToken); } const promise = this.doRefresh(refreshToken); this.refreshPromises.set(refreshToken, promise); try { return await promise; } finally { this.refreshPromises.delete(refreshToken); } } private static async doRefresh(refreshToken: string) { const response = await fetch(`${process.env.API_BASE_URL}/auth/refresh`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ refresh_token: refreshToken }), }); if (!response.ok) { throw new Error('Failed to refresh token'); } return response.json(); } }4. به روزرسانی درخواست با توکن جدیدtypescriptfunction updateRequestWithNewTokens( request: NextRequest, newTokens: { access_token: string; refresh_token: string } ) { const response = NextResponse.next(); // تنظیم کوکیهای جدید response.cookies.set('access_token', newTokens.access_token, { httpOnly: true, secure: process.env.NODE_ENV === 'production', sameSite: 'lax', maxAge: 60 * 15, // 15 دقیقه path: '/', }); // اضافه کردن توکن به هدرهای درخواست const requestHeaders = new Headers(request.headers); requestHeaders.set('Authorization', `Bearer ${newTokens.access_token}`); return NextResponse.next({ request: { headers: requestHeaders }, }); }مدیریت Cache با Next.js Cache1. کش کردن داده ها با use cachetypescript// app/dashboard/page.tsx import { cacheLife, cacheTag } from 'next/cache'; export async function getDashboardData(): Promise { 'use cache'; cacheLife('minutes'); // کش به مدت 5 دقیقه cacheTag('dashboard_data'); // تگ برای invalidate کردن const response = await fetch('API_URL/dashboard', { headers: { 'Authorization': `Bearer ${await getToken()}`, }, }); if (!response.ok) { return {} as Dashboard; } return response.json(); }2. Invalidate کردن کشtypescript// app/actions/refresh.ts 'use server'; import { revalidateTag } from 'next/cache'; export async function refreshDashboard() { 'use server'; // پاک کردن کش با تگ مشخص revalidateTag('dashboard_data'); // در صورت نیاز، revalidate مسیرهای خاص // revalidatePath('/dashboard'); return { success: true }; }3. ترکیب با Suspense برای تجربه کاربری بهترtypescript// app/dashboard/page.tsx import { Suspense } from 'react'; import { DashboardContent } from './DashboardContent'; import { DashboardSkeleton } from './DashboardSkeleton'; export default async function DashboardPage() { return ( }> ); } // app/dashboard/DashboardContent.tsx async function DashboardContent() { const data = await getDashboardData(); return ; }اجرای Refresh در Frontend1. دکمه Refresh با استفاده از Server Actionstypescript// app/dashboard/RefreshButton.tsx 'use client'; import { useTransition } from 'react'; import { useRouter } from 'next/navigation'; import { refreshDashboard } from '../actions/refresh'; interface RefreshButtonProps { className?: string; } export function RefreshButton({ className = '' }: RefreshButtonProps) { const router = useRouter(); const [isPending, startTransition] = useTransition(); const handleRefresh = () => { startTransition(async () => { // 1. پاک کردن کش await refreshDashboard(); // 2. ریفرش صفحه برای دریافت دادههای جدید router.refresh(); }); }; return ( {isPending ? ( <> Refreshing... ) : ( '🔄 Refresh' )} ); } // کامپوننت Spinner ساده function Spinner({ className = '' }) { return ( ); }2. استفاده در کامپوننت والدtypescript// app/dashboard/page.tsx import { RefreshButton } from './RefreshButton'; export default async function DashboardPage() { const data = await getDashboardData(); return (

Dashboard

); }3. دکمه Refresh در کامپوننت های تو در تواگر نیاز دارید دکمه Refresh در کامپوننتهای عمیقتر قرار گیرد، از Context استفاده کنید:typescript// app/dashboard/RefreshContext.tsx 'use client'; import { createContext, useContext, useTransition } from 'react'; import { useRouter } from 'next/navigation'; import { refreshDashboard } from '../actions/refresh'; interface RefreshContextType { refresh: () => void; isRefreshing: boolean; } const RefreshContext = createContext(undefined); export function RefreshProvider({ children }: { children: React.ReactNode }) { const router = useRouter(); const [isRefreshing, startTransition] = useTransition(); const refresh = () => { startTransition(async () => { await refreshDashboard(); router.refresh(); }); }; return ( {children} ); } export function useRefresh() { const context = useContext(RefreshContext); if (!context) { throw new Error('useRefresh must be used within RefreshProvider'); } return context; }typescript// app/dashboard/layout.tsx import { RefreshProvider } from './RefreshContext'; export default function DashboardLayout({ children, }: { children: React.ReactNode; }) { return {children}; }typescript// استفاده در هر کامپوننت عمیق 'use client'; import { useRefresh } from '../RefreshContext'; export function DeepComponent() { const { refresh, isRefreshing } = useRefresh(); return ( ); }نکات امنیتی و بهینه سازی1. تنظیمات امنیتی کوکی هاtypescriptconst cookieOptions = { httpOnly: true, // جلوگیری از دسترسی JavaScript secure: process.env.NODE_ENV === 'production', // فقط HTTPS sameSite: 'lax' as const, // جلوگیری از CSRF path: '/', maxAge: 60 * 15, // 15 دقیقه برای access token };2. Rate Limiting برای درخواست های Refreshtypescript// utils/rateLimit.ts class RateLimiter { private requests: Map = new Map(); isRateLimited(key: string, limit: number = 5, window: number = 60): boolean { const now = Date.now(); const windowStart = now - window * 1000; const timestamps = this.requests.get(key) || []; const recentRequests = timestamps.filter(t => t > windowStart); if (recentRequests.length >= limit) { return true; } recentRequests.push(now); this.requests.set(key, recentRequests); return false; } } // استفاده در middleware const rateLimiter = new RateLimiter(); if (rateLimiter.isRateLimited(request.ip || 'unknown')) { return new Response('Too many refresh requests', { status: 429 }); }3. Logging و Monitoringtypescript// utils/logger.ts export class Logger { static info(message: string, data?: any) { console.log(`[INFO] ${new Date().toISOString()} - ${message}`, data || ''); } static error(message: string, error?: any) { console.error(`[ERROR] ${new Date().toISOString()} - ${message}`, error || ''); } static warn(message: string, data?: any) { console.warn(`[WARN] ${new Date().toISOString()} - ${message}`, data || ''); } } // استفاده در middleware Logger.info('Token refresh successful', { userId: payload.sub });4. Error Handling جامعtypescript// middleware.ts async function handleRequest(request: NextRequest) { try { // پردازش اصلی return await processRequest(request); } catch (error) { if (error instanceof TokenExpiredError) { // هدایت به صفحه لاگین return NextResponse.redirect(new URL('/login', request.url)); } if (error instanceof NetworkError) { // تلاش مجدد با backoff return await retryWithBackoff(() => processRequest(request)); } // خطاهای غیرمنتظره Logger.error('Unhandled error in middleware', error); return NextResponse.next(); } }جمعبندیدر این مقاله، یک راه حل کامل برای مدیریت خودکار توکنها و کش در Next.js 16 ارائه شد:مزایای این معماری:مدیریت متمرکز Token: تمام درخواستها از middleware عبور کرده و توکن ها به صورت خودکار تمدید میشوندکش هوشمند: استفاده از use cache و revalidateTag برای بهینه سازی عملکردتجربه کاربری روان: استفاده از Suspense و Server Actions برای به روزرسانی بدون ریلودامنیت بالا: ذخیره توکنها در کوکی های httpOnly با تنظیمات امنیتی مناسبقابلیت نگهداری: کد تمیز و ماژولار با جدا بودن لایه هابهترین Practices:✅ توکنها را در کوکیهای httpOnly ذخیره کنید✅ از revalidateTag برای invalidate کردن کش استفاده کنید✅ از Suspense برای مدیریت حالتهای loading استفاده کنید✅ Rate Limiting برای جلوگیری از حملات✅ Logging مناسب برای دیباگ و مانیتورینگ✅ استفاده از TypeScript برای type safety

16- Dynamic Routes و Catch-all Routes (تأثیر بر getStaticPaths)

مصطفی رستگار — Wed, 29 Jul 2026 14:31:40 +0330

«در App Router جدید Next.js، ساختار فولدرها مستقیماً تبدیل به آدرس‌های URL می‌شوند. برای ساخت صفحات پویا (Dynamic)، از نام فولدر یا فایل با کروشه استفاده می‌کنیم. مثلاً فولدری به نام [id] یعنی هر مقداری که در آدرس بیاید، به عنوان پارامتر id در اختیار صفحه قرار می‌گیرد.حالا تفاوت Dynamic با Catch-all در این است که Dynamic فقط یک بخش از آدرس را می‌گیرد، اما Catch-all با سه نقطه (...) نوشته می‌شود و می‌تواند یک یا چند بخش از آدرس را پوشش دهد. مثلاً فولدر [...slug] یعنی هر تعداد بخش که بعد از آدرس اصلی بیاید، به صورت یک آرایه در پارامتر slug ذخیره می‌شود.تأثیر اصلی این دو بر روی getStaticPaths در زمان Build است. چون اگر می‌خواهیم این صفحات را به صورت استاتیک (Static) از پیش رندر کنیم، باید در تابع generateStaticParams (که معادل جدید getStaticPaths است) دقیقاً مشخص کنیم که چه مقادیری قرار است تولید شوند.برای Dynamic معمولی، لیستی از اشیاء با همان کلید (مثلاً { id: '1' }) برمی‌گردانیم. اما برای Catch-all، مقدار را به صورت یک آرایه در همان کلید (slug) تحویل می‌دهیم. مثلاً { slug: ['products', 'shoes', 'nike'] } یعنی آدرس /products/shoes/nike تولید می‌شود.نکته مهم این است که اگر از generateStaticParams استفاده نکنیم، Next.js این صفحات را در زمان درخواست (SSR یا ISR) رندر می‌کند و دیگر تأثیری روی Build ندارد. همچنین اگر پارامتری در generateStaticParams تعریف نشود، با استفاده از fallback: true یا 'blocking' می‌توانیم صفحات جدید را موقع بازدید کاربر بسازیم.به طور خلاصه، App Router مسیرها را ساده‌تر کرده، اما برای رندر استاتیک، ما موظفیم در generateStaticParams تمام حالت‌های ممکن Dynamic و Catch-all را مشخص کنیم تا Next.js بتواند هنگام Build، فایل‌های HTML متناظر با آن‌ها را تولید کند.»نکات کلیدی برای تسلط بیشتر (برای خودت):۱. تفاوت نحوه نوشتن:[id] → فقط یک بخش: page/[id] → آدرس: /page/5[...slug] → یک یا چند بخش: page/[...slug] → آدرس: /page/a/b/c (خواهد شد slug: ['a','b','c'])۲. نحوه نوشتن در generateStaticParams (معادل getStaticPaths):js// برای Dynamic ساده: generateStaticParams() { return [{ id: '1' }, { id: '2' }]; } // برای Catch-all: generateStaticParams() { return [ { slug: ['products', 'shoes'] }, { slug: ['blog', 'nextjs', 'tutorial'] } ]; }۳. نکته فنی:در App Router، دیگر از getStaticProps و getStaticPaths استفاده نمی‌کنیم، بلکه به جای آن‌ها از generateStaticParams و داخل خود کامپوننت از fetch یا کش استفاده می‌کنیم.۴. جمع‌بندی کاربردی:اگر تعداد صفحات محدود و مشخص است، حتماً از generateStaticParams استفاده کن تا سایتت سریع‌تر شود.اگر تعداد صفحات نامحدود یا خیلی زیاد است، از fallback: 'blocking' استفاده کن تا فقط صفحات پرطرفدار اول ساخته شوند.

14- Next.js:`App Router vs Pages Router (تفاوت و استراتژی مهاجرت)

مصطفی رستگار — Wed, 29 Jul 2026 13:46:58 +0330

۱. تعریف کلی (برای شروع):"برای اینکه صحبتم را شفاف کنم، اجازه دهید از یک مثال ساده استفاده کنم. قبلاً در Next.js (نسخه ۱۳ به پایین)، ما یک سیستم داشتیم به نام Pages Router. این سیستم مثل یک دفترچه تلفن قدیمی بود: هر فایلی که در پوشه pages می‌گذاشتیم، یک آدرس (مسیر) جدید در سایت می‌شد. اما مشکل این بود که تمام صفحات ما ایستا (Static) بودند و برای کارهای پیشرفته‌تر، مجبور بودیم کدهای پیچیده‌ای بنویسیم."۲. تفاوت اصلی (مفهوم کلیدی):"اما با آمدن App Router در نسخه ۱۳.۴ به بعد، طرز فکر ما عوض شد. تفاوت اصلی در سه بخش خلاصه می‌شود:۱. ساختار پوشه‌ها (Folder vs File): در App Router دیگر نام فایل تعیین‌کننده مسیر نیست، بلکه نام پوشه مهم است. مثلاً یک پوشه به نام dashboard با یک فایل خاص page.js داخلش، یعنی مسیر داشبورد. این اجازه می‌دهد که فایل‌های کمکی را در کنار همان صفحه قرار دهیم (مثل استایل یا کامپوننت‌های اختصاصی).۲. رندرینگ (سرویس‌دهی صفحات): اینجا مهم‌ترین تفاوت است. در Pages Router، فقط دو حالت داشتیم: استاتیک (SSG) یا سروری (SSR) در سطح کل صفحه. اما در App Router، هر بخش از صفحه می‌تواند استراتژی رندرینگ خودش را داشته باشد! یعنی می‌توانیم یک کامپوننت را داخل صفحه به صورت 'use client' (کلاینت) و کامپوننت دیگر را به صورت 'use server' (سروری) تعریف کنیم. این یعنی کنترل کامل روی عملکرد.۳. بهبود عملکرد (Performance): App Router از قابلیت جدیدی به نام Server Components استفاده می‌کند که باعث می‌شود بخش اعظم کدها در سرور اجرا شوند و حجم جاوااسکریپتی که به مرورگر کاربر می‌فرستیم، به شدت کم شود. نتیجه؟ سایت‌های بسیار سریع‌تر و سئو بهتر."۳. استراتژی مهاجرت (چطور از قدیم به جدید برویم؟):"اگر پروژه‌ای با Pages Router داریم، نباید یک‌دفعه کل پروژه را عوض کنیم. استراتژی من هوشمندانه است:قدم اول (هم‌زیستی): خوشبختانه Next.js اجازه می‌دهد که هم‌زمان از هر دو مسیریاب استفاده کنیم. یعنی می‌توانم پوشه app را کنار پوشه pages بسازم و به تدریج صفحات جدید را با App Router بنویسم.قدم دوم (اولویت با صفحات جدید): برای صفحات جدید یا صفحاتی که بیشترین بازدید را دارند و نیاز به بهینه‌سازی دارند، اولویت می‌دهم تا با معماری جدید نوشته شوند.قدم سوم (نکات فنی): در حین مهاجرت، باید دو نکته را رعایت کنم:۱. getServerSideProps یا getStaticProps دیگر وجود ندارند و باید با fetch مستقیم در کامپوننت‌های سروری جایگزین شوند.۲. فایل _app.js و _document.js حذف می‌شوند و به جای آن از layout.js ریشه‌ای و loading.js برای نمایش بارگذاری استفاده می‌کنم."۴. جمع‌بندی نهایی (نتیجه‌گیری):"در یک جمله، App Router فقط یک آپدیت ساده نیست؛ بلکه یک تغییر پارادایم از Page-based به Component-based است. با این کار، توسعه‌دهنده قدرت بیشتری برای بهینه‌سازی دارد و کاربر نهایی سایتی بسیار سریع‌تر و روان‌تر تجربه می‌کند. من برای پروژه‌های جدید حتماً از App Router شروع می‌کنم و برای پروژه‌های قدیمی، مهاجرت تدریجی و هوشمندانه را در پیش می‌گیرم."نکات طلایی برای مصاحبه (که در متن بالا گنجانده شده):به جای گفتن "فرق در فایل است"، بگویید "از File-based به Folder-based".حتماً به Server Components اشاره کنید (چون نشان می‌دهد به‌روز هستید).نگویید "همه چیز را عوض می‌کنیم"، بگویید "مهاجرت تدریجی" برای نشان دادن مدیریت ریسک.

13- Middleware در Next.js (مقایسه با Express.js middleware)

مصطفی رستگار — Wed, 29 Jul 2026 13:41:13 +0330

Middleware در Next.js چیست؟Middleware در Next.js یک تابع است که قبل از کامل شدن درخواست (Request) اجرا می‌شود. یعنی بین لحظه‌ای که کاربر درخواست می‌دهد و زمانی که صفحه یا پاسخ نهایی نمایش داده می‌شود، یک لایه میانی قرار دارد که می‌توانیم در آن منطق خود را اجرا کنیم.این Middleware در پوشه‌ی ریشه پروژه، در فایل middleware.ts قرار می‌گیرد و به طور پیش‌فرض روی همه‌ی مسیرها اجرا می‌شود، مگر اینکه با استفاده از matcher بعضی مسیرها را حذف یا محدود کنیم.کاربردهای اصلی Middleware در Next.js:احراز هویت (Authentication): مثلاً اگر کاربر لاگین نکرده باشد، او را به صفحه‌ی ورود هدایت کنیم.مدیریت مسیرها (Routing): تغییر مسیر بر اساس موقعیت جغرافیایی یا نوع دستگاه (موبایل/دسکتاپ).تنظیم هدرها (Headers): افزودن هدرهای امنیتی یا کش به پاسخ.لاگ‌گیری (Logging): ثبت اطلاعات درخواست‌ها برای تحلیل.تفاوت Middleware در Next.js با Express.jsاین سؤال خیلی رایج است. تفاوت‌های اصلی را در چند نقطه خلاصه می‌کنم:یک مثال ساده از Middleware در Next.js:typescript// middleware.ts import { NextResponse } from 'next/server'; import type { NextRequest } from 'next/server'; export function middleware(request: NextRequest) { // اگر کاربر توکن احراز هویت نداشت، به لاگین ببر const token = request.cookies.get('token'); if (!token && request.nextUrl.pathname.startsWith('/dashboard')) { return NextResponse.redirect(new URL('/login', request.url)); } // ادامه‌ی مسیر return NextResponse.next(); } // فقط روی مسیرهای dashboard اجرا کن export const config = { matcher: '/dashboard/:path*', };خلاصه‌ی نهایی برای مصاحبه:Middleware در Next.js یک لایه میانی در لبه (Edge) است که قبل از نمایش هر صفحه اجرا می‌شود و برای کنترل دسترسی، تغییر مسیر، و مدیریت درخواست‌ها استفاده می‌شود. برخلاف Express.js که Middleware‌ها روی سرور Node.js اجرا می‌شوند و انعطاف بیشتری در پاسخ‌دهی دارند، Middleware Next.js سریع‌تر و سبک‌تر است و بیشتر روی مسیردهی و امنیت تمرکز دارد.