https://virgool.io/feed/@siavash.aghazadeh Front-end Developer fa 2026-07-06 18:58:42 https://files.virgool.io/upload/users/3161658/avatar/nxHg4i.jpg?height=120&width=120 https://virgool.io/@siavash.aghazadeh https://virgool.io/@siavash.aghazadeh/react-design-patterns-part-2-o2ft6pyrmifr بریم سراغ پارت دومِ Design Pattern های توی React. یه مشکل اساسی که من داشتم این بود که به صورت مفهومی دوتا از پترن های مهم Factory و Adapter رو درست متوجه نمیشدم. که اینجا مفهومی و با مثال بهشون پرداختم تا درکشون راحت تر بشه. و اینکه به یکی از پر استفاده ترین ها یعنی Provider Pattern میپردازیم.❗️ فقط نکته اینکه مثال هایی که میزنم صرفا روش درستی برای هندل کردن اون مثال توی دنیای واقعی نیست، فقط برای درک اون پترن مثال هارو میزنم.Factory PatternAdapter PatternProvider Pattern1- Factory Patternفرض کن یه اپلیکیشن داری که برای مدیریت پرداخت‌ها ساخته شده. تو نسخه اول فقط پرداخت با کارت بانکی پشتیبانی میشه. همه کدت توی کامپوننتی به اسم BankCardPayment نوشته شده.بعد از مدتی، کاربران میگن:پرداخت با PayPal رو هم اضافه کن!پرداخت با کریپتو چی؟حالا اگه بخوای هر بار یه نوع پرداخت جدید اضافه کنی، باید کلی کد رو تغییر بدی و شرط بذاری ؛ مثلاً if (type === 'PayPal') یا if (type === 'Crypto')این باعث میشه کدت به مرور زمان شلوغ، پیچیده، و سخت برای نگهداری بشه.🎯 حالا ببینیم Factory Pattern چجوری این مشکل رو حل میکنه !با استفاده از این پترن، به جای اینکه خودت مستقیم تصمیم بگیری کدوم کلاس یا کامپوننت رو بسازی یا استفاده کنی، این تصمیم رو به یه کارخونه (Factory) واگذار میکنی. یعنی یه تابع یا آبجکت داری که بر اساس ورودی‌ها (مثل نوع، پارامترها یا شرایط)، به صورت داینامیک چیزی که لازمه رو می‌سازه یا برمی‌گردونه. این کار باعث میشه کدت تمیزتر، قابل گسترش‌تر و از نظر نگهداری راحت‌تر بشه، چون همه تصمیم‌گیری‌ها متمرکز و مستقل از بقیه کده.چطور با Factory Pattern حلش کنیم؟به جای اینکه توی یه فایل شرط‌های مختلف بذاری، میای یه ساختار انعطاف‌پذیر درست می‌کنی که بر اساس نوع پرداخت، کامپوننت مناسب رو برگردونه.در نتیجه Factory یه شاه‌کلیده برای ساخت کدهای تمیز و انعطاف‌پذیره. این الگو نه‌تنها بهت اجازه میده کامپوننت‌های مختلف رو بدون نیاز به شرط‌های پیچیده و شلوغ مدیریت کنی، بلکه روند اضافه کردن قابلیت‌های جدید رو هم آسون می‌کنه. با استفاده از Factory، کدت از یه سیستم بهم‌ریخته به یه معماری مرتب و قابل نگهداری تبدیل میشه.2- Adapter Patternفرض کنید شما در حال کار با یک سیستم هستید که از دو API مختلف برای دریافت اطلاعات کاربرا استفاده می‌کنه. یکی از این‌ها API قدیمی شرکت شماس و اون یکی یک سرویس جدید که اخیراً اضافه شده. هر کدوم از این‌ها داده‌ها رو با ساختار متفاوتی برمی‌گردونند. مشکل اینه که کل اپلیکیشن شما داره با یک ساختار ثابت با ریسپانس این سرویس ها کار میکنه. اگه قرار باشه از سرویس جدید استفاده کنید باید دوتا مورد رو در نظر بگیرید:هر جای اپلیکیشن از ساختار قدیمی استفاده کردین و آپدیت کنید و به ساختار جدید تغییر بدیندیگه نمیتونید از سرویس قدیمیه استفاده کنید.🎯 خب حالا Adapter Pattern چجوری مشکل و حل میکنه !؟این الگو با ایجاد یک لایه میانی به نام "آداپتر" عمل می‌کنه که مثل یک مترجم بین API‌های مختلف و کامپوننت‌های ما عمل می‌کنه. تصور کنید شما یک شارژر موبایل دارید که پریز برق رو به موبایلتون متصل می‌کنه. آداپتر هم دقیقاً همین کار رو انجام میده. برای هر API، یک آداپتر جداگانه می‌سازیم که می‌دونه داده‌های اون API رو چطور به فرمت استاندارد ما تبدیل کنه. مثلاً وقتی API قدیمی از user_id استفاده می‌کنه و API جدید از id، آداپتر مربوطه می‌دونه که باید این فیلدها رو به چه شکلی تبدیل کنه تا کامپوننت‌های ما بتونن باهاشون کار کنن. به این ترتیب، کامپوننت‌های ما فقط با یک ساختار داده استاندارد کار می‌کنن و نیازی نیست برای هر API تغییر کنن👌بریم که کدشو بزنیمبیایم ببینیم که هر کدوم از سرویس ها ساختار ریسپانسشون به چه شکلی هستش :تو مرحله اول میایم Adapter های هرکدوم از سرویس ها و interface رو مینویسیم :برای راحتی کار میایم یه کاستوم هوک هم مینویسم که fetch کردن دیتا و Adapte کردن دیتا رو هندل کنیم:بعد میریم سراغ کامپوننت نمایش userProfile و نحوه استفاده از اون کامپوننت :نکته اخر اینکه این دیزاین پترن هدفش این نیست که بیایم و از سرویس ها قدیمی و جدید به این شکل استفاده کنیم، بلکه بیشتر هدفش توی فرانت اینه که از third party libraries ها بهتر بتونیم استفاده کنیم. مثلا ما داریم از یک input توی Ant Design استفاده میکنیم، بنا به دلایلی تصمیم میگیریم که لایبری رو تغییر بدیم به MUI. اینجا نباید بریم توی کل اپلیکیشن و کلی تغییرات بدیم، به جاش میایم از یک Adapter استفاده میکنیم. که واقعا کارو آسون میکنه✌️3- Provider Patternیکی دیگه از پترن های React که تقریبا همیشه داریم ازش استفاده میکنیم، Provider Pattern هستش.فرض کنید، اطلاعاتی مثل تم (Theme) یا کاربر لاگین شده باید بین چندین کامپوننت به اشتراک گذاشته بشه. تاکید میکنم اینها روش درستی برای هدل کردن اینجور مثال ها نیستن، صرفا برای فهم این پترن ها همچین مثال هایی میزنم.اگر بخواهیم این اطلاعات را از طریق Props Drilling (ارسال داده از طریق پراپ‌ها) مدیریت کنیم، کد بسیار پیچیده و نامرتب می‌شود. که باعث میشه وقتی تعداد کامپوننت‌ها زیاد بشه، مدیریت داده هم سخت‌تر بشه و نکته مهم تر اینکه هر تغییری تو ساختار داده باید تو تمامی کامپوننت‌های زنجیره اعمال بشه.مثل این کد :🎯 ببینیم Provider Pattern چجوری مشکل و حل میکنه !در واقع این پترن یک پترن مدیریت استیت تو React هست که مشکل انتقال داده بین کامپوننت‌های عمیق رو حل می‌کنه. این پترن معمولاً با استفاده از Context API تو React پیاده‌سازی میشه.خب بریم برای پیاده سازی :اول یک context برای داده‌های مشترک می‌سازیم.یک کامپوننت که نقش Provider را ایفا می‌کنه، می‌سازیم و داده‌ها را تو اون قرار میدیم.قرار دادن Provider در بالاترین سطح (معمولا توی layout ها)استفاده از Context تو کامپوننت‌ها.❗️این نکته مهم و در نظر داشته باشین که؛ Provider Pattern بخشی از مفهوم State Management هستش، اما جایگزین کاملی برای اون نیست. خوده بحث State Management باید جداگونه بهش پرداخته بشه.پارت دوم هم تموم شد، ممنون میشم شما هم نظرات خودتونو یا هر سوالی درباره هرکدوم از پترن ها دارین باهام به اشتراک بزارین. منتظر پارت بعدی باشین 🙏امیدوارم مطالب مفید بوده باشه ✌️❤️ Siavash Aghazadeh Siavash Aghazadeh Fri, 22 Nov 2024 22:37:56 +0330 https://virgool.io/@siavash.aghazadeh/react-design-patterns-part-1-axui4xloh8pp سلام 👋من تصمیم گرفتم خیلی خلاصه و ساده بیام و بهترین و مهم ترین(هر چند نمیشه گفت که کدوم بهترینه) Design Pattern های ریکت و توضیح بدم تا درکشون خیلی راحت تر بشه. البته واقعا متوجه شدم به همشون توی یک پارت نمیشه پرداخت، و اینکه اگه بخوام همشون و توی یک پارت توضیح بدم طولانی میشه. پس نتیجه گرفتم چند تا پارتشون کنم ولی با مثال کامل برای هر کدوم. توی پارت اول به این پترن ها میپردازیم:Higher-Order Component (HOC)Render PropsContainer/PresentationalCompoundروش توضیح دادن هم اینجوریه که اول میام توضیح میدیم که اصلا مشکلمون چی بوده و بعد چجوری با اون پترن خاص حلش کردیم. بریم سر اصل مطلب.1- Higher-Order Component (HOC)گاهی اوقات تو پروژه‌های بزرگ، نیازه که رفتارهای مشترک بین چنتا کامپوننت تکرار بشه. مثلا اگر بخوایم قابلیت احراز هویت، مدیریت داده، یا لاگ‌گیری رو به چندین کامپوننت اضافه کنیم، می‌تونیم از HOC استفاده کنیم تا این رفتار مشترک رو تو یک مکان پیاده‌سازی و تو چندین کامپوننت به کار ببریم. به این شکل، از تکرار کد جلوگیری می‌شه و کد تمیزتر و قابل نگهداری‌تری خواهیم داشت.در نتیجه HOC یک تابعه که به عنوان ورودی یک کامپوننت دریافت می‌کنه و یک کامپوننت جدید با قابلیت‌ها و رفتارهای اضافی برمی‌گردونه.برای مثال :فرض کنید می‌خواهیم کاربرایی که وارد سیستم نشدن رو از دسترسی به بعضی صفحات مسدود کنیم. برای این کار، می‌تونیم یک HOC بنام withAuth بسازیم که فقط زمانی کامپوننت اصلی رو نمایش بده که کاربر وارد شده باشه.در نتیجه HOC یک پترن برای اشتراک‌گذاری منطق یا همون logic بین کامپوننت‌هاست. این الگو باعث میشه که بدون تغییر تو ساختار یا محتوای کامپوننت‌ها، ویژگی‌ها یا منطق جدیدی رو به اونها اضافه کنیم.این پترن یک تابعه که یک کامپوننت رو می‌گیره و یک کامپوننت جدید با ویژگی‌ها و منطق اضافه‌شده برمیگردونه.فقط باید دقت کرد که HOC ‌ها نباید state داخلی خودشون رو مدیریت کنن و باید فقط منطق و ویژگی‌ها رو به کامپوننت‌ها منتقل کنن.کلاً این پترن، ref را انتقال نمیده. (که البته با forwardRef حل میشه)در کل، Higher-Order Components به شما کمک می‌کنن تا کد تمیزتر، قابل نگهداری‌تر و انعطاف‌پذیرتر داشته باشید و منطق مشترک رو به راحتی تو پروژه‌های React خودتون استفاده کنید.2- Render Propsتو دنیای React، معمولاً یک کامپوننت مسئول رندر کردن محتوای خودشه. این کامپوننت می‌تونه داخل JSX، المنت‌های مختلفی رو رندر کنه. اما بعضی وقت ها ممکنه بخواهیم کنترل بیشتری روی نحوه‌ی رندر کردن محتوای داخل کامپوننت داشته باشیم، و اینجاست که مفهوم Render Prop وارد میشه.در واقع، Render Prop یک پراپه که به کامپوننت داده می‌شه و مقدار اون یک تابع هستش. این تابع در نهایت یک JSX element برمی‌گردونه که همونطور که می‌دونید، همون محتوای UI که باید رندر بشه هست. این ویژگی به کامپوننت این امکان رو می‌ده که رندرینگ خودش رو به تابعی که بهش داده شده واگذار کنه. بنابراین، کامپوننت خودش مستقیماً تصمیم نمی‌گیره که چه چیزی نمایش بده، بلکه تصمیم‌گیری رو به تابعی که از بیرون براش ارسال شده، می‌سپاره.البته این نکته رو هم در نظر داشته باشین که لازم نیست کل ui اون کامپوننت رو تغییر بدیم میتونیم حتی فقط قسمتی ازش رو منحصر به فرد کنیم. مثلا ما یک Card داریم که میخوایم فقط Header اون تو جاهای مختلف فرق کنهشاید گیج کننده باشه ولی بزارین با یک مثال راحت ترش کنم:ما یک کامپوننت به نام MouseTracker داریم که موقعیت فعلی موس رو ردیابی می‌کنه. کامپوننت MouseTracker هیچ چیزی رو به طور مستقیم رندر نمی‌کنه. بلکه از Render Prop استفاده می‌کنه تا به کامپوننت‌هایی که از اون استفاده میکنن، این امکان رو بده که نحوه‌ی نمایش موقعیت موس رو مشخص کنند.در نتیجه پترن Render Prop یک روش انعطاف‌پذیر برای مدیریت رندر کامپوننت‌ها تو React هستش که به ما این امکان رو میده که منطق رندرینگ رو از نمایش UI جدا کنیم. این پترن باعث میشه که کامپوننت‌ها قابل استفاده مجدد باشن و تغییرات تو نحوه‌ی نمایش داده‌ها راحت‌تر انجام بشه.با این حال، استفاده بیش از حد از این پترن میتونه کد رو پیچیده‌تر کنه و تو برخی مواقع روی عملکرد تأثیر منفی بزاره. بنابراین، بهتره از اون زمانی استفاده کنیم که نیاز به انعطاف‌پذیری بالا داریم و در غیر این صورت، ممکنه استفاده از روش‌های دیگه ساده‌تر و کارآمدتر باشه.3- Container/Presentational Patternفرض کنیم یک کامپوننت به نام UserProfile داریم که توی اون اطلاعات کاربر نمایش داده میشه و یکسری عملیات مثل ویرایش یا به‌روزرسانی اطلاعات کاربر هم انجام میشه. اگر بخوایم Logic و UI رو تو همین یک کامپوننت پیاده‌سازی کنیم، کد شلوغ و پیچیده‌ میشه.الگوی Container/Presentational که با نام‌های Container/View یا Smart/Dumb هم معروف هستش، یکی دیگه از Design Pattern هستش که به‌طور گسترده توی برنامه‌های React استفاده میشه. تو این پترن، کامپوننت‌ها به دو نوع Container و Presentational تقسیم میشن. هدف اصلیش هم جداسازی منطق و داده، از نحوه نمایش UI هستش. این جداسازی باعث میشه تغییرات تو نحوه نمایش یا منطق به راحتی انجام بشه بدون اینکه بخش های دیگه رو تحت تأثیر قرار بده.- البته یکی از معایبی که این پترن داره اینه که، تعداد کامپوننت های پروژه تقریبا دوبرابر میشه که اینم خودش باعث سردرگمی های زیادی میشه بین کامپوننت ها.- نیاز به ارسال تعداد زیادی props بین کامپوننت‌ها وجود داره، که مدیریت اون ها را دشوار می‌کنه. - ممکنه توی نام گذاری هاشون هم به مشکل بخوریم.بریم سراغ مثال : کامپوننت‌های Presentational فقط مسئول نمایش (UI) هستن. این کامپوننت‌ها از داده‌هایی که از والد خودشون (Container) به صورت props دریافت می‌کنن استفاده می‌کنن و معمولاً بدون هیچ منطق پیچیده ای هستن.کامپوننت‌های Container مسئول مدیریت داده‌ها و منطق هستن. این نوع کامپوننت‌ها معمولاً به Redux یا API‌ های خارجی وصل میشن و داده‌ها رو دریافت میکنن و به کامپوننت‌های Presentational ارسال می‌کنن.در نتیجه Container/Presentational با جداسازی منطق از UI به ما کمک می‌کنه تا کدی تمیزتر، قابل نگهداری‌تر و تست‌پذیرتر داشته باشیم. این پترن باعث می‌شه کامپوننت‌های ما بهتر ساختاربندی بشن: کامپوننت‌های Container فقط منطق و داده‌ها را مدیریت می‌کنن، و کامپوننت‌های Presentational صرفاً روی UI تمرکز دارن. با این جداسازی، توسعه و به‌روزرسانی برنامه آسون‌ تر میشه و استفاده مجدد از کامپوننت‌ها تو بخش‌های مختلف امکان‌پذیرتره.4- Compound Patternفرض کنیم شما یک فرم ورود (Login) ساده دارید که شامل فیلدهای نام کاربری، رمز عبور، دکمه‌ی ورود و پیام خطا هستش. مشکل اینجاست که همه این موارد باید به صورت مستقل از هم عمل کنن، اما با همدیگه به عنوان یک کامپوننت کامل یکپارچه بشن. مثلاً، اگر خطایی رخ بده، پیام خطا باید نمایش داده بشه؛ یا دکمه‌ی ورود فقط وقتی فعال بشه که کاربر اطلاعات مورد نیاز رو وارد کرده باشه. تو یک فرم پیچیده‌تر، ممکنه فیلدهای بیشتری هم وجود داشته باشن.پترن Compound به ما کمک می‌کنه کامپوننت‌های مرتبط رو به صورت یک مجموعه منسجم طراحی کنیم. تو این پترن، یک کامپوننت پدر (Container) با چنتا کامپوننت فرزند (Child) تعریف می‌شن و این کامپوننت‌های فرزند از طریق همین کامپوننت پدر به هم متصل و مرتبط می‌شن. این روش اجازه میده تا کاربر نهایی کنترل و انعطاف‌پذیری بیشتری روی ساختار داخلی کامپوننت‌ها داشته باشه و از اون‌ها در قالبی دلخواه استفاده کنه.بریم سراغ مثال :میایم یک کامپوننت پدر (LoginForm) ایجاد میکنیم. تو اینجا، کامپوننت‌های فرزند شاملLoginInput , LoginButoon و LoginErrorMessage هستن، و هر کدوم از این کامپوننت‌ها به وضعیت فرم از طریق Context دسترسی دارند.یکی دیگه از نکات مثبت این پترن اینه که هر بخش میتونه کاملا استایل مخصوص خودشو داشته باشهتوی مثال، این کامپوننت‌ها برای دسترسی به داده‌ها و متدهای مرتبط از LoginContext استفاده می‌کنند.اول میایم کامپوننت پدر رو ایجاد میکنیم :حالا توی همین کامپوننت، کامپوننت های فرزند رو هم ایجاد میکنیم:و الان باید کامپوننت های فرزند رو به کامپوننت پدر اضافه کنیم :نحوه استفاده از این کامپوننت هم به این صورت میشه :با این ساختار، هر بخش از فرم ورود به عنوان بخشی از LoginForm شناخته میشه و به صورت مرتب و دسته‌بندی شده در کد قرار می‌گیره. این روش باعث بهبود خوانایی، سازمان‌دهی بهتر و امکان استفاده‌ی ماژولار از کامپوننت‌ها میشه.پارت اول تموم شد، ممنون میشم شما هم نظرات خودتونو یا هر سوالی درباره هرکدوم از پترن ها دارین باهام به اشتراک بزارین. منتظر پارت بعدی باشین 🙏امیدوارم مطالب مفید بوده باشه ✌️❤️ Siavash Aghazadeh Siavash Aghazadeh Thu, 14 Nov 2024 21:36:03 +0330 https://virgool.io/@siavash.aghazadeh/%F0%9F%A7%A9-code-splitting-concept-nfyesaftvh67 یک مفهومی که توی بحث performance زیاد مطرح میشه همین code splitting هستش که برای خودم یکم زیاد واضح نبود برای همین تصمیم گرفتم دربارش بخوونم خیلی خلاصه وار اینجا توضیح بدم برای اینکه اصلا بفهمیم این مفهوم چیه باید بگیم 📦 Bundling چیه اول :در یک پروژه‌ی فرانت‌اند، معمولاً کدها به فایل‌های زیادی تقسیم می‌شن، وقتی این فایل‌ها رو به سرور می‌فرستیم و کاربر می‌خواد وب‌سایت ما رو باز کنه، مرورگر باید همه‌ی این فایل‌ها رو دانلود کنه تا بتونه صفحه رو کامل و درست نمایش بده. برای اینکه همه‌ی این فایل‌ها به صورت یکجا و بهینه به کاربر برسه، از فرآیندی به نام باندلینگ (Bundling) استفاده می‌کنیم. ابزارهایی مثل Webpack به ما کمک می‌کنن تا کدهای پروژه رو در قالب یک یا چند فایل بزرگ‌تر (به نام باندل) به مرورگر ارسال کنیم. این باندل شامل تمام فایل‌ها و وابستگی‌های پروژه می‌شه که به یک مجموعه‌ی قابل اجرا تبدیل می‌شن.💡چرا باندلینگ مهمه؟باندلینگ به ما کمک می‌کنه تا:تعداد درخواست‌ها به سرور رو کاهش بدیم: با ترکیب چندین فایل به یک یا چند باندل، تعداد درخواست‌های HTTP کم‌تر می‌شه، که این باعث بهبود زمان بارگذاری (load time) می‌شه.بهینه‌سازی برای مرورگر: باندلرها کدها رو بهینه می‌کنن؛ مثلاً با حذف فضای خالی (minification)، کدهای بلااستفاده (tree shaking) و فشرده‌سازی.فرض کنید یک باندل خیلی بزرگ داریم که کل پروژه داخلشه. هر بار که کاربر صفحه‌ی ما رو باز می‌کنه، باید کل باندل دانلود بشه، حتی اگه فقط بخشی از اون لازم باشه، باید چه کنیم ؟ اینجاست که Code Splitting وارد می‌شه.🎯 حالا Code Splitting چیه؟در واقع Code Splitting تکنیکی هست که باهاش کدهای پروژه به بخش‌های کوچیک‌تر و مستقل به اسم chunk تقسیم می‌شه که این درواقع شامل کد های خود برنامه و هر گونه وابستگی های جانبی (third-party dependencies) میشه. این روش کمک می‌کنه تا فقط همون بخش‌هایی از کد لود بشه که کاربر نیاز داره ببینه یا استفاده کنه. مثلاً وقتی یک وب‌سایت چندین صفحه یا کامپوننت داره، لازم نیست همه‌ی کدها از همون اول لود بشن و می‌تونیم بخش‌های غیرضروری رو نگه داریم تا وقتی کاربر به اون صفحه یا کامپوننت خاص میره، اون کدها بارگذاری بشن.این تکنیک بیشتر برای بهبود Performance و بهینه‌سازی تجربه کاربری استفاده می‌شه. با کاهش حجم کد اولیه‌ای که به مرورگر فرستاده می‌شه، زمان لود صفحات کاهش پیدا می‌کنه و به همین دلیل Largest Contentful Paint (LCP) و Time to Interactive (TTI) بهبود پیدا می‌کنه.بهبود سرعت بارگذاری اولیه: چون کاربر نیازی به کل کد پروژه نداره، فقط بخش‌های ضروری لود می‌شن.کاهش مصرف منابع: این کار منابع سیستم کاربر رو کمتر مصرف می‌کنه و تجربه بهتری فراهم می‌کنه.📂 انواع روش‌های Code Splittingکد اسپلیتینگ در جاوا اسکریپت مدرن و به‌خصوص در Webpack، رایج‌ترین ابزار باندلینگ در فرانت‌اند، به چندین روش مختلف قابل پیاده‌سازی هست:روش Entry Points: با تعیین چندین Entry Point در تنظیمات باندلر (مثل Webpack)، می‌شه بخش‌های مختلفی از پروژه رو جداگانه باندل کرد. این روش برای پروژه‌های چند صفحه‌ای (multi-page applications) بسیار کاربردیه. (ایمپورت داینامیک) Dynamic Imports: استفاده از import() به صورت دینامیک، یکی از ساده‌ترین و کاربردی‌ترین روش‌ها برای پیاده‌سازی Code Splitting هست. این روش، به باندلر می‌گه که کد مورد نظر رو به یک فایل جداگانه تبدیل کنه و فقط وقتی که نیاز بود، اون فایل رو دانلود کنه.Dynamic Importsاستفاده از React.lazy و Suspense در ریکت: در ریکت، از React.lazy و Suspense می‌تونیم برای اسپلیت کردن کامپوننت‌ها استفاده کنیم. این به ما اجازه می‌ده که هر کامپوننت رو به صورت جداگانه لود کنیم و فقط وقتی کاربر به اون بخش از صفحه میره، کدش دانلود بشه.Code Splitting in React(کد اسپلیتینگ بر اساس مسیر) Route-based Splitting: در برنامه‌های تک‌صفحه‌ای یا همون (Single Page Applications - SPAs)، یکی از موثرترین روش‌ها برای اسپلیت کردن کدها، تقسیم اون‌ها بر اساس مسیرهای مختلفه. مثلاً هر مسیر اصلی می‌تونه کامپوننت‌ها و استایل‌های خودش رو به صورت مستقل داشته باشه و فقط وقتی به اون مسیر رفتیم، دانلود بشه.Route based Splitting📈 نتیجه‌گیری نهاییبا استفاده‌ی درست از Code Splitting می‌تونید:حجم کدهای ارسالی به مرورگر رو کاهش بدیدتجربه کاربری بهتری ایجاد کنیدو هزینه‌های لود و پردازش کد رو بهینه کنیداین تکنیک برای پروژه‌های بزرگ و پیچیده بسیار مهمه، و در ترکیب با استراتژی‌های دیگه مثل Lazy Loading، Tree Shaking و Prefetching می‌تونه تفاوت زیادی در عملکرد و کارایی پروژه ایجاد کنه.امیدوارم مفید بوده باشه ✌️❤️ Siavash Aghazadeh Siavash Aghazadeh Thu, 07 Nov 2024 06:11:28 +0330