⚡چرا will-change رو نباید روی همه‌چی بذاری؟

یه ترفند CSS هست که خیلی‌ها وقتی انیمیشن سایت لگ می‌زنه سریع میرن سراغش:

.element {
    will-change: transform;
}

و فکر می‌کنن:

«خب، به مرورگر گفتم قراره تغییر کنه؛ پس حتماً سریع‌تر میشه.»

ولی قضیه این‌قدر ساده نیست.

حالا will-change به مرورگر می‌گه:

«خودت رو برای تغییر احتمالی این property آماده کن.»

اما اگر روی ده‌ها المان استفاده بشه، ممکنه مصرف منابع و حافظه بیشتر بشه و حتی Performance رو بدتر کنه.

پس این کار رو نکن:

* {
    will-change: transform;
}

😐

بهتره فقط برای المان‌هایی استفاده بشه که واقعاً قرار هست تغییر کنن؛ مخصوصاً در سناریوهای مشخص مثل Animation.

حتی در خیلی از موارد، اول باید ببینی مشکل واقعاً از کجاست و آیا transform، opacity یا ساختار انیمیشن درست استفاده شده یا نه.

قضیه Performance یعنی بهینه استفاده کردن از منابع، نه فعال کردن تمام گزینه‌های بهینه‌سازی.

@CodeVerse_dev

🛠 قبل از نصب افزونه جدید وردپرس، این یک سؤال رو از خودت بپرس

فرض کن برای یک سایت وردپرسی مشتری، فقط یک قابلیت کوچیک لازم داری.

مثلاً:

«وقتی کاربر وارد صفحه خاصی شد، یک فایل JavaScript اجرا بشه.»

سریع میری سراغ نصب یک افزونه.

ولی افزونه ممکنه علاوه بر همون قابلیت، کلی چیز دیگه وارد سایت کنه:

CSS
JavaScript
Admin Assets
Database Options
Cron Jobs
AJAX Requests

و تو فقط برای یک قابلیت ساده، یک وابستگی جدید به پروژه اضافه کردی.

قبل از نصب افزونه، این سه سؤال رو بپرس:

۱. آیا واقعاً این قابلیت بدون افزونه قابل پیاده‌سازیه؟

۲. افزونه دقیقاً چه چیزهایی به سایت اضافه می‌کنه؟

۳. اگر فردا افزونه آپدیت نشه، پروژه چقدر بهش وابسته میشه؟

این به معنی «افزونه نصب نکن» نیست.

اتفاقاً افزونه خوب می‌تونه ساعت‌ها زمان توسعه رو ذخیره کنه.

بحث اینه که:

هر افزونه یک Dependency جدیده.

پس قبل از اینکه روی Install کلیک کنی، ببین واقعاً چه چیزی وارد پروژه‌ات می‌کنی.

@CodeVerse_dev

🌐 چرا بعضی لینک‌ها وقتی روشون کلیک می‌کنی، صفحه قبلی رو هم تحت تأثیر قرار میدن؟

این کد رو ببین:

<a href="https://example.com" target="_blank">
    Open
</a>

یعنی لینک داخل Tab جدید باز بشه.

اما یک نکته امنیتی مهم وجود داره.

صفحه مقصد در بعضی سناریوها می‌تونه به صفحه بازکننده از طریق window.opener دسترسی داشته باشه.

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

<a
    href="https://example.com"
    target="_blank"
    rel="noopener"
>
    Open
</a>

انتخاب مطمئن‌تریه.

جالب اینجاست که خیلی‌ها این موضوع رو فقط یک جزئیات HTML می‌بینن.

ولی همین جزئیات کوچیک وقتی داخل یک سایت بزرگ، سیستم تبلیغات، پنل کاربری یا صفحات Third-party استفاده بشن، اهمیت بیشتری پیدا می‌کنن.

نکته مهم‌تر؟

اگر از target="_blank" استفاده می‌کنی، امنیت لینک رو هم به عنوان بخشی از تصمیم در نظر بگیر، نه صرفاً رفتار ظاهری اون.

گاهی امنیت وب از چیزهایی شروع میشه که حتی به چشم نمیان.

💬 چندتا Attribute HTML می‌شناسی که کاربرد امنیتی هم داشته باشن؟

@CodeVerse_dev

ابزار مدیریت دیتابیس برای دولوپرهای حرفه‌ای - معرفی TablePlus

یکی از ابزارهایی که هر دولوپری باید داشته باشه، یه مدیریت‌کننده خوب برای دیتابیس هست. TablePlus یکی از بهترین‌ها در این حوزه محسوب میشه.

✅ ویژگی‌های TablePlus:

· پشتیبانی از MySQL، PostgreSQL، SQLite، Redis و MongoDB
· رابط کاربری زیبا و سریع
· امکان اجرای کوئری‌های پیچیده با Auto-complete
· بکاپ‌گیری و ریستور سریع
· نمایش گرافیکی روابط بین جدول‌ها
· نسخه رایگان برای استفاده شخصی

✅ نصب و استفاده:

برای macOS

brew install --cask tableplus

برای ویندوز

از سایت رسمی دانلود کن

💡 ویژگی فوق‌العاده: می‌تونی چندین دیتابیس مختلف رو همزمان باز کنی و بینشون جابه‌جا بشی. همچنین کوئری‌های محبوب رو توی Saved Queries ذخیره کن تا دیگه دوباره ننویسیشون.

⚠️ نکته مهم: همیشه قبل از اجرای کوئری‌های DELETE یا UPDATE، از دیتابیس بکاپ بگیر. TablePlus این قابلیت رو به‌صورت یک‌کلیکی داره.

@CodeVerse_dev

چرا ()map با ()forEach فرق داره؟ 🤔

خیلی‌ها این دوتا رو تقریباً یکی می‌دونن، در حالی که یک تفاوت مهم دارن که توی کدنویسی واقعی خیلی مهمه.

فرض کن یه آرایه داریم:

const prices = [100, 200, 300];

با ()forEach می‌تونیم روی هر آیتم کاری انجام بدیم:

prices.forEach(price => {
  console.log(price * 2);
});

اما ()forEach چیزی برنمی‌گردونه:

const result = prices.forEach(price => price * 2);

console.log(result);
// undefined

اینجاست که ()map وارد میشه:

const result = prices.map(price => price * 2);

console.log(result);
// [200, 400, 600]

یعنی ()map روی هر آیتم یک عملیات انجام میده و یک آرایه جدید برمی‌گردونه.

پس خیلی ساده:

forEach() → برای اجرای یک عملیات روی آیتم‌ها

map() → برای تبدیل آیتم‌ها و ساختن یک آرایه جدید

مثلاً وقتی از API یه لیست کاربر می‌گیری:

const names = users.map(user => user.name);

اینجا دقیقاً داری از ()map برای استخراج و تبدیل داده استفاده می‌کنی. 🔥

یه نکته مهم هم اینه که اگر فقط می‌خوای روی آیتم‌ها کاری انجام بدی و آرایه جدیدی لازم نداری، ()forEach انتخاب منطقی‌تریه.

اسم متد مهم نیست؛ مهم اینه بدونی هرکدوم برای چه کاری ساخته شده.

@CodeVerse_dev

وقتی میگن تو که همش پشت میزی چه خستگی داری😞

📸 افزونه کروم GoFullPage؛ از کل صفحه سایت اسکرین‌شات بگیر!

تا حالا خواستی از یک صفحه وب که خیلی طولانیه، یک اسکرین‌شات کامل بگیری؟
با GoFullPage دیگه لازم نیست چندین بار اسکرین‌شات بگیری و بعد به هم بچسبونیشون! 😎

فقط افزونه رو اجرا کن و خودش صفحه رو از بالا تا پایین Capture می‌کنه.

🔥 چه کارهایی می‌تونه بکنه؟

✅ گرفتن اسکرین‌شات از کل صفحه
✅ مناسب برای صفحات خیلی طولانی
✅ خروجی گرفتن به صورت تصویر یا PDF
✅ بدون نیاز به ابزارهای اضافی
✅ عالی برای طراحان سایت و بررسی UI
✅ مناسب برای ذخیره نمونه‌کار و مستندسازی پروژه‌ها

💡 مخصوصاً وقتی می‌خوای طراحی یک سایت رو برای بررسی، ارائه به مشتری یا آرشیو ذخیره کنی، GoFullPage واقعاً کاربردیه.

📌 یه کلیک کل صفحه ذخیره میشه! 🚀

@CodeVerse_dev

هزارتایی شدیم! 🥳

به تک‌تک شما که این مسیر را با ما همراه شدید، افتخار می‌کنیم. عدد ۱۰۰۰ فقط یک رقم نیست؛ یعنی هزار نفر اعتماد، هزار نگاه و هزار انگیزه برای بهتر بودن.

از صمیم قلب ممنونیم. قرار نیست متوقف شویم، تازه اول راه است! ❤️

با ما بمانید.

🧠 چرا OFFSET برای Pagination در دیتابیس همیشه انتخاب خوبی نیست؟

در پروژه‌های کوچک این Query کاملاً طبیعی است:

SELECT * FROM posts ORDER BY id DESC LIMIT 20 OFFSET 100000

اما هرچه OFFSET بزرگ‌تر شود، دیتابیس ممکن است مجبور شود تعداد زیادی رکورد را بررسی و رد کند تا به بخش موردنظر برسد.
برای دیتاست‌های بزرگ، یکی از راه‌حل‌های بهتر:

Cursor-based Pagination
مثلاً به جای:
OFFSET 100000
می‌توان گفت:
WHERE id < last_seen_id
و سپس:
ORDER BY id DESC LIMIT 20

مزیت؟

⚡ مناسب برای Feedهای بزرگ
⚡ همچنین Performance پایدارتر
⚡ کاهش اسکن غیرضروری رکوردها

البته انتخاب بین Offset و Cursor به Use Case بستگی دارد؛ Cursor برای همه سناریوها جایگزین مستقیم Offset نیست.
قبل از انتخاب Pagination، به حجم داده و Query Plan فکر کنید.


@CodeVerse_dev

🔐قابلیت Rate Limiting فقط برای جلوگیری از حمله نیست

خیلی‌ها Rate Limit را فقط یک قابلیت امنیتی می‌بینند.

اما در APIهای واقعی، Rate Limiting بخشی از Resource Management است.

فرض کنید یک Endpoint دارید:

POST /api/send-code

اگر محدودیتی وجود نداشته باشد، یک Client می‌تواند هزاران Request ارسال کند.

نتیجه؟

❌ فشار روی Application
❌ افزایش مصرف Database
❌ مصرف منابع سرویس SMS
❌ افزایش هزینه
❌ احتمال سوءاستفاده

حالا Rate Limit می‌تواند بر اساس موارد مختلف اعمال شود:

IP → User → API Key → Endpoint

اما یک نکته مهم:

این Rate Limit را فقط در Application تعریف نکنید.

در معماری‌های توزیع‌شده، باید مکانیزمی داشته باشید که بین چند Instance هماهنگ باشد؛ مثلاً یک Store مشترک مانند Redis.

امنیت خوب فقط جلوی مهاجم را نمی‌گیرد؛
از منابع سیستم هم محافظت می‌کند.

@CodeVerse_dev

🚀 آیا Index بیشتر همیشه یعنی Performance بهتر؟

نه!

خیلی‌ها تصور می‌کنند هرچه روی جدول Index بیشتری داشته باشیم، Queryها سریع‌تر اجرا می‌شوند.

اما هر Index یک هزینه هم دارد.

هنگام اجرای:

INSERT

و

UPDATE

دیتابیس باید Indexهای مربوطه را هم به‌روزرسانی کند.

یعنی:

سرعت خواندن ↑

اما:

هزینه نوشتن ↑

از طرفی Indexهای غیرضروری می‌توانند:

🔹 فضای بیشتری مصرف کنند
🔹 عملیات Write را کندتر کنند
🔹 هزینه نگهداری بیشتری داشته باشند
🔹 انتخاب Execution Plan را پیچیده‌تر کنند

پس Index را فقط بر اساس حدس اضافه نکنید.

اول:

EXPLAIN

بعد بررسی کنید:

Selectivity → Query Pattern → Execution Plan → Actual Performance

یک Index خوب، Indexی نیست که فقط وجود داشته باشد؛

بلکه Indexی است که با الگوی واقعی Queryهای سیستم هماهنگ باشد.

💡 گاهی حذف یک Index اضافی، بیشتر از اضافه کردن یک Index جدید به Performance کمک می‌کند.


@CodeVerse_dev

🔥 یه باگ که اولش فکر می‌کردم تقصیر کدمه!

یه بار توی یکی از پروژه‌ها یه درخواست API داشتم که بعضی وقت‌ها درست جواب می‌داد و بعضی وقت‌ها نه.

اولین حدسم این بود که مشکل از کده.

شروع کردم به تغییر دادن Query، بررسی شرط‌ها و حتی چند قسمت از منطق برنامه رو بازنویسی کردم.

ولی مشکل همچنان بود.

آخرش متوجه شدم مشکل اصلاً از منطق برنامه نبود؛
رفتار درخواست‌ها و زمان‌بندی اجرای چند عملیات باعث ایجاد Race Condition شده بود.

اونجا یه چیز مهم برام جا افتاد:

هر باگی که می‌بینی، الزاماً از همون جایی که ظاهر میشه به وجود نیومده.

از اون به بعد موقع دیباگ، فقط به خطی که Error داده نگاه نمی‌کنم؛
کل مسیر اتفاق رو بررسی می‌کنم.

📢 @CodeVerse_dev

🐘 وقتی ()isset اون چیزی نیست که فکر می‌کنی!

خیلی‌ها ()isset رو فقط برای این استفاده می‌کنن:

if (isset($user)) {
    // ...
}

اما یه رفتار مهم داره که توی پروژه‌های واقعی می‌تونه باعث باگ بشه:

$data = [
    'name' => null
];

var_dump(isset($data['name']));
// false

چرا؟

چون ()isset در PHP فقط بررسی نمی‌کنه که کلید وجود داره؛ بررسی می‌کنه که مقدار وجود داشته باشه و null نباشه.

پس این دو حالت از نظر ()isset یکی هستن:

$data = [];

$data = [
    'name' => null
];

هر دو:

isset($data['name']); // false

اگر واقعاً می‌خوای بفهمی کلید وجود داره یا نه، از ()array_key_exists استفاده کن:

$data = [
    'name' => null
];

var_dump(array_key_exists('name', $data));
// true

چرا این موضوع مهمه؟ 👇

فرض کن API بهت این response رو بده:

{
    "name": null
}

اینجا null ممکنه یک مقدار کاملاً معنادار باشه؛ مثلاً یعنی کاربر عمداً نامش رو حذف کرده.

ولی اگر اینطوری بنویسی:

if (!isset($data['name'])) {
    // name doesn't exist
}

داری دو مفهوم متفاوت رو یکی در نظر می‌گیری:

❌ کلید وجود ندارد
❌ کلید وجود دارد ولی مقدارش null است

در پروژه‌های جدی، این تفاوت می‌تونه روی Validation، API، PATCH Request و Update Logic تأثیر مستقیم بذاره.

🔑 قاعده حرفه‌ای:

isset() → آیا مقدار وجود دارد و null نیست؟

array_key_exists() → آیا این کلید واقعاً داخل آرایه وجود دارد؟

همین تفاوت‌های کوچک، دقیقاً جایی هستن که کد معمولی رو از کد حرفه‌ای جدا می‌کنن.


@CodeVerse_dev

🧠 چرا 200 OK همیشه یعنی درخواستت موفق بوده؟

یکی از اشتباهات رایج موقع ساخت API اینه که برای تقریباً همه‌چیز 200 برگردونیم.

مثلاً کاربر محصولی رو درخواست کرده که اصلاً وجود نداره:

HTTP/1.1 200 OK

{
  "success": false,
  "message": "Product not found"
}

از نظر برنامه‌نویس شاید مشکلی نباشه؛ ولی HTTP برای همین سناریوها Status Code داره.

مثلاً:

404 Not Found

وقتی Resource وجود نداره.

یا:

401 Unauthorized

وقتی احراز هویت انجام نشده.

و:

403 Forbidden

وقتی کاربر شناسایی شده ولی اجازه انجام اون عملیات رو نداره.

این تفاوت فقط برای «قشنگ‌تر بودن API» نیست.

حالا Client، Cache، Monitoring، Proxy و حتی ابزارهای Debugging می‌تونن بر اساس Status Code رفتار متفاوتی داشته باشن.

پس API خوب فقط JSON درست تحویل نمی‌ده؛

قرارداد HTTP رو هم درست اجرا می‌کنه.


@CodeVerse_dev

⚡چرا بعضی سایت‌ها بعد از باز شدن، تازه شروع به «پریدن» می‌کنن؟

صفحه باز شده، کاربر آماده کلیک کردنه...

یه دفعه:

تصویر لود میشه ← محتوا پایین میره
فونت لود میشه ← متن جابه‌جا میشه
تبلیغ میاد ← کل صفحه تکون می‌خوره 😐

این مشکل فقط ظاهر سایت رو خراب نمی‌کنه؛ روی Cumulative Layout Shift (CLS) هم تأثیر می‌ذاره.

یکی از راه‌حل‌های ساده برای تصاویر اینه که فضای موردنیاز تصویر از قبل مشخص باشه:

<img
  src="product.webp"
  width="800"
  height="600"
  alt="Product"
>

مرورگر قبل از اینکه تصویر دانلود بشه، می‌فهمه چه فضایی باید برای اون کنار بذاره.

در نتیجه وقتی تصویر رسید، Layout مجبور نیست ناگهان تغییر کنه.

برای ویدیو، iframe، تبلیغات و محتوای Dynamic هم باید همین ذهنیت رو داشته باشی:

فضای المان رو تا جای ممکن از قبل مشخص کن.

موضوع Performance فقط این نیست که صفحه سریع باز بشه.

صفحه باید پایدار هم باشه.


@CodeVerse_dev

🔍 یک ترفند DevTools برای پیدا کردن CSSهای بی‌استفاده

فرض کن یک سایت قدیمی داری که هزاران خط CSS داخلشه.

مشکل؟

نمی‌دونی کدوم کلاس‌ها واقعاً استفاده میشن.

اینجا Chrome DevTools یه قابلیت جالب داره:

Coverage

از Command Menu می‌تونی Coverage رو باز کنی و صفحه رو بررسی کنی.

بعد مرورگر نشونت میده چه مقدار از CSS و JavaScript دانلودشده واقعاً در اون صفحه استفاده شده.

مثلاً ممکنه ببینی:

style.css
Used: 42%
Unused: 58%

یعنی بیشتر از نصف CSS دانلود شده، ولی در همون صفحه استفاده نشده.

البته یه نکته مهم:

گزینه Unused در یک صفحه الزاماً به معنی Dead Code نیست.

ممکنه اون CSS در صفحه دیگری استفاده بشه یا با Interaction کاربر فعال بشه.

پس Coverage رو نباید کورکورانه تبدیل به «این فایل رو حذف کن» کنی.

ولی برای پیدا کردن Assetهای مشکوک و CSS/JSهای سنگین، ابزار فوق‌العاده‌ایه.

خصوصاً وقتی با یک قالب یا سایت قدیمی طرفی که سال‌ها افزونه روی افزونه نصب شده.

💬 تا حالا Coverage رو داخل DevTools امتحان کردی؟

@CodeVerse_dev

📊 افزونه گوگل کروم SEOquake؛ سئوی هر صفحه رو سریع بررسی کن!

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

به‌جای اینکه برای هر بررسی بین چند ابزار مختلف جابه‌جا بشی، SEOquake اطلاعات پایه سئوی صفحه رو در اختیارت می‌ذاره. 🔍

🔥 چه چیزهایی می‌تونی بررسی کنی؟

✅ اطلاعات On-Page صفحه
✅ متا تگ‌ها و ساختار محتوا
✅ بررسی Headingهای صفحه
✅ تحلیل لینک‌های داخلی و خارجی
✅ بررسی برخی فاکتورهای سئو و اطلاعات دامنه
✅ مناسب برای بررسی سریع سایت رقبا

💡 مثلاً:
یک صفحه از سایت رقیب رو باز می‌کنی و می‌خوای سریع ببینی چه Title، Description و Headingهایی داره؛ SEOquake می‌تونه این اطلاعات رو خیلی راحت در اختیارت بذاره.

⚡ برای بررسی سریع سئو، لازم نیست همیشه بری سراغ ابزارهای سنگین؛ گاهی یک افزونه ساده روی مرورگر دقیقاً همون چیزیه که نیاز داری.


@CodeVerse_dev

🚨 وردپرس رسماً داره از AI برای پیدا کردن باگ‌های امنیتی خودش استفاده می‌کنه!

این یکی از خبرهای جالب این روزهای اکوسیستم WordPressـه.

پروژه WordPress یک برنامه جدید به اسم Core Security Initiative راه‌اندازی کرده که هدفش اینه آسیب‌پذیری‌های Core رو زودتر پیدا و برطرف کنه.

قسمت جذاب ماجرا؟

🤖 استفاده از ابزارهای AI برای پیدا کردن Vulnerabilityها قبل از اینکه مهاجم‌ها بتونن ازشون سوءاستفاده کنن.

این اتفاق بی‌دلیل نیست.

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

یعنی AI اینجا قرار نیست جای Security Researcher رو بگیره.

قرارِ کارهای تکراری و حجیم رو سریع‌تر کنه تا متخصص‌ها روی موارد پیچیده‌تر تمرکز کنن.

💡 یه نکته مهم برای توسعه‌دهنده‌های وردپرس:

هرچی ابزارهای پیدا کردن باگ قوی‌تر بشن، کیفیت کدی که برای Plugin و Theme می‌نویسیم هم باید بالاتر بره.

@CodeVerse_dev

🧠 اگه هنوز برای هر Layout سراغ Flexbox و Grid می‌ری، یه قابلیت CSS رو جدی‌تر ببین

اسمش Container Queriesـه.

مشکل Media Query اینه که معمولاً بر اساس اندازه‌ی Viewport تصمیم می‌گیری.

مثلاً:

@media (max-width: 768px) {
  .card {
    ...
  }
}

ولی فرض کن همین Card یک بار داخل Sidebar قرار بگیره و یک بار داخل محتوای اصلی.

حالا Viewport یکیه، ولی فضای واقعی Card کاملاً فرق داره.

اینجاست که Container Query جذاب میشه:

.card-wrapper {
  container-type: inline-size;
}

@container (max-width: 500px) {
  .card {
    grid-template-columns: 1fr;
  }
}

حالا خود Component بر اساس فضایی که در اختیارشه تصمیم می‌گیره، نه اندازه کل صفحه.

🔥 این دقیقاً همون چیزی‌یه که برای ساخت Componentهای قابل استفاده مجدد لازم داری.

به‌خصوص در Design Systemهای بزرگ.

💡قابلیت Responsive Design داره از «Responsive Page» به سمت Responsive Component حرکت می‌کنه.


این روند هم در بررسی‌های جدید اکوسیستم Frontend به‌عنوان یکی از قابلیت‌های مهم CSS مدرن مطرح شده.

@CodeVerse_dev

یه قابلیت عجیب JavaScript به اسم Closure 👀

فرض کن این کد رو داریم:

function counter() {
  let count = 0;

  return function () {
    count++;
    return count;
  };
}

const increment = counter();

console.log(increment()); // 1
console.log(increment()); // 2
console.log(increment()); // 3

شاید سوالت این باشه:

چطور count بعد از اجرای ()counter هنوز وجود داره؟ 🤔

اینجا Closure وارد میشه.

تابعی که داخل counter ساخته شده، به متغیرهای Scope بیرونی خودش دسترسی رو حفظ می‌کنه؛ حتی وقتی اجرای تابع بیرونی تموم شده.

یعنی این تابع:

function () {
  count++;
  return count;
}

هنوز به count دسترسی داره.

این قابلیت Closure کجا به درد می‌خوره؟

یکی از کاربردهای مهمش ساختن Private State هست:

function createUser() {
  let password = "123456";

  return {
    checkPassword(value) {
      return value === password;
    }
  };
}

const user = createUser();

user.checkPassword("123456"); // true

اینجا password مستقیماً از بیرون قابل دسترسی نیست:

user.password
// undefined

ولی متد checkPassword همچنان بهش دسترسی داره.

🔥 در واقع Closure یکی از پایه‌های مهم مفاهیمی مثل:

* Factory Functions
* Data Privacy
* Callbacks
* Event Handlers
* Function Currying

در JavaScript محسوب میشه.

پس Closure فقط یه مفهوم تئوری نیست؛ توی کد واقعی دائماً باهاش سروکار داری.

@CodeVerse_dev

🔐 یه نکته امنیتی که خیلی از توسعه‌دهنده‌های وردپرس نادیده می‌گیرن

فرض کن یه Plugin داری که فقط برای یک صفحه خاص لازمه.

ولی فایل‌های CSS و JavaScript اون Plugin روی تمام صفحات سایت لود میشن.

مشکل فقط Performance نیست.

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

یکی از کارهایی که در پروژه‌های حرفه‌ای باید بررسی کنی اینه:

آیا این قابلیت واقعاً باید در تمام صفحات Load بشه؟

مثلاً می‌تونی در بعضی سناریوها Assetهای یک Plugin رو فقط در صفحه موردنیاز enqueue کنی.

به جای:

تمام سایت

↓
Plugin CSS
Plugin JS

برسی به چیزی شبیه:

/checkout
   ↓
Checkout CSS
Checkout JS

این کار هم Performance رو بهتر می‌کنه، هم وابستگی‌های غیرضروری رو کمتر می‌کنه.

و این موضوع وقتی مهم‌تر میشه که بدونی در همین روزهای اخیر چندین آسیب‌پذیری جدی در Pluginهای WordPress گزارش شده؛ از جمله مواردی که می‌تونستن به Account Takeover یا حتی Remote Code Execution منجر بشن.

💡 داخل وردپرس Plugin کمتر، کد کمتر و سطح حمله کمتر همیشه به معنی امنیت بیشتر نیست؛ ولی مدیریت دقیق وابستگی‌ها قطعاً بخشی از یک معماری سالمه.

@CodeVerse_dev