<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های محمدامین رعدی</title>
        <link>https://virgool.io/feed/@m_47909442</link>
        <description>توسعه‌دهنده فرانت‌اند | متمرکز روی React | در حال ساخت پروژه‌های واقعی | مشتاق یادگیری و رشد</description>
        <language>fa</language>
        <pubDate>2026-04-15 06:11:17</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/583010/avatar/9FY4LY.jpg?height=120&amp;width=120</url>
            <title>محمدامین رعدی</title>
            <link>https://virgool.io/@m_47909442</link>
        </image>

                    <item>
                <title>چرا بعضی پروژه‌ها کند لود میشن؟</title>
                <link>https://virgool.io/@m_47909442/%DA%86%D8%B1%D8%A7-%D8%A8%D8%B9%D8%B6%DB%8C-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D9%87%D8%A7-%DA%A9%D9%86%D8%AF-%D9%84%D9%88%D8%AF-%D9%85%DB%8C%D8%B4%D9%86-cxghd5teby0c</link>
                <description>چرا پروژههات کند لود میشن؟کندی لود سایتها همیشه به مشکلات پیچیدهی فنی مربوط نیست. گاهی دلیلش درست جلوی چشم ماست ولی نادیده گرفته میشه. در این بخش به سه عامل مهم و رایج که باعث کند شدن پروژهها میشن میپردازیم — همراه با راهکار و مثالهای کدی در زبانها و فریمورکهای مختلف. ۱. تصاویر سنگین و بدون بهینهسازیتصاویر حجیم، بدون فشردهسازی و با فرمتهای قدیمی (مثل PNG یا JPG) یکی از دلایل رایج کندی لود هستن. مخصوصاً در سایتهایی که گالری، بنر یا بکگراند تصویری دارن.راهکارها:استفاده از فرمتهای مدرن مثل WebP یا AVIFفعالسازی lazy loadingتنظیم اندازه واقعی تصاویر برای جلوگیری از layout shift📌 مثالها:HTML:htmlCopyEdit&lt;img src=&amp;quot/images/banner.webp&amp;quot loading=&amp;quotlazy&amp;quot width=&amp;quot1200&amp;quot height=&amp;quot600&amp;quot alt=&amp;quotبنر اصلی سایت&amp;quot&gt;React (Next.js):jsxCopyEditimport Image from &amp;quotnext/image&amp;quot

&lt;Image 
  src=&amp;quot/images/banner.webp&amp;quot 
  alt=&amp;quotبنر اصلی&amp;quot
  width={1200}
  height={600}
  loading=&amp;quotlazy&amp;quot
/&gt;Tailwind CSS:htmlCopyEdit&lt;img src=&amp;quot/img.webp&amp;quot class=&amp;quotobject-cover aspect-video w-full&amp;quot loading=&amp;quotlazy&amp;quot&gt; ۲. فایلهای جاوااسکریپت حجیم و غیرضروریبارگذاری کتابخانههایی مثل Lodash یا Moment بهصورت کامل بدون استفاده از تکنیکهایی مثل Tree Shaking یا Code Splitting باعث سنگینی زیاد فایلهای JS میشه.راهکارها:فقط ماژولهای موردنیاز رو ایمپورت کناز Tree Shaking و Lazy Loading در ابزارهایی مثل Webpack یا Vite استفاده کندر React از React.lazy برای بارگذاری ماژولها بهصورت پویا بهره ببر📌 مثالها:کد قدیمی و سنگین:jsCopyEditimport _ from &amp;quotlodash&amp;quot
const result = _.cloneDeep(data);کد بهینه:jsCopyEditimport cloneDeep from &amp;quotlodash/cloneDeep&amp;quot
const result = cloneDeep(data);React Lazy Loading:jsxCopyEditconst Chart = React.lazy(() =&gt; import(&#039;./components/Chart&#039;));

&lt;Suspense fallback={&lt;div&gt;در حال بارگذاری...&lt;/div&gt;}&gt;
  &lt;Chart /&gt;
&lt;/Suspense&gt; ۳. نبود CDN یا کش مناسبلود کردن فایلها مستقیماً از سرور داخلی باعث کندی در مناطق دور، فشار به سرور و مصرف بالاتر منابع میشه.راهکارها:استفاده از CDNهای عمومی مثل jsDelivr یا Cloudflareتنظیم مناسب Cache-Controlنسخهگذاری فایلها برای جلوگیری از کش اشتباه📌 مثالها:قبل:htmlCopyEdit&lt;script src=&amp;quot/libs/jquery.min.js&amp;quot&gt;بعد:htmlCopyEdit&lt;script src=&amp;quothttps://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js&amp;quot crossorigin&gt;هدر پیشنهادی برای کش:arduinoCopyEditCache-Control: public, max-age=31536000, immutableدلایل پنهان + تستهای حرفهای و ابزارهاوقتی تمام موارد واضح رو رعایت کردی و پروژه هنوز کنده، وقتشه سراغ دلایل عمیقتر بری. این پارت به مسائل زیرساختی، تجربه کاربری و تحلیل ابزارها میپردازه. ۴. فونتهای زیاد یا بدون بهینهسازیتعریف:فونتهای متعدد یا با وزنهای زیاد و بدون preload یا swap میتونن زمان نمایش متن رو تا چند ثانیه عقب بندازن!راهحلها:استفاده از فقط وزنهای ضروریفعالسازی font-display: swapفونت در  (head) preload🔧 preload در HTML:htmlCopyEdit&lt;link rel=&amp;quotpreload&amp;quot href=&amp;quot/fonts/iranyekan.woff2&amp;quot as=&amp;quotfont&amp;quot type=&amp;quotfont/woff2&amp;quot crossorigin&gt;🔧 تعریف فونت سفارشی:cssCopyEdit@font-face {
  font-family: &#039;IRANYekan&#039;;
  src: url(&#039;/fonts/iranyekan.woff2&#039;) format(&#039;woff2&#039;);
  font-display: swap;
}🔧 در Tailwind:jsCopyEdittheme: {
  extend: {
    fontFamily: {
      yekan: [&#039;IRANYekan&#039;, &#039;sans-serif&#039;],
    }
  }
} ۵. تست نکردن پروژه در شرایط واقعیتعریف:تست پروژه روی اینترنت پرسرعت و سیستم قوی باعث میشه مشکلات واقعی دیده نشن. کاربر واقعی ممکنه با 3G یا گوشی قدیمی باشه.راهحلها:تست با ابزار DevTools → Throttling → Slow 3Gبررسی Core Web Vitalsاستفاده از نسخه production واقعی نه dev🔧 DevTools تست با سرعت پایین:textCopyEditChrome &gt; DevTools &gt; Network &gt; Throttling &gt; Slow 3G🔧 اجرای نسخه production (React + Vite):bashCopyEditnpm run build
npx serve dist🔧 Angular:bashCopyEditng build --configuration production
npx serve dist/📋 چکلیست نهایی تست سرعت☐ تصاویر WebP با lazy load☐ فونت local و preload شده☐ فقط import ضروری کتابخانهها☐ استفاده از CDN☐ فعال بودن cache با max-age☐ تست واقعی با DevTools / 3G☐ بالای ۸۰ PageSpeed Mobileجمعبندیهمونطور که دیدیم، بسیاری از دلایل کندی سایتها در ظاهر ساده هستن، اما تأثیر عمیقی روی تجربه کاربری، SEO و مصرف منابع دارن. بهینهسازی تصاویر، بارگذاری هوشمند جاوااسکریپت و استفاده از CDN میتونه تغییر چشمگیری در سرعت سایت ایجاد کنه.وقتی همه چیز بهدرستی پیادهسازی شده ولی سایت هنوز کُند لود میشه، وقتشه عمیقتر نگاه کنیم. از فونتهای بدون بهینهسازی گرفته تا تست نکردن پروژه در شرایط واقعی، هرکدوم میتونه تجربه کاربر رو خراب کنه. پس اگه میخوای یه سایت سریع و حرفهای بسازی، فقط به ظاهر اکتفا نکن — ابزارها و دیتای واقعی همیشه حقیقت رو نشون میدن.#React,#Nextjs,#JavaScript,#LazyLoading,#SEO,#WebPerformance#font_display_swap #PageSpeed,#React,#Vite,#Angular,#DevTools,#core_web_vitals #توسعه_فرانتاند,#سئو,#بهینهسازی_وب,#برنامهنویسی_وب,#لود_فونت تست_واقعی</description>
                <category>محمدامین رعدی</category>
                <author>محمدامین رعدی</author>
                <pubDate>Wed, 07 May 2025 14:28:07 +0330</pubDate>
            </item>
                    <item>
                <title>پایان تدریجی کامپوننت‌های همه‌کاره</title>
                <link>https://virgool.io/@m_47909442/%D9%BE%D8%A7%DB%8C%D8%A7%D9%86-%D8%AA%D8%AF%D8%B1%DB%8C%D8%AC%DB%8C-%DA%A9%D8%A7%D9%85%D9%BE%D9%88%D9%86%D9%86%D8%AA-%D9%87%D8%A7%DB%8C-%D9%87%D9%85%D9%87-%DA%A9%D8%A7%D8%B1%D9%87-xsn1th11ah76</link>
                <description>The Gradual Decline of All-in-One Components  دنیای توسعه وب همیشه در حال تحول است. یکی از مفاهیمی که سالها بهعنوان یک استاندارد طلایی شناخته میشد، کامپوننتهای قابل استفاده مجدد بود. اما امروز، کمکم نشانههایی از افول این رویکرد در برخی بخشها به چشم میخورد. آیا واقعاً دوران کامپوننتهای همهکارهای مثل Button، Modal و Card رو به پایان است؟چرا کامپوننتهای قابل استفاده مجدد محبوب شدند؟با ظهور فریمورکهایی مانند React و Vue، مفهوم ساخت اجزای مستقل و قابل استفاده مجدد، انقلابی در دنیای UI بود. توسعهدهندگان میتوانستند تنها یک بار یک Dropdown یا DatePicker بسازند و در سراسر پروژه از آن استفاده کنند. مزایای کلیدی این رویکرد شامل موارد زیر است:کاهش چشمگیر تکرار کدافزایش سرعت توسعهسهولت در نگهداری و تغییراتانسجام بیشتر در طراحی رابط کاربریچالشهای امروزاما هرچه پروژهها بزرگتر شدند، مشکلاتی نیز ظاهر شد:۱. پیچیدگی بیش از حدکامپوننتهای قابل استفاده مجدد اغلب آنقدر انعطافپذیر میشوند که به یک هیولای کنترلناپذیر تبدیل میشوند. نمونه کلاسیک آن، دکمهای با بیش از ۲۰ پراپ است!۲. افزایش حجم باندلساخت کامپوننتهایی که تمام حالات ممکن را پوشش دهند، باعث ارسال کدهای اضافی به مرورگر میشود؛ حتی اگر از بیشتر قابلیتها استفاده نشود.۳. کاهش بهرهوری در تیمهای بزرگگاهی پیدا کردن، فهمیدن یا سازگار کردن یک کامپوننت موجود زمانبرتر از ساخت یک کامپوننت جدید است.ترندهای جدید: انعطافپذیری بالاتر، اجزای کوچکتر✅ کامپوزپذیری به جای همهکاره بودنبهجای یک کامپوننت بزرگ و پیچیده، حالا توسعهدهندگان ترجیح میدهند اجزای کوچکتر بسازند و آنها را ترکیب کنند.مثال موردی: کامپوننت Modal / Dialog💡 روش سنتی (Monolithic)&lt;Modal 
isOpen={true}
title=&amp;quotتأیید حذف&amp;quot
description=&amp;quotآیا از حذف این مورد اطمینان دارید؟&amp;quot
primaryButton=&amp;quotحذف&amp;quot
secondaryButton=&amp;quotانصراف&amp;quot
onPrimaryClick={handleDelete}
onSecondaryClick={handleCancel}
closeOnClickOutside={true}
/&gt;در این ساختار، تمام رفتارها و محتوا در یک کامپوننت کنترل میشود. اضافهکردن تغییرات ساختاری ممکن است پیچیده و محدود باشد.✅ روش مدرن (Composable)&lt;Dialog&gt;
&lt;DialogTrigger&gt;حذف کردن&lt;/DialogTrigger&gt;
&lt;DialogContent&gt;
&lt;DialogHeader&gt;
&lt;DialogTitle&gt;تأیید حذف&lt;/DialogTitle&gt;
&lt;DialogDescription&gt;آیا از حذف این مورد اطمینان دارید؟&lt;/DialogDescription&gt;
&lt;/DialogHeader&gt;
&lt;DialogFooter&gt;
&lt;Button variant=&amp;quotdestructive&amp;quot ={handleDelete}&gt;حذف&lt;/Button&gt;
&lt;Button variant=&amp;quotoutline&amp;quot ={handleCancel}&gt;انصراف&lt;/Button&gt;
&lt;/DialogFooter&gt;
 &lt;/DialogContent&gt;
&lt;/Dialog&gt;در این مدل، هر بخش از Dialog بهصورت مستقل قابل کنترل است. ساختار از اجزای سادهتر تشکیل شده که به راحتی قابل بازآرایی هستند.دیگر رویکردهای محبوب: Utility-First CSSفریمورکهایی مانند Tailwind CSS ثابت کردهاند که میتوان بدون نیاز به ساختن کامپوننتهای پیچیده، تنها با ترکیب کلاسها، کامپوننتهای قدرتمندی ساخت. Atomic Designرویکردی ساختارمند که UI را به اجزای پایه (اتم)، ترکیبی (مولکول)، و ساختاری (ارگان) تقسیم میکند. این مدل باعث سادگی در توسعه و مقیاسپذیری پروژهها میشود.جمعبندی: پایان یا تکامل؟ما در حال ترک کامل کامپوننتهای قابل استفاده مجدد نیستیم؛ بلکه در حال تکامل دادن آنها هستیم. آینده، ترکیبی هوشمندانه از روشهای گذشته و ترندهای نوین خواهد بود:اجزای پایهای (مانند Button، Switch، Checkbox) همچنان با قابلیت استفاده مجدد باقی میمانند.کامپوزپذیری و ترکیب اجزای ساده، جایگزین کامپوننتهای بزرگ و منعطف میشود.متدولوژیهای طراحی کمک میکنند تا کدها ساختارمند و مقیاسپذیر باقی بمانند.نظر شما چیست؟آیا شما هم در پروژههای خود با مشکلات استفاده از کامپوننتهای همهکاره مواجه بودهاید؟آیا از رویکردهای جدید مانند ترکیب کامپوننتها یا Utility-First استفاده کردهاید؟تجربیاتتان را در بخش نظرات به اشتراک بگذارید.#توسعه_وب #فرانت_اند #ریاکت #ویو#کامپوننت #طراحی_رابط_کاربری #طراحی_سیستم#TailwindCSS,#Atomic_Design,#Design_Systems,#ReusableComponents,#ReactJS,#Fronten,#React_Components,#dArchitecture,#UI_Components</description>
                <category>محمدامین رعدی</category>
                <author>محمدامین رعدی</author>
                <pubDate>Mon, 21 Apr 2025 21:53:56 +0330</pubDate>
            </item>
                    <item>
                <title>ری‌اکت فقط یک ابزار نیست — یک زبان ذهنی برای توسعه‌دهنده‌هاست</title>
                <link>https://virgool.io/@m_47909442/%D8%B1%DB%8C-%D8%A7%DA%A9%D8%AA-%D9%81%D9%82%D8%B7-%DB%8C%DA%A9-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1-%D9%86%DB%8C%D8%B3%D8%AA-%DB%8C%DA%A9-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B0%D9%87%D9%86%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D8%AF%D9%87%D9%86%D8%AF%D9%87-%D9%87%D8%A7%D8%B3%D8%AA-eqay5ovazzzr</link>
                <description>React: A New Way of Thinking, Not Just a Libraryمقدمهوقتی اولین بار با React آشنا شدم، فکر می‌کردم فقط یه لایبرری برای ساختن UI  مثل jQuery یا Angularست. اما هر چی بیشتر باهاش کار کردم، بیشتر متوجه شدم که React فقط یه ابزار نیست؛ React یه زبان جدیده. یه شیوه‌ ی فکر کردنه. ما فقط کد نمی‌نویسیم بلکه ما داریم یاد می‌گیریم چطور «با React فکر کنیم».امروز قصد دارم این ایده رو آشکار کنم : چرا React دارد تبدیل می‌شود به یه زبان مستقل نسبت به بقیه؟؟و چرا این زبان، ذهن ما رو توی طراحی نرم‌افزار تغییر داده؟React چطور مثل یک زبان مستقل عمل می‌کنه؟1.  JSX:در واقع JSX نه فقط سینتکس (syntax) زیبا نیست. در واقع  مهم‌تر از یک سینتکس (syntax) هست در ظاهر شبیه HTML ، ولی در واقع ترکیب data + UI ست.همونطور که میدانید UI جدا از منطق نیست یعنی &quot; UI تو، مستقیم از داده‌هات ساخته می‌شود. &quot;UI is a function of stateمثال:const Hello = ({ name }) =&gt; &lt;h1&gt;Hello, {name}&lt;/h1&gt;;در گذشته روند استفاده به طوری بود که :UI = فایل HTML + فایل JS + فایل CSS1 - فایل HTML برای ظاهر2 - فایل JS برای منطق3- فایل CSS برای استایلالان تنها فقط یه تابع ساده که از روی داده‌ها، ظاهر می‌سازد . یعنی به جای اینکه بگی «چیکار کن»، فقط می‌گی چجوری باشه Declarative)) فکر کردن به جای گفتن «چیکار بکن»، می‌گی «چی باید باشه»2. Hooks:تو دنیای React، Hook ها مثل ابزارهای یه زبان جدید هستند. با useState حافظه تعریف می‌کنید، با useEffect اثرات جانبی رو مدیریت می‌کنید و با useMemo از تکرار جلوگیری می‌کند.useEffect(() =&gt; {
console.log( &amp;quotکاربر تغییر کرد&amp;quot ) ; }, [user]);3. طراحی از دل State بیرون میاد قبلاً طراحی از سمت UI بود یعنی ( اول Ul می‌ساختیم، بعد date را inject می‌کردیم )ولی حالا:اول state رو طراحی می‌کنیم، بعد UI رو طراحی می‌کنی، بعد ظاهر خودش درست می‌شه. این باعث می‌شه اول به «جریان داده» فکر کنی، نه ظاهر  با React یاد می‌گیریم که قبل از UI، به جریان داده فکر کنیم — این تغییر ذهنی، خیلی مهمه.4.  مدل ذهنی جدید Thinking in Reactدر React  توانایی این داریم  کامپوننت بسازیم ، State پاس بدیم و فقط باید بشینیم تماشا کنیم بقیه‌شو بسپار به خود React و  imperative نمی‌نویسیم و با data flow کار می‌کنیم. انگار داری با یه زبان فکر می‌کنی که &quot;Reactive&quot;، نه &quot;Imperative&quot; به طور خلاصه تو React فقط میگیم چی باید باشد (UI = function(state))، نه اینکه باید چطوری درستش کنیم . این باعث می‌شه تمرکزت بیشتر بر منطق برنامه باشه تا دستکاری کردن دستی DOM .5. نتیجه‌گیریشاید React از نظر فنی یه Library باشه، ولی برای خیلی از ما تبدیل شده به یه زبان فکری کامل  ما با JSX فکر می‌کنیم و با hooks برنامه‌ریزی می‌کنیم و با state طراحی می‌کنیم. اگه تو هم حس می‌کنی React فقط یه ابزار نیست، نظرتو برام بنویس. به نظرت این مدل ذهنی قراره آینده‌ی توسعه وب رو تغییر بده؟و خیلی دوست دارم نظر تو رو بدونمبه نظرت React واقعاً یه زبان جدیده؟ یا فقط یه ابزار خوبه که ما زیادی جدی گرفتیمش؟منتظر دیدگاه‌هاتم. تو هم مثل من فکر می‌کنی یا نه؟React, JSX, Hooks, State Management,React, useEffect, useState,React,declarative,کامپونن, زبان برنامه‌نویسی,طراحی رابط کاربری, توسعه وب</description>
                <category>محمدامین رعدی</category>
                <author>محمدامین رعدی</author>
                <pubDate>Sun, 20 Apr 2025 23:32:13 +0330</pubDate>
            </item>
            </channel>
</rss>