CodeVerse | دنیای برنامه نویسان

دیگه برای هر Property چک if ننویس! 😎

فرض کن اطلاعات کاربر از API اومده:

const user = {
  profile: {
    address: {
      city: "Baku"
    }
  }
};

حالا می‌خوای شهر رو بگیری:

console.log(user.profile.address.city);

فعلاً مشکلی نیست.

اما اگر address وجود نداشته باشه:

const user = {
  profile: {}
};

console.log(user.profile.address.city);

💥 خطا می‌گیری:

Cannot read properties of undefined

قبلاً شاید اینطوری حلش می‌کردیم:

if (
  user &&
  user.profile &&
  user.profile.address
) {
  console.log(user.profile.address.city);
}

ولی JavaScript یه راه تمیزتر داره:

console.log(user?.profile?.address?.city);

اگر هرکدوم از این Propertyها وجود نداشته باشه، به‌جای Error مقدار undefined برمی‌گرده.

---
ترکیبش با ?? خیلی خفنه 🔥

مثلاً:

const city =
  user?.profile?.address?.city ?? "Unknown";

console.log(city);

اگر شهر وجود نداشته باشه:

Unknown

یعنی:

?. → اگر وجود نداشت، خطا نده.

?? → اگر مقدار null یا undefined بود، مقدار پیش‌فرض بده.

این ترکیب توی پروژه‌هایی که با API، JSON و داده‌های تو‌در‌تو کار می‌کنی واقعاً کاربردیه.

کد کمتر، شرط کمتر، خطای کمتر. 🚀

@CodeVerse_dev

🔐 وقتی LLM وارد Web App می‌شود، مدل تهدید هم تغییر می‌کند.

قبلاً امنیت وب را بیشتر با تهدیدهایی مثل:

XSS
SQL Injection
CSRF
SSRF

می‌شناختیم.

اما وقتی یک LLM یا AI Agent را وارد Application می‌کنیم، یک لایه جدید ایجاد می‌شود:

Prompt Injection

مشکل اینجاست که ورودی کاربر دیگر فقط یک Input ساده نیست؛ ممکن است روی تصمیم‌گیری Agent تأثیر بگذارد.

مثلاً:

User Input
↓
LLM
↓
Tool / API
↓
Database

اگر Agent اجازه اجرای Tool داشته باشد، یک ورودی مخرب می‌تواند از مرز «متن» عبور کرده و روی عملیات واقعی سیستم اثر بگذارد.

به همین دلیل در معماری‌های AI-enabled باید علاوه بر Validation سنتی، به مواردی مثل:

🛡️ محدودسازی Toolها
🛡️ کنترل Permission
🛡️ جداسازی داده و دستور
🛡️ اعتبارسنجی خروجی
🛡️همچنین Runtime Monitoring

هم فکر کرد.

امنیت Web Appهای مجهز به AI دیگر فقط مسئله‌ی Backend یا Frontend نیست؛

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


@CodeVerse_dev

🌐 چرا یک سایت حرفه‌ای همیشه یک Loading Spinner نشون نمی‌ده؟

وقتی درخواست طول می‌کشه، اولین راه‌حل خیلی از طراح‌ها اینه:

⏳ Loading...

ولی UX مدرن همیشه این نیست.

فرض کن صفحه‌ای داری که ساختارش مشخصه، ولی اطلاعاتش هنوز از API نیومده.

به جای اینکه کل صفحه رو قفل کنی:

        Loading...

می‌تونی از Skeleton UI استفاده کنی:

┌─────────────────────┐
│ █████████████       │
│ █████████████████   │
│                     │
│ ████████            │
│ ███████████████     │
└─────────────────────┘

کاربر از همون لحظه اول می‌فهمه ساختار صفحه چیه و منتظر محتوا می‌مونه.

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

Skeleton نباید صرفاً یک انیمیشن تزئینی باشه.

اگر قرار باشه ۵ ثانیه Skeleton نمایش بدی و بعد محتوا بیاد، فقط تأخیر رو قشنگ‌تر کردی. 😄

هدفش اینه که درک کاربر از زمان انتظار بهتر بشه، نه اینکه Performance واقعی رو پنهان کنیم.

گاهی بهترین UX این نیست که کاری کنی کاربر منتظر نماند؛

کاری کن بداند دقیقاً منتظر چه چیزی است.


@CodeVerse_dev

🧩 چرا بعضی تغییرات وردپرس فقط وقتی لاگین هستی دیده میشن؟

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

مدیر سایت وارد WordPressـه و همه‌چیز عالیه.

ولی وقتی Logout می‌کنی:

> طراحی خراب میشه! 😐

یکی از مظنون‌های اصلی Cacheـه.

ممکنه وقتی لاگین هستی، صفحه از Cache سرو نشه و وردپرس نسخه تازه رو تولید کنه.

اما کاربر عادی نسخه Cached قدیمی رو ببینه.

برای همین وقتی تغییر مهمی در ظاهر سایت میدی، فقط خودت رو بررسی نکن.

این سناریوها رو هم تست کن:

Logged in
Logged out
Incognito
Mobile
Desktop

و اگر CDN یا Page Cache داری، Cache مربوط به صفحه رو هم بررسی کن.

یه نکته مهم‌تر:

«برای من درست نمایش داده میشه» به معنی «برای کاربر هم درست نمایش داده میشه» نیست.

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

@CodeVerse_dev

چرا null و undefined یکی نیستن؟ 🤔

خیلی‌ها فکر می‌کنن هر دو یعنی «هیچی»، ولی در JavaScript تفاوت مهمی دارن.

حالا undefined معمولاً یعنی یک مقدار هنوز تعیین نشده:

let username;

console.log(username);
// undefined

اما null معمولاً یعنی خود برنامه‌نویس عمداً نبودن مقدار رو مشخص کرده:

let user = null;

یعنی:

فعلاً کاربری وجود نداره.

حالا یه نکته جالب:

typeof undefined
// "undefined"

typeof null
// "object"

این رفتار null یکی از باگ‌های تاریخی JavaScript محسوب میشه و هنوز هم به همین شکل باقی مونده. 😅

اما قسمت مهم‌تر:

null == undefined
// true

null === undefined
// false

چون == تبدیل نوع انجام میده، ولی === هم نوع و هم مقدار رو بررسی می‌کنه.

توی پروژه واقعی چی؟

وقتی داده‌ای از API می‌گیری، ممکنه با هر دو مواجه بشی:

if (user.name === undefined) {
  // فیلد name اصلاً وجود نداره
}

if (user.name === null) {
  // فیلد وجود داره ولی مقدارش عمداً خالیه
}

البته در پروژه‌های واقعی بهتره قرارداد API مشخص کنه که برای «مقدار خالی» از null استفاده میشه یا نبودن property.

🔥 خلاصه:

undefined → مقدار تعیین نشده / property ممکنه وجود نداشته باشه

null → عمداً مقدار خالی

و برای مقایسه دقیق:

=== 

رو انتخاب کن.

@CodeVerse_dev

چرا کپی کردن یک Object در JavaScript همیشه کپی واقعی نیست؟ 🤔

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

const user = {
  name: "Ahmad",
  settings: {
    theme: "dark"
  }
};

const copy = { ...user };

copy.name = "Ali";
copy.settings.theme = "light";

console.log(user.name);
// Ahmad

console.log(user.settings.theme);
// light 😐

چی شد؟!

ما که user رو کپی کرده بودیم!

مشکل اینجاست که Spread Operator فقط یک Shallow Copy می‌سازه.

یعنی لایه اول Object کپی میشه، ولی Objectهای تو‌در‌تو همچنان به همان Reference قبلی اشاره می‌کنن.

پس:

copy.settings === user.settings
// true

اما برای کپی عمیق می‌تونی از ()structuredClone استفاده کنی:

const copy = structuredClone(user);

copy.settings.theme = "light";

console.log(user.settings.theme);
// dark

حالا:

copy.settings === user.settings
// false

🔥 این تفاوت توی پروژه‌هایی که با State، API Response یا Objectهای تو‌در‌تو کار می‌کنی خیلی مهمه.

نکته حرفه‌ای:

تابع JSON.parse(JSON.stringify(obj)) هم یک روش قدیمی برای Deep Copy محسوب میشه، اما محدودیت‌های مهمی داره و برای همه داده‌ها مناسب نیست.

اگر با JavaScript حرفه‌ای کار می‌کنی، ()structuredClone رو بشناس.

@CodeVerse_dev

🔥 یه ترفند PHP که کد پروژه‌ات رو خیلی تمیزتر می‌کنه

فرض کن یه تابع داری که فقط باید با یک نوع خاص از داده کار کنه.

روش قدیمی اینه که داخل تابع مدام چک کنی:

if (!is_string($value)) {
    throw new Exception('Invalid value');
}

ولی در PHP مدرن می‌تونی این قرارداد رو از همون اول مشخص کنی:

function generateSlug(string $title): string
{
    return strtolower(str_replace(' ', '-', $title));
}

حالا تابع رسماً اعلام می‌کنه:

ورودی باید string باشه و خروجی هم string.

این موضوع وقتی پروژه بزرگ میشه خیلی مهم‌تر میشه.

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

«این تابع چه چیزی می‌گیره؟ چی برمی‌گردونه؟»

خود Signature تابع جواب رو میده.

حتی می‌تونی برای ساختارهای پیچیده‌تر از:

int
string
bool
array
object
Union Types
Nullable Types

استفاده کنی.

💡موضوع Type Hint فقط برای جلوگیری از Error نیست؛ یه جور قرارداد بین بخش‌های مختلف کده.

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


@CodeVerse_dev

🚨 اگه روی سایتت All-in-One WP Migration داری، همین امروز نسخه‌ش رو چک کن!

یه آسیب‌پذیری جدی با شناسه CVE-2026-19949 در افزونه All-in-One WP Migration and Backup پیدا شده.

قسمت ترسناک ماجرا؟

این باگ فقط یه خطای ساده نیست؛ می‌تونه در شرایط خاص از یک SQL Injection به اجرای کد روی سرور و در نهایت Takeover کامل سایت منجر بشه. 😐

این افزونه بیش از ۵ میلیون نصب فعال داره و طبق گزارش‌های امنیتی، تعداد زیادی از سایت‌ها هنوز Patch نشدن.

پس اگر روی پروژه‌هات از این افزونه استفاده می‌کنی:

1️⃣ نسخه افزونه رو بررسی کن.
2️⃣ اگر آپدیت امنیتی داری، قبل از هر چیز Backup بگیر.
3️⃣ افزونه رو به نسخه اصلاح‌شده 7.110 یا بالاتر ارتقا بده.
4️⃣ اگر سایت قبلاً آسیب‌پذیر بوده، فقط Update کردن کافی نیست؛ لاگ‌ها، کاربران Administrator و فایل‌های مشکوک رو هم بررسی کن.

💡 نکته‌ای که باید همیشه یادت بمونه:

اینکه Backup Plugin خودش نباید تبدیل به نقطه ضعف سایت بشه

@CodeVerse_dev

⚡ انتشار 8.5 فقط یک نسخه جدید نیست؛ بعضی قابلیت‌هایش روی نحوه نوشتن کد اثر می‌گذارند.

یکی از قابلیت‌های جالب PHP 8.5:

Pipe Operator

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

ایده کلی:

$result = $value |> fn($x) => ...;

هدف اصلی؟

خوانایی بهتر در زنجیره‌ای از عملیات.

در کنار آن، PHP 8.5 قابلیت‌هایی مثل:

🔹 clone with
🔹 توابع array_first() و array_last()
🔹 URI Extension

را هم به اکوسیستم PHP اضافه کرده است.

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

یادگیری Version جدید فقط حفظ کردن Featureها نیست.

باید بفهمیم:

کدام قابلیت واقعاً کد ما را بهتر می‌کند و کدام فقط Syntax جدید است؟


@CodeVerse_dev

🔐 یک API امن فقط با JWT ساخته نمی‌شود

استفاده از JWT به این معنی نیست که API شما امن است.

حالا JWT فقط یکی از روش‌های انتقال اطلاعات هویتی است.

امنیت API باید چند لایه داشته باشد:

Authentication
کاربر چه کسی است؟

↓

Authorization
به چه Resourceهایی دسترسی دارد؟

↓

Input Validation
چه داده‌ای اجازه ورود دارد؟

↓

Rate Limiting
چند درخواست در یک بازه مجاز است؟

↓

Output Filtering
چه اطلاعاتی اجازه خروج دارد؟

↓

Logging & Monitoring
اگر حمله‌ای اتفاق افتاد، چطور متوجه شویم؟

یکی از خطرناک‌ترین اشتباهات این است که توسعه‌دهنده تمام تمرکز خود را روی Token بگذارد و بقیه لایه‌ها را فراموش کند.

اینجا JWT معتبر می‌تواند متعلق به یک کاربر واقعی باشد؛

اما این سؤال همچنان باقی است:

آیا این کاربر اجازه انجام این عملیات را دارد؟

@CodeVerse_dev

🐘 چرا کپی کردن یک آرایه همیشه یعنی کپی شدن حافظه نیست؟

یکی از رفتارهای جالب PHP، مکانیزم Copy-on-Write هست.

مثلاً:

$data = range(1, 1_000_000);

$copy = $data;

شاید فکر کنی PHP همین لحظه یک آرایه‌ی یک میلیون‌عضوی دیگه داخل Memory ساخته.

اما نه! 👀

حالا PHP تا وقتی داده تغییر نکرده، می‌تونه بین این دو متغیر از همان داده‌ی موجود استفاده کنه.

$data = range(1, 1_000_000);

$copy = $data;

// هنوز الزاماً یک کپی کامل ساخته نشده

اما داستان وقتی جالب میشه که یکی از آن‌ها را تغییر بدی:

$copy[0] = 999;

اینجاست که PHP باید وضعیت داده را طوری مدیریت کند که تغییر $copy روی $data تأثیر نگذارد.

یعنی عملاً:

$data  ─────┐
            ├──> Shared Memory
$copy  ─────┘

        ↓ تغییر

$data  ─────────> Original Data
$copy  ─────────> New Copy

حالا یک نکته‌ی مهم‌تر 👇

همین موضوع یکی از دلایلیه که این کد:

function process(array $data)
{
    // ...
}

لزوماً به این معنی نیست که با ورود $data به تابع، یک کپی کامل از آرایه ساخته می‌شود.

زبانPHP می‌تواند تا زمانی که داده تغییر نکرده، از Copy-on-Write استفاده کند.

اما اگر داخل تابع شروع به تغییر آرایه کنی:

function process(array $data)
{
    $data['status'] = 'done';
}

شرایط Memory می‌تواند کاملاً متفاوت شود.

🔴 پس یک تصور اشتباه:

«قابلیت Pass by Value یعنی PHP همیشه همان لحظه کل داده را کپی می‌کند.»

نه لزوماً.

در PHP، برای داده‌هایی مثل Array، مکانیزم Copy-on-Write باعث می‌شود کپی فیزیکی داده تا زمان نیاز به تغییر، به تعویق بیفتد.

نکته‌ی Performance 🚀

اگر با آرایه‌های بزرگ، پردازش فایل، داده‌های API یا پردازش‌های سنگین کار می‌کنی، درک Copy-on-Write مهمه؛ چون ممکنه یک تغییر کوچک روی یک آرایه‌ی بزرگ، باعث افزایش قابل‌توجه مصرف Memory بشه.

حرفه‌ای نوشتن PHP فقط کد نیست؛ باید بدونی Engine پشت این کد چه رفتاری داره. 🐘

@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

یه قابلیت عجیب 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

🧠 اگه هنوز برای هر 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

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

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

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

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

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

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

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

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

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

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

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

@CodeVerse_dev

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

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

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

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

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

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

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


@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

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

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

یه دفعه:

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

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

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

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

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

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

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

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

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

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


@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

🐘 وقتی ()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