نوشته های fatemeh....

توابع در JSX: رندر، بهینه‌سازی و Memoization

fatemeh.... — Sun, 02 Nov 2025 10:17:22 +0330

1.تابع ثابت خارج از JSX"وقتی تابع را خارج از کامپوننت تعریف میکنیم، فقط یک بار در حافظه ایجاد میشود و مرجع آن در طول اجرای برنامه ثابت باقی می ماند."function handleClick() { console.log("Clicked"); } const Item = React.memo(({ }) => ( )); function App() { return ; }در کد بالا چه اتفاقی می افتد ؟وقتی کامپوننت App اجرا میشود، تابع handleClick فقط یکبار ساخته شده و در props به Item ارسال میشود.چون مرجع تابع در رندرهای بعدی تغییر نمیکند، React.memo متوجه میشود که props ثابت ماندهاند و Item دوباره رندر نمیشود.مرجع تابع در رندر های مختلف تغییر نمی کند پس هر بار که کد رندر می شود Item دوباره رندر نمی شود.نکته ی مهم : اگر تابع داخل App تعریف میشد، مثل:function App() { const handleClick = () => console.log("Clicked"); return ; }در این حالت هر بار که App رندر میشود، یک مرجع جدید از handleClick ساخته میشود و Item با React.memo مجبور به رندر دوباره میشود. با استفاده از useCallback می تونیم این مشکل را حل کنیم.2.Arrow function مستقیم در JSX"وقتی تابع را مستقیماً بهصورت Arrow function داخل JSX تعریف میکنیم، در هر رندر یک تابع جدید ساخته میشود و مرجع آن تغییر میکند؛ در نتیجه memoization از کار میافتد."function App() { return console.log("Clicked")} />; }در کد بالا چه اتفاقی می افتد ؟در هر بار رندر کامپوننت App، یک تابع جدید در حافظه ساخته میشود..از اونجایی که memo فقط مقایسه ی سطحی (shallow) انجام میدهد، در رندرهای بعدی متوجه میشود که مرجع تابع تغییر کرده و نتیجه میگیرد که props تغییر کرده اند.در نتیجه، کامپوننت فرزند (مثل Item) دوباره رندر میشود حتی اگر عملکرد تابع اصلی (handleClick) هیچ تغییری نکرده باشد.به همین دلیل این روش باعث شکست memoization و ایجاد رندرهای غیرضروری میشود.توصیه: تعریف تابع مستقیم در JSX فقط برای کامپوننتهای کوچک یا بدون memo مناسب است؛ در غیر این صورت باعث رندرهای غیرضروری و کاهش کارایی میشود.3. تابع تعریفشده با useCallback"با useCallback، تابع فقط زمانی که وابستگیها تغییر کنند بازسازی میشود و مرجع آن ثابت میماند؛ بنابراین memo درست کار میکند و از رندرهای اضافی جلوگیری میشود."const Item = React.memo(({ }) => { return ; }); function App() { const handleClick = useCallback(() => { console.log("Clicked"); }, []); return ; }در کد بالا چه اتفاقی می افتد ؟تابع handleClick با استفاده از useCallback ساخته میشود و تا زمانی که وابستگیهای آن (در اینجا هیچ وابستگی ندارد) تغییر نکنند، مرجع آن ثابت میماند.در نتیجه، React.memo تشخیص میدهد که props تغییری نکردهاند و از رندر مجدد Item جلوگیری میکند.

مشکل arrow function در jsx و اثرش در memoize

fatemeh.... — Sat, 01 Nov 2025 11:15:17 +0330

در React، memoization با React.memo، useMemo و useCallback برای کاهش رندرهای غیرضروری استفاده میشود. با این حال، حتی با این ابزارها، استفاده از arrow function مستقیم در JSX میتواند باعث شکستن بهینه سازی شود.import { memo, useCallback } from 'react';const Item = memo(({ click }) => { console.log('Item rendered'); return ;});function App({ value }) { const handleClick = useCallback(() => { }, [value]); return handleClick()} />;}export default App;در کد بالا، handleClick با useCallback ساخته شده و تا وقتی تغییر نکند، تابع ثابت میماند. این باعث میشود memoization روی handleClick کارآمد باشد و از رندرهای غیرضروری جلوگیری شود. handleClick()} />اما مشکل اینجاست که وقتی از arrow function استفاده میکنیم هر بار که مؤلفه رندر میشود، یک تابع جدید میسازد. درسته که از useCallback استفاده کردیم اما هر بار که تابع را می سازیم دارای یک مرجع (reference) جدید است.چرا باعث می شود memoization شکسته شود؟تابع handleClick به عنوان یک prop به مؤلفه Item پاس داده میشود.هر بار که مؤلفه والد رندر میشود، arrow function جدید ساخته میشود و مرجع آن تغییر میکند.چون Item با React.memo نوشته شده است، React props قبلی و جدید را مقایسه میکند.از آنجا که مرجع تابع تغییر کرده، React فکر میکند props تغییر کرده و Item دوباره رندر میشود.نتیجه: memoization کار نمیکند، Item همیشه رندر میشود و تمام بهینهسازیها از بین میرود.

git checkout vs git switch/git restore

fatemeh.... — Wed, 29 Oct 2025 15:20:52 +0330

git checkout یکی از دستورهای قدیمی و پرکاربرد گیت است که برای جابجایی بین نسخه‌ها و شاخه‌های مختلف پروژه استفاده می‌شد.تا قبل از سال ۲۰۱۹، تنها راه انجام این کار همین دستور بود.اما چون git checkout چند کار مختلف را با هم انجام می‌داد، گاهی باعث اشتباه یا سردرگمی می‌شد.به همین دلیل، از نسخه ۲.۲۳ به بعد، گیت دو دستور جدید معرفی کرد:git switch و git restore تا هرکدام وظیفه مشخص‌تری داشته باشند.کاربردهای اصلی git checkoutسوییچ بین Branchهامی‌تونی بین شاخه‌های مختلف پروژه جابه‌جا بشی و روی نسخه‌های متفاوت کد کار کنی:git checkout branch-nameساخت و جابجایی هم‌زمان به یک Branch جدیدمی‌تونی شاخه‌ی جدیدی بسازی و هم‌زمان واردش بشی تا روی تغییرات جدید کار کنی:git checkout -b branch-nameبرگردوندن فایل‌ها به حالت قبلاگه فایلی رو اشتباهی تغییر دادی و هنوز commit نکردی، می‌تونی اون رو به آخرین وضعیت ذخیره‌شده برگردونی:git checkout -- file-pathرفتن به نسخه خاصی از Commitبا استفاده از شناسه (hash) هر commit می‌تونی مستقیماً به اون نسخه برگردی:git checkout hash-nameجایگزین‌های جدیددستور git switchشاخه‌ی جدیدی به نام branch-name ساخته می‌شود و هم‌زمان وارد آن می‌شوی.git switch -c branch-nameدستور git restoreدستور git restore برای برگردوندن فایل‌ها به حالت قبلی‌شون استفاده میشه.git restore file-name

Git Flow

fatemeh.... — Wed, 22 Oct 2025 15:43:27 +0330

«مدل شاخه‌بندی منظم برای کنترل و انتشار کد در گیت.»Git Flow چیه؟Git Flow یک مدل استاندارد برای مدیریت شاخه‌ها (branches) در گیت هست که کمک می‌کنه توسعه‌ی پروژه به‌صورت منظم، قابل پیش‌بینی و تمیز انجام بشه.در واقع Git Flow بهت نمی‌گه "چطور از git استفاده کن"،می‌گه "چطور شاخه‌هات رو سازمان‌دهی کن تا کار تیمی و انتشار راحت بشه".شاخه‌های اصلی در Git Flowدر Git Flow پنج نوع branch اصلی وجود داره:1.main (یا master) : شاخه‌ی اصلی و رسمی محصول (Production) که هر نسخه ای که منتشر میشه از این شاخه میاد.2.develop : شاخه‌ی توسعه (Development line) که همه‌ی ویژگی‌ها بعد از تست به این شاخه merge می‌شن آخرین نسخه‌ی آماده‌ی انتشار اینجاست و از این شاخه نسخه‌ی جدید (release) ساخته می‌شه.stage : در Git Flow استاندارد شاخه‌ای به اسم stage وجود نداره، اما بعضی تیم‌ها خودشون یه شاخه اضافه می‌کنن به اسم stage یا staging. این کاملاً یه توافق تیمی هست و به پروژه و پروسه‌ی دیپلوی بستگی داره."در واقع، شاخه‌ی stage یک واسط بین develop و main است که قبل از انتشار نسخه روی main، تست نهایی روی آن انجام می‌شود و QA و تست‌کننده‌ها روی این شاخه کار می‌کنند."مزیت شاخه‌ی stage: امنیت بیشتر برای production: هیچ feature ناقص مستقیم وارد main نمی‌شه.تست متمرکز: همه featureها قبل از انتشار واقعی روی یه شاخه هستنآماده‌سازی release: گاهی tag یا version نهایی روی stage زده می‌شه قبل از merge به mainنکته‌ی مهم درباره‌ی این شاخه این است که به صورت رسمی جزو Git Flow نیست، به آن گاهی pre-release branch نیز گفته می‌شود و برای تست‌ها و آماده‌سازی‌های پیش از عملیاتی شدن استفاده می‌شود.ساختار branch Main (یا Master): شاخه‌ی رسمی و پایدار محصول، همان نسخه‌ای که روی production منتشر می‌شه.Develop: شاخه‌ی اصلی توسعه، جایی که همه‌ی فیچرها merge می‌شن تا برای انتشار آماده بشن.Feature Branch: توسعه‌ی قابلیت یا فیچر جدید به صورت مستقل از develop.Release Branch: آماده‌سازی نسخه‌ی جدید برای انتشار؛ شامل تست و رفع باگ‌های کوچک.Hotfix Branch: رفع فوری باگ‌ها در نسخه‌ی منتشرشده روی main.مدل‌های رایج Git Flow1. Classic Git Flowبرنچ‌ها:main, develop, release/*, feature/*, hotfix/*توضیح:این مدل ساختار استاندارد و کلاسیک Git Flow است.توسعه‌های جدید روی develop انجام می‌شوند.برای هر نسخه‌ی آماده انتشار، یک برنچ موقت با نام release/0.0.0.0 ساخته می‌شود تا تست نهایی و رفع باگ‌ها روی آن انجام شود.پس از نهایی شدن، تغییرات به main (نسخه‌ی پایدار) و develop (برای ادامه توسعه) مرج می‌شوند.نسخه‌ها با tag مشخص می‌شوند، نه با برنچ جداگانه.در صورت نیاز به رفع سریع باگ در نسخه‌ی منتشرشده، از برنچ hotfix/* استفاده می‌شود.🟢 مناسب برای پروژه‌های بزرگ یا تیم‌هایی که چند مرحله‌ی مجزا بین توسعه تا انتشار دارند.2. Git Stage Flowبرنچ‌ها:main, develop, stageتوضیح:در این مدل، به جای ساخت برنچ‌های موقتی برای هر نسخه، یک برنچ دائمی به نام stage وجود دارد.توسعه‌های جدید روی develop انجام می‌شوند.وقتی نسخه‌ای آماده‌ی تست نهایی است، به stage مرج می‌شود.پس از تأیید در محیط استیج، تغییرات از stage به main منتقل می‌شود تا منتشر گردد.🟡 مناسب برای تیم‌هایی با انتشار سریع (CI/CD) یا پروژه‌هایی که نیاز به استیجینگ دائمی دارند.3. LTS Git Flow (Long-Term Support)برنچ‌ها:main, develop, release/1.x, release/2.x, ...توضیح:در این مدل، هر نسخه‌ی اصلی (major version) که هنوز پشتیبانی می‌شود، برنچ مخصوص به خودش را دارد.توسعه‌های جدید در develop انجام می‌شوند.هر نسخه‌ی پایدار در برنچ مخصوص خودش release/1.x , release/2.x و غیره نگهداری می‌شود.باگ‌فیکس‌ها یا آپدیت‌های امنیتی روی همان برنچ نسخه انجام می‌گیرند.نسخه‌ها معمولاً با tag هم مشخص می‌شوند.🔵 مناسب برای پروژه‌های Enterprise یا نرم‌افزارهایی که چند نسخه‌ی فعال به‌طور هم‌زمان دارند (مثل APIهایی که مشتریان مختلف از نسخه‌های متفاوت استفاده می‌کنند).