‏**Nuxt نسخهٔ چهارم رسماً منتشر شده است!
🔗 [جزئیات بیشتر](https://nuxt.com/blog/v4)

این نسخه شامل مجموعه‌ای از بهبودهای مهم و کاربردی است:

🐤 **تغییر ساختار پوشه‌های پروژه (یا همان معماری): اکنون با ساختار جدید شامل app/`، `server/ و modules/.

✨ بازطراحی کامل useAsyncData و useFetch: اکنون از واکنش‌گرایی سطحی (shallow reactivity)، مقدار پیش‌فرض undefined و اشتراک داده‌ها بین کامپوننت‌ها پشتیبانی می‌شود.

🍙 سادگی در tsconfig: حالا فقط یک فایل در ریشهٔ پروژه کافی است.

🩹 هماهنگ‌سازی نام‌گذاری خودکار کامپوننت‌ها: از این پس نام‌ها به‌صورت یکنواخت در ابزار توسعه، ویژگی KeepAlive و سیستم Auto Import نمایش داده و استفاده می‌شوند.

📦 آمادهٔ ارتقا هستید؟
📘 [راهنمای مهاجرت به Nuxt 4](https://nuxt.com/docs/4.x/getting-started/upgrade#upgrading-nuxt)

📅 نگران نباشید اگر هنوز آماده نیستید —
پشتیبانی از Nuxt 3 تا پایان سال ۲۰۲۵ ادامه دارد، و Nuxt 4 تا میانهٔ سال ۲۰۲۶ پشتیبانی خواهد شد.

در ضمن، نسخهٔ سوم Nitro هم به‌زودی منتشر می‌شود و پایه‌ای برای Nuxt 5 خواهد بود.



#️⃣#tool
👥@IR_javascript_group
🆔@IR_javascript

Dockview
Dockview یک کتابخانهٔ جاوااسکریپت است که برای ساخت رابط‌های کاربری پنلی پیشرفته، مشابه آن‌چه در محیط‌های توسعهٔ یکپارچه (IDE) مدرن دیده می‌شود، طراحی شده است. این کتابخانه از پنل‌هایی که قابل جابجایی**، **چسباندن (Docking) و تغییر اندازه هستند پشتیبانی می‌کند.

گزینه‌ای مناسب برای توسعهٔ وب‌اپلیکیشن‌هایی است که نیاز به یک فضای کاری منعطف و قابل تنظیم دارند.


🔗https://dockview.dev/
#️⃣#npm_module
👥@IR_javascript_group
🆔@IR_javascript

برای علاقه‌مندان به آزمایش دستیارهای هوش مصنوعی، شرکت AWS نسخه‌ای اختصاصی از Visual Studio Code با قابلیت‌های هوش مصنوعی ارائه کرده است که با نام Kiro شناخته می‌شود.


ویژگی متمایز Kiro آن است که بر اساس مشخصات پروژه (spec-driven) عمل می‌کند؛ به این معنا که کاربر ابتدا باید مشخصات و نیازمندی‌های پروژه را تعریف کند و سپس Kiro بر مبنای همان مشخصات، ساختار و کدهای پروژه را تولید می‌نماید.

این رویکرد بسیار هوشمندانه است. البته می‌توان این روند را به‌صورت دستی نیز پیاده‌سازی کرد، اما نکته قابل توجه این است که در Kiro این منطق به‌صورت درونی در الگوریتم آن طراحی شده است.

در حال حاضر، استفاده از Kiro رایگان است و این ابزار از مدل Claude Sonnet ۴ بهره می‌برد.

🔗https://kiro.dev/blog/introducing-kiro
#️⃣#tool
👥@IR_javascript_group
🆔@IR_javascript

آیا تا به حال خواسته‌اید پیش از بسته‌شدن صفحهٔ وب توسط کاربر، اطلاعاتی را ذخیره کنید؟

در جاوااسکریپت رویدادهایی وجود دارد که با استفاده از آن‌ها می‌توان درخواست‌هایی به سرور ارسال کرد تا داده‌های مفید ذخیره شوند. اما دقت داشته باشید که در این موقعیت‌ها، درخواست‌های همگام (synchronous) قابل استفاده نیستند؛ تنها روش‌های ناهمگام مانند fetch یا sendBeacon قابل اتکا هستند.

متأسفانه بسیاری از اپلیکیشن‌های وب در این زمینه عملکرد درستی ندارند، چرا که چرخهٔ عمر برنامه در موبایل را در نظر نمی‌گیرند: یا به رویدادهایی گوش می‌دهند که ممکن است اصلاً اجرا نشوند، یا این مشکل را به‌طور کلی نادیده می‌گیرند، که در نهایت منجر به تجربه‌ای ضعیف برای کاربر می‌شود. البته باید منصف بود؛ پلتفرم وب نیز با ارائهٔ رویدادهای متنوعی مانند visibilityState، pageshow، pagehide، beforeunload و unload، کار را ساده نکرده است. حال سوال اینجاست: از کدام رویداد باید استفاده کرد و چه زمانی؟

چرا نمی‌توان روی رویدادهای unload و beforeunload حساب کرد؟
در پلتفرم‌های موبایل نمی‌توان انتظار داشت که رویدادهای pagehide، beforeunload یا unload همیشه اجرا شوند. این مسئله ایرادی در مرورگر مورد علاقهٔ شما نیست؛ بلکه ناشی از نحوهٔ عملکرد سیستم‌عامل‌های موبایل است. یک اپلیکیشن فعال می‌تواند به چند روش وارد وضعیت پس‌زمینه شود:

+ کاربر روی یک اعلان کلیک کرده و وارد اپلیکیشن دیگری شود؛
+ کاربر با استفاده از تسک‌سوئیچر (Task Switcher) به برنامه‌ای دیگر برود؛
+ با زدن دکمهٔ "خانه" به صفحهٔ اصلی گوشی بازگردد؛
+ سیستم‌عامل به‌صورت خودکار برنامه را به پس‌زمینه ببرد — مثلاً هنگام دریافت تماس.

پس از آن، اپلیکیشن می‌تواند بدون هیچ هشدار خاصی خاتمه یابد — مثلاً سیستم‌عامل فرآیند را برای آزادسازی منابع متوقف کند، یا کاربر برنامه را از تسک‌منیجر حذف کند. بنابراین باید فرض را بر این گذاشت که خاموشی‌های "تمیز" که در آن رویدادهایی مانند pagehide و unload اجرا می‌شوند، استثناء هستند، نه قاعده.

‏Page Visibility API این امکان را برای توسعه‌دهندگان فراهم می‌سازد تا از وضعیت نمایش یا پنهان بودن صفحه آگاه شوند.

این API عمدتاً از ویژگی‌ها و رویدادهای زیر بهره می‌برد:

‏* document.visibilityState: یک رشته (string) برمی‌گرداند که نشان‌دهندهٔ وضعیت کنونی سند است. مقادیر ممکن شامل visible (قابل‌مشاهده) و hidden (پنهان) می‌باشد.
* رویداد visibilitychange: هنگامی اجرا می‌شود که وضعیت نمایش سند تغییر کند.

با استفاده از این API، می‌توانید رفتار اپلیکیشن خود را بر اساس قابل‌مشاهده بودن یا نبودن صفحه تنظیم کنید.

---

### نمونهٔ پیاده‌سازی

کد زیر نشان می‌دهد که چگونه می‌توان هنگام قابل‌مشاهده شدن صفحه، یک پیام هشدار نمایش داد:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
  <title>Visibility Test</title>
  <script>
    function updateVisibility() {
      if (document.visibilityState === 'visible') {
        alert('صفحه اکنون قابل‌مشاهده است');
      }
    }

    document.addEventListener("visibilitychange", updateVisibility);

    // بررسی وضعیت اولیهٔ نمایش صفحه
    updateVisibility();
  </script>
</head>
<body>
  <h1>صفحهٔ آزمایشی</h1>
  <p>این یک صفحهٔ تست برای بررسی رویدادهای تغییر در نمایش است.</p>  
</body>
</html>

در این مثال، تابع updateVisibility بررسی می‌کند که آیا صفحه در حال حاضر قابل‌مشاهده است یا نه، و در صورت تأیید، پیام هشدار را نمایش می‌دهد. این تابع هم هنگام بارگذاری صفحه و هم هنگام تغییر وضعیت نمایش فراخوانی می‌شود.

### چه زمانی مقدار document.visibilityState برابر با visible است؟

وضعیت visible در شرایط زیر فعال می‌شود:

* بازگشت به تب از تب دیگر:
کاربر از تب دیگری به تب شما بازمی‌گردد.

* بازیابی پنجرهٔ کوچک‌شده:
کاربر مرورگر را مینیمایز کرده و سپس مجدداً باز می‌کند.

* بازگشت از یک اپلیکیشن دیگر به مرورگر:
کاربر پس از استفاده از برنامه‌ای دیگر، به مرورگری که صفحهٔ شما در آن باز است برمی‌گردد.

* بازکردن قفل دستگاه:
کاربر دستگاه را آنلاک می‌کند و مرورگر (و صفحهٔ شما) دوباره به نمایش درمی‌آید.

در این سناریوها، وضعیت صفحه از حالت «پنهان» به حالت «قابل‌مشاهده» تغییر می‌کند و رویداد visibilitychange اجرا می‌شود.

---

### جمع‌بندی

‏Page Visibility API ابزاری بسیار مفید برای شناسایی بازگشت کاربر به صفحه است. این امکان را به شما می‌دهد که اقدامات خاصی نظیر به‌روزرسانی محتوا یا ادامهٔ پخش رسانه را اجرا کنید.
با پایش وضعیت نمایش صفحه، می‌توانید تجربهٔ کاربری را ارتقا دهید و از منابع سیستم به‌صورت بهینه استفاده کنید.

برای اطلاعات و نمونه‌های بیشتر، به [مستندات MDN دربارهٔ Page Visibility API](https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API) مراجعه فرمایید.


#️⃣#tip
👥@IR_javascript_group
🆔@IR_javascript

۸ ابزار رایگان برای طراحی وایرفریم و نمونه‌سازی (Prototyping):

🔸 Figma
🔸 Adobe XD
🔸 Wireframe.cc
🔸 FluidUI
🔸 Mockflow
🔸 Moqups
🔸 Cacoo
🔸 Jumpchart

این ابزارها برای طراحی رابط کاربری، ترسیم طرح‌های اولیه و شبیه‌سازی تعاملات کاربر بسیار کاربردی و مؤثر هستند.

#️⃣#tool
👥@IR_javascript_group
🆔@IR_javascript

❔ تابع `hsla()` چگونه کار می‌کند؟

تابع hsla() که پارامترهای آن به ترتیب نشان‌دهندهٔ تون رنگ (Hue)**، **اشباع رنگ (Saturation)**، **روشنایی (Lightness) و کانال آلفا (Alpha) هستند، برای تعیین رنگ‌های نیمه‌شفاف نیز به‌کار می‌رود.

تون رنگ (Hue) با استفاده از درصدهایی بر مبنای دایرهٔ رنگ مشخص می‌شود. این دایره به بخش‌هایی تقسیم شده که هر کدام نمایندهٔ یکی از رنگ‌های اصلی یا فرعی هستند:

* ۰ یا ۳۶۰ درجه — رنگ قرمز
* ۶۰ درجه — رنگ زرد
* ۱۲۰ درجه — رنگ سبز
* ۱۸۰ درجه — رنگ آبی روشن (فیروزه‌ای)
* ۲۴۰ درجه — رنگ آبی تیره
* ۲۷۰ درجه — رنگ بنفش
* ۳۰۰ درجه — رنگ ارغوانی (سرخابی)

برای به‌دست آوردن رنگ سیاه**، باید مقدار **تون، اشباع و روشنایی را برابر با صفر قرار دهید:
hsla(0, 0%, 0%, 1)

رنگ سفید با روشنایی صد درصد و صفر بودن تون و اشباع حاصل می‌شود:
hsla(0, 0%, 100%, 1)

و برای تولید رنگ **خاکستری**، کافی‌ست اشباع برابر صفر و روشنایی پنجاه درصد باشد:
hsla(0, 0%, 50%, 1)


#️⃣#tip #css
👥@IR_javascript_group
🆔@IR_javascript

طراحی تطبیقی (Adaptive Design) VS طراحی واکنش‌گرا (Responsive Design)

### اصل کارکرد

#### طراحی تطبیقی (Adaptive Design)

🔹 نقاط توقف (Breakpoints):
در این روش، وضوح‌های مشخص و ثابتی تعریف می‌شوند — برای مثال، سیصد و بیست، هفت‌صد و شصت و هشت، هزار و بیست و چهار، و هزار و چهارصد و چهل پیکسل. برای هر یک از این نقاط، یک طرح (layout) مجزا طراحی می‌گردد.

🔹 سبک‌ها و منابع مجزا:
برای هر breakpoint می‌توان تصاویر بهینه‌شده بارگذاری کرد، محتوایی را فعال یا غیرفعال نمود، یا حتی مجموعه فونت‌های خاصی را به کار گرفت.

🔹 سناریوهای بارگذاری:
در زمان رندر صفحه، سیستم تصمیم می‌گیرد که بر اساس عرض صفحه‌نمایش، کدام طرح و سبک را فعال کند.

---

#### طراحی واکنش‌گرا (Responsive Design)

🔹 شبکه‌ی انعطاف‌پذیر:
صفحه‌بندی با استفاده از واحدهای نسبی مانند درصد، em/rem، یا vw/vh ساخته می‌شود.

🔹 گذارهای روان:
المان‌ها به‌صورت خودکار با تغییر عرض مرورگر تغییر اندازه می‌دهند و جابه‌جا می‌شوند، بدون نیاز به پرش یا تغییر ناگهانی طرح.

🔹 کد یکپارچه:
یک مجموعه واحد از قوانین CSS برای تمامی دستگاه‌ها کافی است، و media query‌ها صرفاً برای تنظیم جزئیات و تفاوت‌های ظریف استفاده می‌شوند.

### مزایا و معایب

---

### طراحی تطبیقی (Adaptive Design)

#### ✅ مزایا:

* کنترل دقیق بر هر طرح:
برای هر وضوح صفحه، می‌توان طراحی ویژه و کاملاً کنترل‌شده‌ای ارائه داد.

* بهینه‌سازی منابع:
در نسخه‌های موبایلی، تصاویر سبک‌تر و فونت‌های کم‌حجم‌تر استفاده می‌شود که باعث کاهش حجم و افزایش سرعت بارگذاری می‌گردد.

* تجربه کاربری دقیق در نقاط کلیدی:
در نقاط توقف تعریف‌شده، تجربه کاربری دقیق و از پیش طراحی‌شده‌ای فراهم می‌شود.

#### ❌ محدودیت‌ها:

* ناهمخوانی بین نقاط توقف:
ممکن است در فاصله بین breakpoints، تغییرات ناهموار یا ظاهر نامنظمی دیده شود.

* نیاز به نگهداری چندین طرح و منبع:
برای هر وضوح باید نسخه‌ای جداگانه از طراحی، تصاویر و فایل‌های CSS مدیریت شود.

* پشتیبانی ضعیف از وضوح‌های جدید:
در صورت اضافه‌شدن دستگاه‌های با ابعاد جدید، ممکن است آن‌ها در هیچ‌کدام از breakpoints موجود قرار نگیرند.

---

### طراحی واکنش‌گرا (Responsive Design)

#### ✅ مزایا:

* گذارهای روان در تمامی عرض‌ها:
بدون پرش یا تغییر ناگهانی، اجزا به‌صورت نرم و تدریجی با تغییر عرض تطبیق پیدا می‌کنند.

* کد CSS یکپارچه و تکرار کمتر:
با استفاده از یک مجموعه قوانین واحد، می‌توان برای همه دستگاه‌ها طراحی کرد و از افزونگی جلوگیری نمود.

* تطبیق خودکار با دستگاه‌های جدید:
بدون نیاز به طراحی مجدد، طرح موجود به‌صورت پویا با دستگاه‌های جدید هم‌ساز می‌شود.

#### ❌ محدودیت‌ها:

* سختی در تنظیم دقیق رابط‌های پیچیده:
تنظیم جزئیات دقیق و رفتار المان‌ها در تمام عرض‌های ممکن، به‌ویژه برای رابط‌های پیچیده، دشوار است.

* احتمال کاهش خوانایی در محتوای زیاد:
در صفحات پرمحتوا، تطبیق خودکار ممکن است باعث به‌هم‌ریختگی و افت کیفیت خوانایی شود.

* محاسبات بیشتر و تأثیر بر عملکرد:
تغییرات پویا ممکن است فشار بیشتری به مرورگر وارد کرده و عملکرد کلی را کاهش دهد.

بسیاری طراحی *تطبیقی* (Adaptive) و طراحی *واکنش‌گرا* (Responsive) را با هم اشتباه می‌گیرند — چون هر دو به نوعی «متناسب با صفحه‌نمایش» عمل می‌کنند. اما در واقع این دو، رویکردهایی متفاوت هستند. یکی بر اساس سناریوهای از پیش تعریف‌شده کار می‌کند، و دیگری به‌صورت آنی و پویا خود را با شرایط جدید تطبیق می‌دهد. برای آنکه در اصطلاحات سردرگم نشویم و بدانیم کدام روش در پروژه مناسب‌تر است، بیایید بررسی کنیم هر یک چگونه عمل می‌کند، چه کاربردی دارد، و چگونه می‌توان آن‌ها را با یکدیگر ترکیب کرد.



---

👩‍💻 چگونه در عمل استفاده کنیم؟

✔️ پرتال سازمانی: شامل جداول، نمودارها و فرم‌های متعدد است — در این حالت طراحی تطبیقی به‌منظور کنترل دقیق روی وضوح‌های کلیدی ضروری است.

✔️ بلاگ یا لندینگ‌پیج: دارای محتوای سبک و تصویری است — طراحی واکنش‌گرا در این موارد، سازگاری روان و نگهداری ساده‌تر را فراهم می‌کند.

✔️ فروشگاه اینترنتی (E‑commerce): کارت‌های واکنش‌گرا برای نمایش کالا + مراحل تطبیقی در فرایند پرداخت، تجربه کاربری پایدار و مؤثری را تضمین می‌کنند.

---

💡 توصیه‌های عملی:

⭐️ نقاط توقف (breakpoint) را به حداقل برسانید. برای طراحی تطبیقی، داشتن سه تا پنج وضوح اصلی کافی است. اگر تعداد آن‌ها زیاد شود، نگهداری پروژه پیچیده‌تر خواهد شد.

⭐️ از ابزارهای کمکی استفاده کنید. فریم‌ورک‌هایی مانند Tailwind یا ابزارهای CSS اختصاصی شما، ساخت شبکه‌های واکنش‌گرا و مدیریت breakpoints را ساده‌تر می‌کنند.
⭐️ روی دستگاه‌های واقعی تست کنید. ابزار Chrome DevTools خوب است، اما آزمایش روی گوشی‌ها و تبلت‌های واقعی، تفاوت‌های ظریفی را که در شبیه‌ساز دیده نمی‌شوند، آشکار می‌کند.

---

🔧 بهترین راهکار، استفاده از ترکیب این دو رویکرد است: بگذارید رابط کاربری نسبت به همه اندازه‌های صفحه واکنش نشان دهد، و در بخش‌های بحرانی، با دقت پیکسلی تطبیق یابد. کارت‌های واکنش‌گرا همراه با فرم‌های تطبیقی، راهکاری متعادل، کارآمد و هوشمندانه برای طراحی رابط کاربری فراهم می‌سازد.



#️⃣#tip
👥@IR_javascript_group
🆔@IR_javascript

چند روز پیش گوگل از قابلیت جدیدی به نام [Speculation API](https://developer.chrome.com/docs/web-platform/prerender-pages) رونمایی کرد.

این API به شما امکان می‌دهد که پیش از بارگذاری واقعی، یک منبع را از پیش بارگیری یا حتی رندر کنید:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

توسعه‌دهنده می‌تواند به مرورگر اعلام کند که صفحاتی را که احتمال زیادی دارد کاربر به آن‌ها مراجعه کند، در پس‌زمینه بارگذاری کند. در نتیجه، آن صفحات تقریباً به‌صورت آنی باز خواهند شد.
(جالب است بدانید VitePress همین کار را به‌صورت پیش‌فرض برای مقالهٔ بعدی انجام می‌دهد.)

🔧 این قابلیت بیشترین کارایی را در پروژه‌های SSR و وب‌سایت‌های MPA دارد. در مقابل، برای SPAها چندان سودی ندارد، چون به‌طور کلی در مسیریابی داخلی، سرعت خوبی دارند.

🌐 در حال حاضر این قابلیت در مرورگرهای Chrome و Microsoft Edge پشتیبانی می‌شود.

📶 کاربران با اینترنت ضعیف یا گران‌قیمت احتمالاً با دیدن این ویژگی، ایستاده کف می‌زنند!


#️⃣#tip
👥@IR_javascript_group
🆔@IR_javascript

‏### 🔧 Override در pnpm یعنی چی و چرا بهش نیاز داریم؟

در پروژه‌های جاوااسکریپتی، مخصوصاً وقتی از ابزارهایی مثل pnpm یا npm استفاده می‌کنیم، پکیج‌ها ممکنه به‌صورت زنجیره‌ای به نسخه‌های مختلفی از یک کتابخانه وابسته باشن.

📌 مثلاً فرض کن پروژه‌ت از لایبرری foo استفاده می‌کنه، و foo خودش به lodash@4.17.20 وابسته‌ست.
از طرف دیگه، یه لایبرری دیگه (مثل bar) هم از lodash@4.17.15 استفاده می‌کنه.

در نتیجه، توی node_modules`، **دو نسخه مختلف از `lodash** نصب می‌شن.

📦 این باعث می‌شه:

* حجم نهایی پروژه بیشتر بشه
* احتمال بروز ناسازگاری و باگ بالا بره
* دیباگ کردن سخت‌تر بشه

---

### ✅ اینجاست که override وارد میشه!

با override می‌تونی به pnpm بگی:
«هر پکیجی که `lodash` رو می‌خواد، فقط از نسخه‌ای استفاده کن که من می‌گم.»

### 🧩 مثال واقعی:

فرض کن پروژه‌ت از چند مسیر مختلف نیاز به jsesc داره، ولی نسخه‌هاش فرق دارن:

‏* chalk از jsesc@2.5.2 استفاده می‌کنه
* یه لایبرری دیگه از jsesc@3.0.2

حالا تو می‌خوای همه از نسخه ۳.۰.۲ استفاده کنن، چون نسخه قدیمی مشکل امنیتی یا باگ داره.

در این صورت، این‌طوری توی package.json override می‌ذاری:

"pnpm": {
  "overrides": {
    "jsesc": "3.0.2"
  }
}

با این کار:

‏* pnpm جلوی نصب نسخه‌های دیگه‌ی jsesc رو می‌گیره
* همه پکیج‌ها از همون نسخه‌ای استفاده می‌کنن که تو تعیین کردی
* پروژه سبک‌تر و قابل پیش‌بینی‌تر می‌شه

---

### 💡 نتیجه:

‌‏`override` یه ابزار قدرتمند برای مدیریت نسخه‌ی پکیج‌هاست.
به‌ویژه در پروژه‌های بزرگ با وابستگی‌های زیاد، کمک می‌کنه:

* از چند نسخه‌ای شدن جلوگیری بشه
* ناسازگاری‌های ناگهانی برطرف بشه
* همه‌چیز یکدست و قابل کنترل باشه ✅


#️⃣#tip
👥@IR_javascript_group
🆔@IR_javascript

🎯 شناسایی و اعمال override پکیج‌ها در `package.json`


در پست قبل راجع به تعریف override صحبت شد اینکه گاهی تو پروژه‌های بزرگ با چند نسخه از یه پکیج خاص در node_modules روبه‌رو می‌شی. این می‌تونه باعث سنگین شدن پروژه، ناسازگاری، یا حتی بروز باگ بشه.

برای شناسایی این موارد، می‌تونی از کامند زیر در PowerShell استفاده کنی:

Get-ChildItem -Path "E:\p\sd\front\node_modules" -Directory -Recurse | Where-Object { $_.Name -match '^[^@]+@\d+(\.\d+)*$' }

📂 این دستور فولدرهایی از node_modules رو فیلتر می‌کنه که به شکل package@version نام‌گذاری شدن. مثلاً:

jsesc@2.5.2
jsesc@3.0.2
ansi-regex@5.0.1

یعنی چند نسخه مختلف از یه پکیج توی پروژه‌ت وجود داره.

---

🔍 حالا اگه خواستی بدونی یه پکیج چرا نصب شده و از طرف کدوم وابستگی‌ها اومده، از دستور pnpm why استفاده کن:

pnpm why jsesc

✅ خروجی ممکنه چیزی شبیه این باشه:

jsesc@3.0.2
└─ ansi-regex@5.0.1
   └─ strip-ansi@6.0.1
      └─ chalk@4.1.2
         └─ your-project > some-lib > chalk

این دستور مسیر وابستگی رو نشون می‌ده و مشخص می‌کنه کدوم پکیج، jsesc رو وارد پروژه کرده.

---

می‌خوای همه نسخه‌های مختلف یک پکیج رو مجبور کنی که فقط از یک نسخه خاص استفاده کنن. اینجاست که قابلیت pnpm.overrides وارد عمل می‌شه.

با اضافه کردن بخش زیر به package.json:

"pnpm": {
  "overrides": {
    "jsesc": "3.0.2"
  }
}

تمام لایبرری‌هایی که از jsesc استفاده می‌کنن، حالا مجبور می‌شن فقط از نسخه `۳.۰.۲` استفاده کنن — حتی اگه خودشون نسخه دیگه‌ای رو درخواست کرده باشن.

این تکنیک بهش می‌گن core override. ابزاری قوی برای مدیریت وابستگی‌ها در پروژه‌های پیچیده.

---

📦 نتیجه:
✔️ وابستگی‌های یکدست
✔️ حذف نسخه‌های اضافه
✔️ کاهش حجم نهایی
✔️ افزایش ثبات و پایداری پروژه


#️⃣#tip
👥@IR_javascript_group
🆔@IR_javascript

### آشنایی با ویژگی جالبی به نام touch-action 🤫

زمانی که برای دستگاه‌های موبایل یا نمایشگرهای لمسی وب‌اپلیکیشن توسعه می‌دهیم، مدیریت دقیق ژست‌های لمسی کاربران—مانند سوایپ، اسکرول یا بزرگ‌نمایی—اهمیت زیادی پیدا می‌کند. در این میان، ویژگی CSS به نام touch-action به کمک ما می‌آید.

این ویژگی به ما امکان می‌دهد کنترل کنیم که عناصر صفحه در برابر رویدادهای لمسی چگونه واکنش نشان دهند و می‌توانیم از انجام خودکار برخی رفتارهای پیش‌فرض مرورگر جلوگیری کنیم.

---

### touch-action دقیقاً چه کاری انجام می‌دهد؟ 🧐

به‌طور پیش‌فرض، مرورگرها خودشان ژست‌های لمسی را تفسیر و اجرا می‌کنند. این موضوع ممکن است در عملکرد برخی برنامه‌ها اختلال ایجاد کند، چرا که مرورگر می‌تواند در پردازش رویدادها دخالت کند.

با استفاده از touch-action می‌توانیم مشخص کنیم که کدام رفتارها را مرورگر باید پردازش کند و کدام‌ها را اپلیکیشن. این امکان به‌ویژه برای جلوگیری از رفتارهای ناخواسته، مانند اسکرول ناگهانی یا بزرگ‌نمایی ناخواسته، بسیار مفید است.

---

### چرا استفاده از touch-action ضروری است؟ 🤕

یک) بهبود عملکرد:
با غیرفعال کردن عملکردهای غیرضروری مرورگر (مانند اسکرول یا زوم)، می‌توان عملکرد کلی اپلیکیشن را به‌ویژه در موبایل‌ها افزایش داد.

دو) کنترل کامل ژست‌ها:
در بسیاری از اپلیکیشن‌ها، نیاز داریم رفتار ژست‌هایی مانند سوایپ یا اسکرول را دقیقاً مطابق نیاز تنظیم کنیم، که این ویژگی امکان‌پذیرش را فراهم می‌سازد.

سه) جلوگیری از تداخل با مرورگر:
استفاده از مقدار touch-action: none جلوی دخالت مرورگر را می‌گیرد—برای مثال، در شرایطی که کاربر با سوایپ قصد تعامل با اپلیکیشن دارد، اما مرورگر آن را به‌عنوان حرکت بازگشت به صفحه قبلی تلقی می‌کند.




#️⃣#tip #css
👥@IR_javascript_group
🆔@IR_javascript

‏✌️ Driver.js: تورها، نکات برجسته، راهنمایی‌های زمینه‌ای و موارد بیشتر

یک کتابخانه جاوااسکریپت خالص برای ساخت تورهای تعاملی در صفحه و سیستم‌های راهنمایی زمینه‌ای است. این کتابخانه چندین سال است که عرضه شده، اما همچنان به‌روزرسانی و نگهداری می‌شود و نمونه‌های متعددی برای بررسی دارد — عملکرد آن بسیار روان و بی‌نقص است.


🔗https://driverjs.com/
#️⃣#npm_module
👥@IR_javascript_group
🆔@IR_javascript

در این‌جا مجموعه‌ای از برترین آیکون‌های متحرک آورده شده است که هر طراح رابط کاربری و تجربه کاربری (UI/UX) باید برای پروژه‌های طراحی آتی خود مد نظر قرار دهد:

یک. LottieFiles
ارائه‌دهنده مجموعه‌ای حرفه‌ای از آیکون‌های متحرک مبتنی بر فرمت Lottie
🔗 [lottiefiles.com/animation/icon](https://lottiefiles.com/animation/icon)

دو. Lordicon
کتابخانه‌ای غنی از آیکون‌های تعاملی و انیمیشنی با قابلیت سفارشی‌سازی
🔗 [lordicon.com](https://lordicon.com)

سه. IconScout
منبعی گسترده برای آیکون‌های متحرک، Lottie، SVG و سایر فرمت‌ها
🔗 [iconscout.com/icons/animation](https://iconscout.com/icons/animation)

چهار. Icons8
مجموعه‌ای متنوع از آیکون‌های متحرک، استاتیک و چندفرمت برای استفاده در انواع پروژه‌ها
🔗 [icons8.com/animated-icons](https://icons8.com/animated-icons)

پنج. UseAnimations
آیکون‌هایی با طراحی مینیمال و انیمیشن‌های سبک برای رابط‌های مدرن
🔗 [useanimations.com](https://useanimations.com)

شش. Flaticon
یکی از بزرگ‌ترین منابع جهانی برای آیکون‌های گرافیکی، اکنون با پشتیبانی از آیکون‌های متحرک
🔗 [flaticon.com/animated-icons](https://flaticon.com/animated-icons)

این ابزارها می‌توانند به طرز چشمگیری جذابیت بصری و تعامل‌پذیری طراحی‌های شما را افزایش دهند.


#️⃣#npm_module
👥@IR_javascript_group
🆔@IR_javascript

سرور HTTP انجین‌ایکس (Nginx) دارای ماژولی به نام njs است که امکان گسترش قابلیت‌های آن با استفاده از جاوااسکریپت را فراهم می‌کند. در گذشته، این ماژول تنها از استاندارد ES5 پشتیبانی می‌کرد. اما اکنون، با بهره‌گیری از موتور QuickJS
، تجربه‌ای مدرن‌تر و قدرتمندتر را ارائه می‌دهد و پشتیبانی کامل از استاندارد ES2023 را فراهم کرده

🔗https://blog.nginx.org/blog/quickjs-engine-support-for-njs
#️⃣#tool
👥@IR_javascript_group
🆔@IR_javascript

‏👀 npq: نصب ایمن بسته‌ها از طریق بررسی پیش از نصب
[مشاهده در GitHub](https://github.com/lirantal/npq)

‏ابزار npq نسبت به npm چند مرحله‌ی اضافی برای اطمینان از سلامت و امنیت بسته‌ها انجام می‌دهد. این ابزار:

* با پایگاه داده‌ی آسیب‌پذیری‌های امنیتی Snyk مشورت می‌کند،
* سن بسته (مدت‌زمانی که از انتشار آن گذشته)،
* تعداد دفعات دانلود،
* و مستندات آن را بررسی می‌کند،

و تلاش می‌کند تصویری دقیق‌تر و شفاف‌تر از آنچه واقعاً در حال نصب هستید ارائه دهد.

این رویکرد باعث افزایش امنیت در زنجیره‌ی تأمین نرم‌افزار شده و به توسعه‌دهندگان کمک می‌کند با اطمینان بیشتری بسته‌ها را انتخاب و نصب کنند.


#️⃣#npm_module
👥@IR_javascript_group
🆔@IR_javascript

### بررسی متد classList.toggle همراه با پارامتر دوم 🤨

متد toggle یکی از پرکاربردترین ابزارها برای مدیریت کلاس‌های CSS در JavaScript است. این متد امکان تغییر پویا در وضعیت عناصر صفحه را با افزودن یا حذف کلاس‌ها فراهم می‌کند.

اما این متد یک پارامتر دوم هم دارد که معمولاً نادیده گرفته می‌شود! 😔

---

### ☺️ نگاهی به سینتکس پایه:

element.classList.toggle('className');

در این حالت:

* ✔️ اگر کلاس مورد نظر وجود داشته باشد، حذف می‌شود؛
* ✔️ اگر وجود نداشته باشد، افزوده می‌شود.

---

### ☺️ اما پارامتر force چیست؟

element.classList.toggle('className', force);

پارامتر force یک مقدار بولی (true یا false) است که به طور صریح کنترل می‌کند که کلاس افزوده شود یا حذف:

* ✔️ true → همیشه کلاس را افزوده خواهد کرد؛
* ✔️ false → همیشه کلاس را حذف خواهد کرد.

---

### 🔍 چند مثال:

menu.classList.toggle('open', true);   // کلاس 'open' حتماً افزوده می‌شود
menu.classList.toggle('open', false);  // کلاس 'open' حتماً حذف می‌شود

---

### 🔧 این قابلیت کجا به کار می‌آید؟

برای همگام‌سازی وضعیت عناصر با منطق برنامه.
به‌جای نوشتن شرط‌های جداگانه برای بررسی وجود یا نبود کلاس، می‌توان به‌سادگی از یک شرط منطقی استفاده کرد:

const isDarkMode = userSettings.theme === 'dark';
document.body.classList.toggle('dark-mode', isDarkMode);

---

### 📌 موارد کاربرد رایج:

* 🔵 فعال‌سازی تم تیره
* 🔵 باز یا بسته بودن منوها
* 🔵 مشخص کردن عنصر فعال
* 🔵 اعمال فیلتر یا مرتب‌سازی

---

### چرا مهم است؟

اگر از پارامتر force استفاده نشود، متد toggle فقط وضعیت کلاس را بین حالت موجود و ناموجود جابه‌جا می‌کند. اما در دنیای واقعی توسعه، معمولاً نیاز به کنترل دقیق و هماهنگ با منطق برنامه وجود دارد.

---

### ✅ نتیجه‌گیری:

استفاده از toggle با پارامتر force مزایای زیر را به همراه دارد:

* کاهش منطق اضافی (نیازی به شرط‌های جداگانه نیست)
* کاهش حجم کد (فقط یک خط کد به‌جای چندین خط شرطی)
* کاهش خطا (جلوگیری از ناهماهنگی بین وضعیت UI و داده‌ها)

در مجموع، روشی ساده و مؤثر برای همگام‌سازی دقیق وضعیت عناصر با منطق برنامه است. 👍


#️⃣#tip #css
👥@IR_javascript_group
🆔@IR_javascript

لاراول و Node.js: اجرای PHP در محیط Watt Runtime
[مطالعه در وبلاگ Platformatic](https://blog.platformatic.dev/laravel-nodejs-php-in-watt-runtime)

در ماه ژوئن، پروژه‌ای با نام php-node معرفی شد که روشی نوین برای *پر کردن فاصله بین PHP و Node.js* ارائه می‌داد؛ به‌طوری‌که می‌توانستیم کدهای PHP را درون برنامه‌های Node اجرا کنیم.

اکنون این رویکرد یک گام فراتر رفته است: با بهره‌گیری از php-node و سرور برنامه‌ای Watt**، امکان **اجرای برنامه‌های لاراول (Laravel) نیز فراهم شده است.

این پروژه، پیوندی جالب و نوآورانه میان دو اکوسیستم محبوب یعنی PHP و Node.js ایجاد کرده و راهی تازه برای هم‌زیستی آن‌ها در یک پروژه واحد فراهم می‌سازد.


#️⃣#tool
👥@IR_javascript_group
🆔@IR_javascript

### انواع رشته‌ای قالب‌دار (Template Literal Types) در TypeScript: چرا به آن‌ها نیاز داریم؟ 🤨

با آن‌که این قابلیت‌ها به‌طور مکرر استفاده نمی‌شوند، اما می‌توانند حل برخی مسائل خاص را بسیار ساده‌تر کنند — مسائلی مانند تولید کلیدها یا مدیریت مسیرها.

---

### ❓ این قابلیت چیست؟

انواع رشته‌ای قالب‌دار در TypeScript این امکان را می‌دهند که رشته‌هایی با ساختار پویا بسازیم، با استفاده از ساختار ${} برای ترکیب بخش‌های مختلف. این کار به تعریف انواع دقیق‌تر، ایمن‌تر و انعطاف‌پذیرتر کمک می‌کند.

#### نمونه:

type Key = `${string}_action`;

در اینجا، نوع Key می‌تواند هر رشته‌ای باشد که با _action پایان می‌یابد.

---

### 🧑‍💻 این ویژگی چه زمانی مفید است؟

#### ✔️ تولید کلیدها:

زمانی که نیاز است چندین کلید با ساختار یکسان تولید شود، می‌توان با استفاده از رشته‌های قالب‌دار، از تکرار و خطاهای احتمالی جلوگیری کرد.

type Prefix = 'user' | 'admin';
type Action = 'create' | 'edit' | 'delete';

type ActionKey = `${Prefix}_${Action}`;
// 'user_create' | 'admin_edit' | و مانند آن‌ها

---

#### ✔️ کار با مسیرها و URLها:

در مواردی که نیاز است مسیرهایی با بخش‌های پویا تعریف شوند — مانند مسیرهای کاربری یا API.

type UserProfileUrl = `users/${string}/profile`;
// 'users/۱۲۳/profile' | 'users/john/profile' و غیره

---

#### ✔️ تولید مقادیر خاص و کنترل‌شده:

زمانی که بخواهیم رشته‌هایی با الگوهای خاص و پیشوندهای مشخص داشته باشیم و سایر مقادیر را مجاز ندانیم.

---

### ✅ جمع‌بندی:

استفاده از رشته‌های قالب‌دار در TypeScript این امکان را فراهم می‌کند که رشته‌هایی با ساختار مشخص و الگوهای ثابت را با دقت و ایمنی بالا نوع‌دهی کنیم. این ویژگی به‌ویژه در پروژه‌هایی که نیاز به کار با داده‌های پویا اما ساختاریافته دارند، بسیار کاربردی است و خطاهای رایج را به حداقل می‌رساند. 👍


#️⃣#tip
👥@IR_javascript_group
🆔@IR_javascript