نوشته های فرشید کریمی

تست‌نویسی در javascript/typescript — بخش ۳: تکنیک‌های پیشرفته تست واحد

فرشید کریمی — Thu, 19 Feb 2026 06:36:57 +0330

در مقاله قبلی، با مبانی تست واحد و TDD آشنا شدیم. در این مقاله تکنیک‌های پیشرفته تست نویسی واحد رو با هم بررسی می‌کنیم. در این مقاله، ابزارهای قدرتمندی رو یاد می‌گیریم که به ما کمک می‌کنن تست‌های حرفه‌ای‌تر و انعطاف‌پذیر‌تری بنویسیم.تساوی مرجعی و ساختاری (Referential vs Structural Equality)توی جاوااسکریپت (و قطعا تایپ‌اسکریپت)، تفاوت بین toBe و toEqual بسیار مهمه و انتخاب نادرست، می‌تونه به تست‌های اشتباه و گمراه‌کننده منجر بشه. داستان به این حقیقت برمی‌گرده که دو متغیر از نوع ‌reference در جاوااسکریپت، اگر رفرنس مشترکی نداشته باشند، حتی اگرمقادیر کاملا یکسانی داشته باشند، باز هم با هم مساوی نیستند. مثال:let a = { x:1 }; let b = { x:1 }; console.log(a===b); // false استفاده از toBe (مقایسه مرجعی)متد toBe برای مقایسه مرجعی استفاده می‌شه و مشابه === یا ()Object.is عمل می‌کنه:test('strings should be strictly equal', () => { expect('string').toBe('string'); }); test('numbers should be strictly equal', () => { expect(2).toBe(2); }); test('booleans should be strictly equal', () => { expect(true).toBe(true); expect(false).toBe(false); }); test('undefined and null should be strictly equal to themselves', () => { expect(undefined).toBe(undefined); expect(null).toBe(null); }); همه تست‌های فوق پاس میشن، اما وقتی به سراغ اشیا و آرایه‌ها می‌ریم، مشکلاتی پیش میاد:test.fails('objects should not be strictly equal', () => { expect({ a: 1 }).toBe({ a: 1 }); // it fails! }); test.fails('arrays should not be strictly equal', () => { expect([1, 2, 3]).toBe([1, 2, 3]); // it fails! }); test.fails('functions should not be strictly equal', () => { expect(() => {}).toBe(() => {}); // it fails! }); پس می‌بینیم که استفاده از toBe در چنین مواردی راهکار درستی نیست و باید سراغ toEqual رفت.استفاده از toEqual (مقایسه ساختاری)متد toEqual برای مقایسه ساختاری استفاده می‌شه و به صورت shallow مقادیر رو بررسی می‌کنه:test('objects with the same properties are equal', () => { expect({ a: 1, b: 2 }).toEqual({ a: 1, b: 2 }); }); test('arrays should be equal', () => { expect([1, 2, 3]).toEqual([1, 2, 3]); }); test('nested objects should be equal', () => { expect({ a: 1, b: { c: 2 } }).toEqual({ a: 1, b: { c: 2 } }); }); test('multi-dimensional arrays should be equal', () => { expect([1, [2, 3]]).toEqual([1, [2, 3]]); }); حالا تمامی تست های فوق به درستی پاس می شوند.تفاوت toEqual و toStrictEqualمتد toStrictEqual نسخه سفت‌وسخت‌تری از toEqual هست:class Person { constructor(name) { this.name = name; } } test('objects with undefined properties are equal to objects without those properties', () => { expect({ a: 1 }).toEqual({ a: 1, b: undefined }); // ✅ موفق می‌شه }); test('objects with undefined properties are NOT strictly equal to objects without those properties', () => { expect({ a: 1 }).not.toStrictEqual({ a: 1, b: undefined }); // ✅ موفق می‌شه }); test('instances are equal to object literals with the same properties', () => { expect(new Person('Alice')).toEqual({ name: 'Alice' }); // ✅ موفق می‌شه }); test('instances are NOT strictly equal to object literals with the same properties', () => { expect(new Person('Alice')).not.toStrictEqual({ name: 'Alice' }); // ✅ موفق می‌شه }); دقت کنید که در تست‌های فوق با not عدم تساوی رو بررسی کردیم.کدام روش رو انتخاب کنیم؟متد toBe: وقتی می‌خوایم مطمئن بشیم دو متغیر به یک شیء اشاره می‌کننمتد toEqual: وقتی می‌خوایم مطمئن بشیم دو شیء محتوای یکسانی دارن (معمولاً اینو می‌خوایم)متد toStrictEqual: وقتی می‌خوایم نسبت به toEqual دقیقتر باشیم و undefinedها و انواع شیء رو هم بررسی کنیممثال عملی با کلاس‌هااگر بخواهیم یک مثال از مفهوم تساوی اینبار در ساختار کلاسی بزنیم، بدین صورت میشه.class Calculator { constructor() { this.result = 0; this.history = []; } add(num) { this.result += num; this.history.push(`+${num}`); return this; } subtract(num) { this.result -= num; this.history.push(`-${num}`); return this; } } حالا تستش:test('calculator should work correctly', () => { const calc = new Calculator(); calc.add(5).subtract(2); expect(calc).not.toBe(new Calculator()); // it fails! expect(calc).toEqual({ result: 3, history: ['+5', '-2'] }); // it success! }); همسان‌یابی نامتقارن (Asymmetric Matchers)همسان‌یابی نامتقارن بدون شک یکی از قدرتمندترین ابزارهای تست نویسیه. matcher ها به ما اجازه می‌دن فقط قسمت‌هایی از داده‌ها رو تست کنیم که واقعاً مهم هستن و بقیه رو نادیده بگیریم. این کار باعث می‌شه تست‌هامون انعطاف‌پذیرتر و مقاوم‌تر نسبت به تغییرات غیرضروری بشن.چرا از همسان‌یابی نامتقارن استفاده کنیم؟تصور کنید یه API داریم که اطلاعات کاربر رو برمی‌گردونه:{ id: "user-123", name: "John Doe", email: "john@example.com", createdAt: "2024-01-15T10:30:00Z", lastLogin: "2024-01-20T15:45:00Z", settings: { theme: "dark", notifications: true } } اگه بخوایم این رو با toEqual تست کنیم، باید همه فیلدها رو دقیق مشخص کنیم. این کار تست رو خیلی سفت می‌کنه و با هر تغییر کوچیک (مثلاً تغییر timestamp)، تست fail میشه.همسان‌یابی نامتقارن به ما اجازه می‌دن فقط روی چیزایی تمرکز کنیم که واقعاً برامون مهم هستن.مشاهده مقاله کامل در این آدرس:https://farshidev.ir/Post/%D8%AA%D8%B3%D8%AA%E2%80%8C%D9%86%D9%88%DB%8C%D8%B3%DB%8C-javascript-typescript-unit-test-advancedموفق باشید.

تست‌نویسی در javascript/typescript — بخش ۲: تست واحد یا unit test

فرشید کریمی — Thu, 19 Feb 2026 06:34:50 +0330

در این مقاله، قصد داریم وارد دنیای تست واحد (Unit Testing) بشیم. تست واحد یکی از پایهایترین و مهمترین انواع تستهای نرمافزاریه که در اون فقط یک واحد کوچیک از کد (معمولاً یک تابع یا متد) به صورت ایزوله تست میشه.تست واحد به ما کمک میکنه تا:خطاهای اولیه رو سریع شناسایی کنیمتغییرات ایمن داشته باشیم، یعنی وقتی کدمون رو میخواهیم تغییر بدیم، دست و دلمون نلرزه که چندجای دیگه بترکه!اعتماد به نفس بیشتری در ریلیز کردن نسخهها داشته باشیمتوسعه مبتنی بر تست (Test-Driven Development - TDD)قبل از اینکه وارد نوشتن تستها بشیم، واسه اینکه تاکید کنم، تست نوشتن چقدر می تونه مهم باشه باید بگم اصلا ما یک متدولوژی توسعه داریم که برمبنای تست نویسیه و اسمش توسعه مبتنی بر تست یا TDD عه.توی متدولوژی TDD ما اول تست مینویسیم، بعد کد. درباره اینکه چه موقعیه اوکیه این متدولوژی رو استفاده کنیم و چه موقع foul عه بعدا صحبت می کنیم ولی اول بذارید توضیح بدم که چقدر بامزه است، توسعه این سبکی!چرخه Red-Green-Refactorمتدولوژی TDD رو اینجوری پیاده میکنند:قرمز (Red): اول یک تست برای تیکه کدمون مینویسیم که شکست میخورهسبز (Green): حداقل کد ممکن رو مینویسیم تا تست موفق بشهبازنگری (Refactor): کد رو بهبود میدیم بدون اینکه تستها شکست بخورنمثال عملی TDDفرض کنید میخوایم یک تابع برای محاسبه فاکتوریل بنویسیم. دقت کنید ما تابع factorial رو هنوز ننوشتیم و تازه میخواهیم شروع کنیم به نوشتنش. متد TDD به ما میگه اول تستش رو خرد خرد بنویس تا به خودش برسی!مرحله ۱: قرمز (نوشتن تست شکست خورده)اول تست رو مینویسیم: (فعلا بیخیال syntax اش، میگیم جلوتر چیه داستانش!)describe('factorial', () => { it('should calculate factorial of 5', () => { expect(factorial(5)).toBe(120); }); }); این تست حتماً شکست میخوره چون تابع factorial هنوز وجود نداره!مرحله ۲: سبز (نوشتن حداقل کد برای موفقیت)حالا حداقل کد ممکن رو مینویسیم:export const factorial = (n) => { return 120; }; تست موفق میشه! ولی این کد قاعدتا درست نیست.مرحله ۳: بازنگری (افزایش تستها و بهبود کد)حالا تستهای بیشتری اضافه میکنیم:describe('factorial', () => { it('should calculate factorial of 0', () => { expect(factorial(0)).toBe(1); }); it('should calculate factorial of 1', () => { expect(factorial(1)).toBe(1); }); it('should calculate factorial of 5', () => { expect(factorial(5)).toBe(120); }); }); حالا برای پاس شدن تستها، کد رو بهبود میدیم:export const factorial = (n) => { if (n === 0 || n === 1) { return 1; } return n * factorial(n - 1); }; مزایای TDDکیفیت بالاتر: کدی که با TDD نوشته میشه معمولاً باگ کمتری دارهطراحی بهتر: TDD به شما کمک میکنه APIهای بهتری طراحی کنیداعتماد به نفس بیشتر: با تستهای جامع، جرئت تغییر و بهبود کد رو داریدمستندسازی: تستها به عنوان مستندات اجرایی عمل میکننمعایب و چالشهای TDDزمان بیشتر: اول امر زمان بیشتری میبرهمنحنی یادگیری شیب دار: یادگیری TDD نیاز به تمرین دارهبرای همه چیز مناسب نیست: نوشتن تست با این روش، برای بعضی از قسمتهای کد (مثل UI) مناسب نیست.به عنوان یه rule of thumb اگر بخام بگم، تست TDD رو زمانی بنویسید که میدونید برای هر ورودی دقیقا چه خروجی قابل انتظار است، مثلا در validation ها یا state machine ها یا توابع ریاضی.حالا که با TDD آشنا شدیم، بیاید وارد نوشتن اولین تستهامون بشیم!شروع به نوشتن تستهاخب اول از همه اگر پروژه ندارید یه پروژه با روال زیر بسازید و dependency ها رو نصب کنید. اگرم در حال حاضر هر نوع پروژه JavaScript یا typescript دارید، کافیه فقط dependency رو نصبش کنید.npm init -y npm install -D vitest حالا فایل زیر رو با عنوان helloWorld.test.ts مثلا ذخیره کنید.import { test, expect } from 'vitest'; test('is a super simple test', () => { expect(true).toBe(true); }); میتونید این تست رو با اجرای npx vitest از خط فرمان اجرا کنید و میبینید که تست پاس میشه. اگر بخوام این فایل رو توضیح بدم:یه تابع به نام test وجود داره که دو تا آرگومان میگیره: 1. یه رشته که نام تست رو نشون میده 2. یه تابع که بدنه تست رو شامل میشهداخل اون تابع، از یه کتابخونه assert برای بیان انتظاراتمون استفاده میکنیم 1. در اینجا، انتظار داریم این دو تا چیز با هم برابر باشن 2. و اونها هستن!یک مثال دیگهحالا بیاید یه مثال واقعیتر بررسی کنیم:test('another test, but with some logic', () => { expect(1 + 1).toBe(2); }); test('a test with a function', () => { const add = (a, b) => a + b; expect(add(1, 2)).toBe(3); }); نکته مهم اینه که، وقتی یک تست مثل فایل بالا مینویسیم، میتونیم (نه اینکه باید!) هر تعداد خواستیم از این (...)test ها داشته باشیم . اینجوری میتونیم مطمئن بشیم هر سناریویی رو پوشش دادیم. وظیفه تست runner (در اینجا npx vitest) اینه که تست ما رو اجرا کنه و مطمئن بشه که همه چیز درست کار میکنه.نحوه کار تستهایه تست فقط به خاطر اینکه شکست نخورده، قبول میشه.این به این معنیه که اگه یه تست شکست بخوره، یعنی یه error انداخته شده. پس وقتی میگیم تست قبول شده، یعنی هیچ errorای ننداخته!تستی که انتظار داریم شکست بخوره با test.failمیتونیم از .test.fails برای تستهایی استفاده کنیم که انتظار داریم شکست بخورن:test.fails('works with "test" as well', () => { expect(true).toBe(false); }); این مثال ساده نشون میده که چطور میتونیم تستهایی بنویسیم که انتظار داریم شکست بخورن.نادیده گرفتن تست با it.skipاگر میخواید یه تست خاص رو موقتاً اجرا نکنید (مثلاً در حال کار روی اون بخش هستید یا تست مشکل داره):it.skip('this test is temporarily disabled', () => { expect(someFunction()).toBe('expected result'); }); اجرای فقط یه تست با it.onlyاگر میخواید فقط یه تست خاص رو اجرا کنید و بقیه تستها رو نادیده بگیرید (مثلاً وقتی روی یه بخش خاص کار میکنید و میخواید فقط تست مربوط به اون بخش رو ببینید):it.only('this is the only test that will run', () => { expect(add(2, 3)).toBe(5); }); به جای test در vitest میشه it هم نوشت و فرقی ندارند و به کرات به جای هم استفاده میشن، فلذا گیج نشید!تست کد Asyncخب فرض کنیم یه کد async رو بخواهیم تست کنیم. تست زیر به اشتباه قبول میشه، چون تابع بالادست setTimeout یه تابع سنکرونه و منتظر resolve این تایم اوت و رسیدن به assertion نمیشه. (رجوع به مفاهیم async)it('it will pass, unfortunately', () => { setTimeout(() => { expect('This should fail.').toBe('Totally not the same.'); }, 1000); }); خب راه حلش اینه که به سادگی از async/await استفاده کنیم:test('works with "test" as well', async () => { const result = await addAsync(2, 3); expect(result).toBe(5); }); مشاهده مقاله کامل در این آدرس:https://farshidev.ir/Post/%D8%AA%D8%B3%D8%AA%E2%80%8C%D9%86%D9%88%DB%8C%D8%B3%DB%8C-javascript-typescript-unit-testموفق باشید.

تست‌نویسی در javascript/typescript — بخش ۱: مقدمات

فرشید کریمی — Thu, 19 Feb 2026 06:31:51 +0330

لازمه یه توسعه مسئولیت پذیرانه، نوشتن تسته. تست کردن، اعتماد به نفس ما رو در مورد عملکرد مورد انتظار برنامه‌مون افزایش می‌ده. توی این سری قصد داریم راجع به اصول نوشتن تست کارآمد و لایه های مختلفش صحبت کنیم.مقدمهتست کردن فقط برای پیدا کردن باگ نیست. بلکه تست نوشتن به ما کمک می‌کنه که کد بهتری بنویسیم. وقتی برای تست نوشتن پلن داریم، مجبوریم کدی بنویسیم که سازمان‌یافته‌تر و قابل‌استفاده‌تر باشد. این یه فرآیند دو‌طرفه است:کد خوب <------------------> تست خوبچرا تست نویسی مهمه؟اعتماد به نفس: با تست‌های جامع، جرئت تغییر و بهبود کد رو داریدکیفیت کد: تست‌ها به بهبود کیفیت کد و طراحی کمک می‌کننمستندسازی: تست‌ها به عنوان مستندات اجرایی عمل می‌کننrefactoring ایمن: با تست‌های مناسب می‌تونید کد رو重构 کنید بدون ترس از شکستن ویژگی‌هاکاهش باگ: تست‌ها به شناسایی و جلوگیری از باگ‌ها کمک می‌کننچالش‌های پیش رومنحنی یادگیری: تست نویسی نیاز به تمرین و تجربه دارهزمان و هزینه: نوشتن تست زمان و هزینه داره، اما سرمایه‌گذاری ارزشمندیهنگهداری تست‌ها: با تغییر کد، تست‌ها هم نیاز به به روز رسانی دارنتعادل: باید تعادل بین نوشتن تست و توسعه ویژگی‌ها برقرار کردروش‌های تستما در این سری، سه متد رایج تست رو بررسی خواهیم کرد:تست واحد (unit test)تست یکپارچگی (integration test)تست نهایی (e2e test)تست واحد (Unit Test)تست واحد، کوچک‌ترین قسمت برنامه‌مون رو تست می‌کنه. یه تابع یا متد را به طور ایزوله بررسی می‌کنیم که انتظار داریم چطوری کار کنه. عموما این نوع تست‌ها سریع و جمع‌وجور هستند.تست یکپارچگی (Integration Test)تست یکپارچگی، چند تا از قسمت های برنامه‌مون رو با هم تست می‌کنه. مثلاً فرض کنید یه بخش از برنامه‌ ما یه API صدا می‌زنه و نتیجه رو پردازش می‌کنه و یا چندتا هوک و کامپوننت react ای در یک کامپوننت رو شبیه‌سازی می‌کنیم تا از عملکردشون کنار هم مطمئن بشیم.تست نهایی (E2E Test)تست نهایی (end-to-end)، کل برنامه‌ رو از دید کاربر نهایی تست می‌کنه. یعنی ما شبیه‌سازی می‌کنیم که کاربر چطور با برنامه‌مون تعامل داره. مثلاً کاربر روی دکمه‌ای کلیک می‌کنه، فرم رو پر می‌کنه و نتیجه رو می‌بینه.پیش از شروعابزارهای استفاده‌شدهدر این سری از ابزارهای شناخته‌شده، به‌روز و پرکاربرد استفاده خواهیم کرد:Vitest - یه گزینه مدرن و سریع برای تست unit و integration و جایگزین JestTesting Library - یه کتابخونه با کلی ابزار مفید برای تست DOMJSDOM یا HappyDom - یه کتابخونه سریع برای شبیه‌سازی محیط ‌DOM در nodePlaywright - برای تست E2Eراجع به اینکه کدوم ابزار رو کی استفاده می‌کنیم در بخش های مربوطه توضیح می‌دیم.پیش‌نیازهاآشنایی اولیه با javascript یا typescriptآشنایی با git, npm و node

استفاده از zustand برای بهبود مدیریت state ها

فرشید کریمی — Thu, 19 Feb 2026 06:26:18 +0330

وقتی صحبت از مدیریت stateها در اپلیکیشنهای react ای میشه نمیشه یه نسخه برای همه اپلیکیشنها پیچید، بعضی وقت ها stick شدن به همون امکانات react مثل Context API جوابه و بعضی وقتها نیاز به کتابخونه هایی مجزا برای مدیریت stateها داریم.درباره اینکه استراتژی مناسب برای هر موضوع چیه، امیدوارم بتونیم توی یه پست مجزا راجع بهش صحبت کنیم. به عنوان یه rule of thumb باید بگم که این دو نکته می تونه به شما بگه شاید وقتش باشه که به یک کتابخونه مدیریت state مجزا فکر کنید.تعداد زیاد state ها در Context APIنرخ بالای بروزرسانی state ها در کامپوننتالبته core react دائما در حال توسعه است و مواردی مثل react compiler می تونه تا حدودی شرایط رو تغییر بده.حالا بریم سر داستان خودمون. zustand قطعا توی دسته کتابخونه های مجزا از core react برای مدیریت stateها قرار می گیره. کار با zustand خیلی راحت و مشابه react عه، اول از همه بگذارید راجع به فلسفه کارکردی zustand یکم صحبت کنیم و اینکه چجوری داره کار میکنه.فلسفه عملکردی zustandوقتی شما با zustand یک store در جایی می سازی در حقیقت در run-time جاوااسکریپت یه محدوده ای میسازی که داخلش چیزهایی که میخوای رو ذخیره میکنی.اول بگم lifecycle این store در وهله اول کاملا به run-time مرورگر شما بستگی داره یعنی اگر صفحه مرورگر رو reload کنید قاعدتا این store پاک میشه مگر اینکه جای دیگه ای هم persist بشه که موضوع بحث ما فعلا نیست. همونطور که توی شکل بالام مشخصه اپلیکیشن شما هر حرکتی بزنه دخلی(!) به این store به طور معمول نداره چون space یا فضای حافظه و run-time شون جداست.حالا از این ببعدش جالب میشه، شما وقتی zustand رو به طور مثال در برنامه react تون استفاده میکنید یه wrapper ای از جنس stateهای react دورش ایجاد میشه که فرآیندهای آپدیت و rendering در react بدین وسیله handle میشه.شکل زیر تقریبی از چیزی است که اتفاق میافته. به عبارتی برای اینکه react برای این که بتونه فرآیندهای rendering رو برعهده بگیره نیاز به چیزی داره که براش معنا و مفهوم داشته باشه که همون stateهاست. حالا ما هربار که useStore رو استفاده کنیم(بعدا خواهیم گفت)، در حقیقت کنترل re-render و render رو برعهده میگیریم.اولین گام zustand - ساخت storeدر کتابخونه zustand برای ساختن state کافیه متد create رو صدا بزنید:import { create } from "zustand"; حالا store رو populate میکنیم:export const useTasksStore = create((set) => ({ tasks, setTasks: (arg: Task[] | ((tasks: Task[]) => Task[])) => { set((state) => { return { tasks: typeof arg === "function" ? arg(state.tasks) : arg, }; }); }, currentView: "list", setCurrentView: (newView: TasksView) => set({ currentView: newView }), currentFilter: "", setCurrentFilter: (newFilter: string) => set({ currentFilter: newFilter }), })); همونطور که میبینید تابع create یه تابع به عنوان آرگومان خودش میگیره. این تابع یک خودش یه آرگومان به نام set داره که میتونیم ازش برای مقداردهی موارد داخل store مون استفاده کنیم. (آرگومان get هم داره که بعدا میگیم به چه دردی میخوره)طبعا ما می تونیم state ها رو به صورت پیچیده تری آپدیت کنیم و دستمون بازه اینجا. به این سبک partial update هم میگن.setCurrentView: (newView: TasksView) => set({ currentView: newView, tasks: [] }), همچنین تابع بالا یه آرگومان دوم هم می گیره که باهاش می تونیم کل store رو replace کنیم، مثلا در مثال زیر store مون رو می تونیم با clear ریست کنیم. البته در استفاده ازش با دقت عمل کنید چون می تونه کل store تون رو wipe کنه.const initialState = { user: null, loggedIn: false, }; const useStore = create((set) => ({ ...initialState, clear: () => set(initialState, true), })); خب حالا بریم این custom hook ای که ساختیم رو استفاده کنیم. منظورم همین store هست که با useStore ایجاد شده است.برای این کار روش های متنوعی وجود داره و خیلی راحت میتونید انتخاب اشتباهی رو صورت بدید و اوضاع رو خرابش کنید. ما در ادامه خیلی گاماس گاماس با هم پیش میریم تا معایب و مزایای هر روش رو به خوبی خودتون متوجه بشید.استفاده از zustand در کامپوننتاستفاده از الگوی atmoic تا ابد!استفاده از zustand بدین شکل که state ها رو در متغیرهای مجزا استخراج کنیم(atomic pattern)، همیشه جوابه و توصیه خود zustand هم در غالب مواقع همین روشه.const currentView = useTasksStore(state => state.currentView); const tasks = useTasksStore(state => state.tasks); const currentFilter = useTasksStore(state => state.currentFilter); همونطور که واضحه در این حالت و هربار باید explictly بگیم چی ها رو می خواهیم. یعنی باید از selector استفاده کنیم، مشابه اونچه در غالب state manager ها مثل redux هم داشتیم.اینجوری دقیقا میگیم چیارو می خواهیم و فقط state مربوط به همونا میاد توی کامپوننت مون و هربار که فقط این state عوض بشه کامپوننت ما rerender میشه. یعنی میشه با تقریبی اینو معادل این دونست برای درک بهتر وگرنه در واقعیت کمی پیچیده ترهconst [currentFilter] = useState({"Current State's Value in the Store"}); . . خب دیگه حالا هرچی توی store عوض بشه تا وقتی currentFilter عوض نشه این state موجبات rerender کامپوننت مون رو فراهم نمی کنه و این درسته!خواندن store به صورت گرتره ایمی تونیم به روش زیر state مون رو از store بخونیم که خب اتفاقا کار هم می کنه.const { currentFilter } = useTasksStore(); در این خط، کتابخونه zustand به طور پیشفرض در جواب useTasksStore کل store رو برمی گردونه که در واقع اگر به فلسفه zustand برگردیم یعنی stateهای کل store در این کامپوننت قرار داده میشن و این یعنی اگر هرکدوم از اون state ها آپدیت بشن این کامپوننت rerender خواهد شد. دقت کنید در این مورد object destructring هم با این که انجام شده ولی تاثیری نداره.این اتفاق شبیه همون چیزی که توی Context API خود react رخ میده، فلذا اینگونه استفاده با هدف zustand در غالب مواقع همخوانی نداره.خب تا همینجا کافیه که بتونید توی کامپوننتهاتون از zustand استفاده کنید و کنترل rendering رو راحتتر داشته باشید. از اینجا ببعد ما به این میپردازیم که چگونه از zustand به صورت هوشمندانهتری استفاده کنیم و اینم یادتون نره که هرجا شک کردید که کدوم راه درستتره just stick to atomic pattern که همیشه جوابه!استفاده از zustand طبیعتا هیچ محدودیتی در عدم استفاده از کتابخونههای دیگه مدیریت state برای شما ایجاد نمی کنه و می تونید توی یه پروژه redux ای یا با context API به کارش بگیرید، اگر لازم بود.در پایان این بخش اگر بخواهیم به صورت مرحله به مرحله آن چه در selectorهای zustand اتفاق میفته رو بگیم، این میشه:با هر selector در حقیقت zustand اون کامپوننت رو در store خبردار یا subscriber قرار میدهکه این یعنی با هر set در store:کتابخانه zustand میاد selector رو اجرا میکنهمقدار قبلی حاصل از برآورد این selector با مقدار حاصل از بخش یک مقایسه میشهاگر تغییری رخ داده بود، کامپوننت re-render میشهاگرم رخ نداده بود که هیچی به هیچی!استفاده هوشمندانه تر از zustandاول از همه با یه مثال react ای بگم چه مواقع الگوی atomic کد مارو یه جوری میکنه!import { create } from "zustand"; type State = { count: number; user: { name: string; email: string }; increment: () => void; }; export const useTestStore = create((set) => ({ count: 0, views: 1, user: { name: "Marco", email: "marco@example.com" }, increment: () => set((state) => ({ count: state.count + 1 })), })); حالا استفاده ازشimport { useTestStore } from './store' export default function Example1() { const user = useTestStore(state => state.user) const count = useTestStore(state => state.count) const increment = useTestStore(state => state.increment) return (

Count: {count}

) } همانطور که می بینید اگر تعداد بیشتری state داشته باشیم یه جورایی کلی باید چیز تکراری و boilerplate بنویسیم. آیا راه بهتری هم هست؟ بله!import { useTestStore } from './store' export default function Example1() { const { user, count, increment } = useTestStore((state) => ({ user: state.user, count: state.count, increment: state.increment, })); return (

Count: {count}

) } گیرش کجاست؟ فرض کنید در یک کامپوننت دیگه داشته باشیم.import { useTestStore } from './store' export default function Example2() { const {user, views} = useTestStore(state => ({views:state.views, user:state.user})) return (

{user}

User views: {views}

) } حالا اگر به طور مثال از increment در Example1 استفاده کنیم یعنی روی button کلیک کنیم، این خط (سلکتور) یکبار دیگر اجرا خواهد شد تا از تغییرات احتمالی مطلع شود. (بالاتر گفته بودیم که هر selector یک subscriber است)const { user, views } = useTestStore((state) => ({ views: state.views, user: state.user, })); طبق تعریف increment، فقط count در store عوض میشود. سپس این خط یکبار دیگر ارزیابی شده و آبجکت دیگری دقیقا با همین مقادیر تولید خواهد کرد(چون چیزی عوض نشده است). حالا چون دو آبجکت رفرنس یکسانی ندارد، در نتیجه این کامپوننت بیخودی رندر مجدد می شود.برای حل این مشکل باید یه جوری به zustand بگیم که آقا ما نمی خواهیم دو تا آبجکت رو با هم از نظر رفرنس مقایسه کنی و فقط همین که مقادیرش عوض بشه برامون مهمه. برای این کار از مفهوم shallow استفاده می کنیم.مشاهده مقاله کامل در این آدرس:https://farshidev.ir/Post/%E2%80%8Czustand-react-smart-state-managmentموفق باشید.

Layers و Stacking Context چی هستند و چجوری می‌تونن Performance سایت‌مون رو بهتر کنند؟

فرشید کریمی — Thu, 19 Feb 2026 06:18:18 +0330

مقدمهدو مفهوم Stacking context و Layers در فرآیند تبدیل کدهای ما به صفحات وب در مرورگر معنا پیدا می‌کنند. این دو مفهوم خیلی شبیه هم هستند و حتی بعضی جاها اشتباها به جای هم به کار میرن اما تفاوت دارند. دونستن این تفاوت بهمون کمک می‌کنه که CSS ای بنویسیم که به سایت با کیفیت‌تری منتج بشه!از اونجایی که گفتم فرآیند تبدیل کد ما به صفحات وب، لازمه تا یک بار این فرآیند رو مرور کنیم و اختصارا بگیم که این دو مفهوم در کدوم لایه از این فرآیند خودشون رو نشون می‌دن.فرآیند رندرینگ مرورگروقتی یه صفحه وب رو باز می‌کنید، مرورگر چند مرحله اصلی رو طی می‌کنه تا کدهای شما رو به یه صفحه قابل مشاهده تبدیل کنه:۱. ساخت DOM (Document Object Model)وقتی مرورگر کدهای HTML شما رو می‌خونه، یه ساختار درختی به نام DOM می‌سازه. این درخت شامل تمام المان‌های HTML صفحه شما می‌شه، از تا آخرین

یا . هر المان یه node در این درخت محسوب می‌شه.۲. ساخت CSSDOM (CSS Object Model)همزمان با ساخت DOM، مرورگر کدهای CSS رو هم پردازش می‌کنه و یه ساختار درختی دیگه به نام CSSDOM می‌سازه. این درخت شامل تمام استایل‌ها و قوانین CSS می‌شه که مشخص می‌کنه هر المان چجوری باید نمایش داده بشه.۳. ترکیب DOM و CSSDOM - درخت رندر (Render Tree)بعد از ساخت DOM و CSSDOM، مرورگر این دو درخت رو با هم ترکیب می‌کنه و یه درخت رندر ایجاد می‌کنه. این درخت فقط شامل المان‌هایی می‌شه که قابل نمایش هستند (مثلا المان‌های با display: none در این درخت وجود ندارند).۴. محاسبه Layout (Reflow)در این مرحله، مرورگر موقعیت و اندازه دقیق هر المان رو در صفحه محاسبه می‌کنه. این فرآیند به عنوان reflow یا layout شناخته می‌شه. مرورگر از اطلاعات درخت رندر استفاده می‌کنه تا بفهمه هر المان کجا باید قرار بگیره و چقدر فضا اشغال کنه.۵. Paint (رنگ‌آمیزی)بعد از اینکه موقعیت و اندازه المان‌ها مشخص شد، مرورگر شروع می‌کنه به رنگ‌آمیزی یا paint کردن المان‌ها. در این مرحله، رنگ‌ها، تصاویر، متن‌ها و سایر ویژگی‌های بصری روی صفحه کشیده می‌شن.۶. Composition (ترکیب لایه‌ها)در مرحله آخر، مرورگر لایه‌های مختلف رو با هم ترکیب می‌کنه تا صفحه نهایی رو نمایش بده.توصیه می‌کنم یه بار به این مقاله در وبسایت کروم مراجعه کنید. چون داخلش این فرآیند رو به شکل تصویری خیلی خوب نشون داده.نکات مهماز بین مراحل فوق، همگی به جز Compostion کاملا در CPU انجام می ‌شوند.امور مربوط به ایجاد Stacking Context در بخش Paint رخ می‌دهد. (جلوتر می‌رسیم)امور مربوط به Layers (جلوتر می‌رسیم که چی هستن) در بخش Composition رخ می دهد. (عمدتا در GPU)زمانبر ترین بخش این فرآیندها، بخش Layout یا Reflow است، چون باید x,y یک المان یا مختصاتش رو CPU دربیاره و برای این فرآیند باید تمام المان‌های توی صفحه رو درنظر بگیره.ذکر این نکته هم لازمه که، چنانچه سیستمی GPU نداشته باشه (که دیگه اینروزا خیلی بعیده) قضیه hand-off میشه به همون CPU مون!بنابراین اگر حرکاتی(!) بزنیم که Reflow رخ نده، می‌تونیم انتظار سرعت و عملکرد بهتری در وبسایتمون داشته باشیم. منظورمون از حرکات هم صرفا تغییر css مونه.البته Reflow لازم و ضروریه اما یه وقت‌هایی واسه یه چیز بیخودی و دائما در حال انجام (مثل انیمیشن‌ها) ما اشتباها موجبات Reflow رو فراهم می‌کنیم (در حالیکه می‌تونیم نکنیم) و اینجوری سایتمون کند میشه و بعضا هنگ می‌کنه.چه حرکاتی نیازی به reflow ندارند؟اگر بخوایم براش یه لیست درست کنیم، قطعا به خاطر نمیشه سپرد و اصلا کار جالبی هم نیست!فقط کافیه این rule of thumb رو بخاطر بسپارید:هر تغییر CSS ای که ابعاد و موقعیت x,y یک المان و همسایه‌هاش رو عوض نکنه، موجب reflow نمیشه.خب دیگه خودتون می تونید یه لیست درست کنید، کارهایی مثل تغییر color و background و opacity تنها نمونه‌هایی از این لیست هستند.مثال عملی: انیمیشن با Reflow و بدون Reflowیه انیمیشن ساده رو با دو روش زیر انجام بدیم یکی با مارجین یکی با ترنسفورم. اولی یه nightmare برای مرورگره و دومی یه چیزه خیلی سریع و مناسب.روش اول: استفاده از margin (دردسرساز!)

Animation with margin

.box { width: 100px; height: 100px; background: blue; margin-top: 10px; } .bad-animation:hover { margin-top: 110px; /* This cause reflow! */ transition: margin-top 0.3s ease; } روش دوم: استفاده از transform (بهینه!)

Animation with transform

.box { width: 100px; height: 100px; background: green; margin-top: 10px; } .good-animation:hover { transform: translateY(100px); /* This isn't cause reflow! */ transition: transform 0.3s ease; } توضیح:در روش اول، با تغییر margin-top، مرورگر مجبور هست تمام المان‌های بعدی رو مجددا محاسبه کنه (reflow)در روش دوم، transform فقط المان رو در Stacking context جداگانه‌ای حرکت میده و نیازی به محاسبه مجدد موقعیت سایر المان‌ها ندارهبریم سراغ Stacking Contextمقدمه: حالت چینش normal flow چیه؟فرض کنید یه فایل HTML مانند فایل زیر دارید. تمامی المنت‌ها در این فایل، در normal flow زیست می کنند. Simple HTML Page

Hello, World!

This is a simple HTML page with no styles or JavaScript.

مفهوم normal flow در مرورگر: یعنی المان های از نوع block در زیر هم به صورت عمودی قرار می گیرند و المان های از نوع inline به صورت افقی در کنار هم. تصویر زیر:تمام المنت‌هایی که در HTML داریم مثل div, p, a, article, و غیره همگی به طور پیشفرض براساس normal flow توسط مرورگر چیده می‌شوند، مگر اینکه با Stacking Context آن‌ها رو از normal flow خارج کنیم!تعریف ‌Stacking Contextاگر با واژه stack آشنا نیستید باید بگم، stack مشابه طبقات یک کیک است که روی هم قرار می‌گیرند و وقتی می‌خواهیم کیک بخوریم قاعدتا اون طبقه بالایی رو اول برمی‌داریم. به عبارت دیگر آخرین (روترین) لایه روی کیک، اولین لایه‌ای است که باید برداریم. (لطفا تصورش کنید!)حالا Stacking Context در مرورگر طبق تعریف سایت MDN می‌شود:اگر ساختار چینش المان ها در صفحه HTML را در یک صفحه سه بعدی در نظر بگیریم، به محور Z و نحوه قرارگیری المان ها در آن stacking context می گویند.چجوری stacking context ایجاد کنیم؟هر کدام از element های زیر می‌توانند منجر به ایجاد stacking context جدید شوند:المنت ()المنتی با مقدار position برابر absolute یا relative و مقدار z-index غیر از autoالمنتی با مقدار position برابر fixed یا stickyالمنتی با مقدار container-type برابر size یا inline-sizeالمنتی که یک flex item است با مقدار z-index غیر از autoالمنتی که یک grid item است با مقدار z-index غیر از autoالمنتی با مقدار opacity کمتر از 1المنتی با مقدار mix-blend-mode غیر از normalالمنتی با هر یک از خواص زیر با مقداری غیر از none:transform (مثالی که بالاتر زده بودیم مثلا همین رو فقط داشت)scalerotatetranslatefilterbackdrop-filterperspectiveclip-pathmask / mask-image / mask-borderمشاهده کامل مقاله درhttps://farshidev.ir/Post/layers-and-stacking-contextموفق باشید.

استفاده از bootstrap در Reactjs و Nextjs و Typescript

فرشید کریمی — Wed, 25 May 2022 15:19:07 +0430

در Reactjs: (با Typescript یا بدون آن)نصب اولیه:npm i bootstrapدو دستور زیر را به index.js می افزاییم:import "bootstrap/dist/js/bootstrap.min.js" import 'bootstrap/dist/css/bootstrap.min.css';در Nextjs: (بدون Typescript)نصب اولیه:npm i bootstrapدستورات زیر را به app.js_ می افزاییم: (چون در nextjs روی سمت سرور صفحه ساخته می شود و آنجا document یا window نداریم، بایستی ایمپورت bootstrap.js رو در زمانی که صفحه روی مرورگر رندر شد، انجام دهیم)import 'bootstrap/dist/css/bootstrap.min.css'; import {useEffect} from 'react'; useEffect(() => { import("bootstrap/dist/js/bootstrap.min.js"); }, []);در Nextjs: (با Typescript)تنها تفاوت نسبت به حالت بدون Typescript در نحوه نوشتن useEffect است:useEffect(() => { typeof document !== undefined ? require('bootstrap/dist/js/bootstrap'): null }, [])البته اگر خواستید می تونید از react-bootstrap هم استفاده کنید که چالش های بالا رو نداشته باشید.

ساخت پروژه API در React با Typescript

فرشید کریمی — Thu, 10 Mar 2022 17:04:35 +0330

پروژه کار با API ساده در React را قدم به قدم با Typescript انجام می دهیم.ما در این نوشته یک برنامه API ساده در React را به کمک Typescript می سازیم. Typescript به نوعی یک Wrapper روی Javascript است که به ما قدرت بیشتری می دهد. اصلی ترین ویژگی این اصطلاحا زبان برنامه نویسی، strict type بودن متغیر ها می باشد. به عبارت دیگر از آنجا که در Javascript ما type نداریم به کمک این زبان می توانیم type ها را به صورت صریح مشخص نموده و از خطاها جلوگیری کنیم.خب برو بریم!برای این کار اول با npx یک پروژه می سازیم. همانطور که توجه می کنیم تمپلیت پیش فرضی که به create-react-app گفتیم تا برای ما بسازه به زبان tsx (typescript) استnpx create-react-app typescript-apiapp --template typescriptخب اگر در پروژه ای که ایجاد شده، دقت کنید. متوجه می شوید تمام فایل هایی که در یک پروژه react با پسوند js بود، تبدیل به پسوند tsx شده اند. همچنین برای زیباتر شدن پروژه از Bootstrap نیز استفاده خواهیم نمود بنابراین آن را با دستور زیر نصب می کنیم.npm i bootstrapبرای استفاده از bootstrap در صورت تمایل می توانید دو خط زیر رو به ابتدای index.tsx تون اضافه کنید.import "bootstrap/dist/css/bootstrap.min.css" import "bootstrap/dist/js/bootstrap.min.js"خب فایل App.tsx رو باز می کنیم و تمام محتویات اون رو پاک می کنیم تا به شکل زیر در بیاد.خیلی ریکلس حالا توی src یک پوشه به نام components ایجاد می کنیم و دو فایل Header.tsx و Header.css رو در اون قرار می دهیم.کد Header.js را به صورت زیر می نویسیم. در این کد type کامپوننت Header را از نوع React.FunctionComponent مشخص کردیم که یک type تعریف شده در React می باشد. توجه کنید که کامپوننتی که از این فایل export می شود هم همین Header است. همچنین به وسیله generic ها در زبان tsx باید type ورودی این کامپوننت هم با Interface ها تعریف شود که در اینجا IHeaderProps می باشد که چون ورودی برای این کامپوننت نیاز نداریم، خالی می گذاریم.همچنین App.tsx را نیز به صورت زیر تغییر می دهیم.به زودی از این سایت اطلاعات کاربران را دریافت می کنیم و نمایش می دهیم، اما قبل از آن نیاز داریم تا type داده های دریافتی از API را به صورت صریح مشخص کنیم. برای اینکار پوشه به نام models در پوشه src ایجاد می نماییم و فایل note.model.ts را مطابق زیر در آن ایجاد می کنیم.export interface note { id: string, title:string, body:string };در ادامه ما نیاز به کامپوننتی داریم تا note ها را به ما نشان دهد و بتونیم اون رو در Header مون بگذاریم. برای این کار کامپوننت ListNotes.tsx را ایجاد می کنیم. این کامپوننت هم مشابه کامپوننت Header تعیین type شده است. برای ورودی این کامپوننت ورودی notes را تعیین کردیم که باید با نام موجود در interface یکسان باشد. به کمک interface می توانیم type این ورودی را تعیین کنیم.حالا تغییرات لازم در App.tsx را انجام می دهیم تا خروجی کامپوننت بالا به کاربر نشان داده شود. نکات لازم به ذکر این است که ما اولا props ای که بوسیله useState آن را نگهداری می کنیم، به کامپوننت ListNotes دادیم. همچنین type متغیر notes را از نوع model ای که تعریف کردیم، تعیین کردیم.خب خسته نباشید، قلنج انگشتاتون رو بشکنید تا بریم سراغ ادامه کار.حالا اطلاعات رو از API می گیریم و نمایش می دهیم. این کار رو در App.tsx و به کمک useEffect و فقط در اولین رندرینگ انجام می دهیم.خروجی بدین صورت خواهد بود.خب می خواهیم در انتها یک ویژگی دیگه هم اضافه کنیم که آیتم های بالا را بتوان حذف نمود. برای این کار اول باید توجه داشته باشیم که متدی که قدرت تغییر notes را دارد setNotes است که در App.tsx است، بنابراین آن را به ListNotes پاس می دهیم.خب حال تغییرات اصلی را در ListNotes.js می دهیم. اول در UI یک دکمه ایجاد می کنیم و البته key لازم را به هر آیتم می دهیم. وظیفه دکمه پاس دادن id آیتم به متد حذف کننده است.در متد حذف کننده به وسیله filter آیتمی که id آن موافق id مدنظر باشد را حذف می کنیم. همچنین چون به props های ListNotes تابع setNotes را نیز افزودیم باید در interface آن را معرفی کنیم.خسته نباشید! امیدوارم براتون مفید واقع شده باشه و من خوب توضیح داده باشم. ممنون میشوم اشکالی چیزی بود بهم بگید.ضمنا سورس کامل پروژه در این آدرس می باشد.

آموزش React Router ورژن 6

فرشید کریمی — Mon, 07 Mar 2022 18:11:14 +0330

آموزش قدم به قدم آخرین ورژن React Router با یک پروژه سادهاز انتشار ورژن 6 کتابخونه React Router حدود 5 ماهی می گذره، و این ورژن ویژگی های کاربردی زیادی نسبت به ورژن 5 داره که ما در این نوشته با ساختن یک پروژه قدم به قدم یادشون می گیرم.خب گام اول مثل همیشه ساخت پروژه اولیه مون هستش‍‍‍‍npx create-react-app router-v6خب آخرین ورژن router رو در پروژه نصب می کنیمnpm install react-router-domخب همونطور که می دونید هر پروژه Reactjs که از روند بالا تولید میشه، کلی بخش غیرقابل استفاده برای تازه کارها داره که حذفشون می کنیم.(اینو بگم که من از ویرایشگر Atom تحت Lubuntu استفاده می کنم که البته برای شما می تونه هر چیز دیگری باشه)حالا فایل index.js مون رو هم خلوت می کنیم تا بدین شکل بشهفایل App.js مون رو نیز هم!الان همچین چیزی در برنامه مون داریمدر پوشه src یک پوشه به نام components ایجاد کرده و فایل Home.js با محتویات زیر رو در اون ایجاد می کنیم.حالا فایل App.js رو ویرایش می کنیم تا حاوی Home.js شود، باید به این نکته اشاره کنم که در ورژن ششم، Switch با Routes تعویض شده است.من برای نوشتن UI از bootstrap و sass کمک می گیرم که البته ارتباطی با روند پروژه نداره و برای سادگی می باشد. برای استفاده ازون من از روش زیر توی پروژه نصبش می کنم و بعد در کامپوننت مدنظرم import اش می کنم.npm install bootstrap sassیه کامپوننت جدید به نام Courses.js اضافه می کنیم.حالا در App.js مون دو تا Route ایجاد می کنیم. اولی به Courses اشاره می کند به طور معمول(مسیر courses). دومی از ویژگی جدیدی به نام Navigate استفاده می کند که ما از طریق مسیر apps به همان مسیر courses می رسیم. (کاربرد آن در ادامه واضح تر خواهد شد.)حالا در صورتی که به localhost:3000/courses یا localhost:3000/apps برویم با صفحه زیر مواجه می شویم.حالا دو کامپوننت جدید ایجاد می کنیم که درون کامپوننت Courses آن ها را در ادامه نشان خواهیم داد. این دو کامپوننت AllCourses.js و Bundles.js می باشند. برای شفافیت بگم که Bundles یک کامپوننت در کنار کامپوننت AllCourses است که می تواند موارد دلخواه دیگری در آن قرار بگیرد و AllCourses هم قرار است تمامی درس ها را نشان دهد و Courses هم عوض می کنیم به زودی.حالا در App.js به route درس ها، دو route می افزاییم. این کار باعث می شود که مسیر دو route جدید در امتداد مسیر درس ها یعنی courses/ باشد.حالا Courses.js رو ویرایش می کنیم تا حاوی دو button باشد که ما رو AllCourses و Bundles ببره. برای لینک دادن به اون ها از Link و برای نمایش محتواشون از Outlet استفاده می کنیم.حاصل بدین صورت خواهد بود.خب خسته نباشید :) . تا اینجا یک Routing ساده صفحات رو انجام دادیم.حالا فرش کنید که می خواهیم روی هر درس که کلیک شد، اطلاعاتی درباره اون درس به کاربر نمایش داده بشه و اون رو در یک آدرس مجزایی نشان دهد مثلا جزئیات درس CSS در مسیر زیر:localhost:3000/courses/allcourses/CSSخب برای اینکار با توجه به relative بودن مسیر، اون رو در route اصلی در App.js می افزاییم. اگر به مسیر SingleCourse دقت کنید، متوجه می شوید که مسیر id: می باشد. این یعنی مسیر دینامیک توسط برنامه خودمون تعیین می شود و می تونه هر چیزی باشه. برای اینکه خود SingleCourse بفهمد که در چه مسیری می باشد، جلوتر روشی با useParams گفته می شود.حالا تغییرات لازم به کد AllCourses.js می دهیم. لیست درس ها را به کمک map می سازیم. به متد map دقت کنید. اولا از آنجا که ورودی string است پس به وسیله template literals ما مسیر خودمون رو تولید کردیم. فرق این کد با کد قبلی این است که Link به NavLink تبدیل شده است. تفاوت اصلی NavLink این است که وقتی روی آن کلید می شود، به طور خودکار کلاس active. برای آن فعال می شود و بدین وسیله ما در کد css مون می تونیم براش ویژگی خاصی تعیین کنیم. فقط همین! اگر حال نمی کنید همون Link رو بگذارید باشه. نهایتا هم با Outlet محتوای اون مسیر رو نشون می دهیم.خب توی App.js محتوای مسیرهای فوق رو به SingleCourse متصل کردیم حالا SingleCourse.js رو می سازیم. برای دسترسی به id که در واقع همون مسیر ماست، از هوکی به نام useParams استفاده می کنیم و اطلاعات را نشان می دهیم.خب حالا نکته دیگری رو با هم تمرین می کنیم و اون pass کردن دیتا بین دو کامپوننت است. در ورژن 6 router این کار را می توان هم با هوک useNavigate و هم با خود Link انجام داد. ما هر دوی این روش ها رو تست می کنیم.به این منظور، در SingleCourse ما بخشی رو درنظر می گیریم که اطلاعات را به کامپوننتی به نام Dashboard برای ما منتقل کند که در یک route جداگانه می باشد. بنابراین اول Dashboard را در App.js معرفی می کنیم.حالا تغیرات لازم را در SingleCourse.js داده که همانطور که گفتیم قرار است اطلاعات را برای ما منتقل کند از دو روش. برای انتقال از طریق useNavigate از تگ استفاده کردیم که البته می توانست button هم باشد یا هر چیزی دیگری و از Link هم برای انتقال داده به کامپوننت Dashboard استفاده کردیم.خب حالا در کامپوننت Dashboard.js اطلاعات را دریافت می کنیم. برای دریافت اطلاعات از هوک useLocation استفاده می کنیم.خب خسته نباشید حالا اطلاعات را به راحتی از دو روش بین کامپوننت ها منتقل نمودیم.فقط تنها نکته ای که باقی مونده Home.js است که برای زیبایی در اون یک لینک قرار می دهیم که به بخش درس ها بیاید.خب خسته نباشید به شما!مفاهیم اصلی React Router v6 رو در این نوشته با هم مرور کردیم. برای دسترسی به فایل های کامل پروژه به این آدرس رجوع کنید.