گاهی در API یا فرم‌ها نیاز داری مطمئن بشی یک آرایه ورودی دقیقا شامل کلیدهایی باشه که انتظار داری. از لاراول 10.9 به بعد میتونی بهراحتی با rule جدید required_array_keys این کارو انجام بدی.

📌 مثال:

فرض کن ورودیه API به این شکل میاد:

{
  "user": {
    "name": "Ali",
    "email": "ali@example.com"
  }
}

برای اینکه مطمئن بشیم حتما کلیدهای name و email داخل user وجود دارن، کافیه اینطوری بنویسیم:

$request->validate([
    'user' => ['required', 'array', 'required_array_keys:name,email'],
]);

حالا اگه یکی از این کلیدها در ورودی نبود، لاراول خطا میده.

این روش خیلی تمیزتر و کوتاه‌تر از نوشتن چندین rule برای هر فیلده و مخصوصا در API ها بسیار کاربردیه.
#Laravel  #لاراول

@GoldenCodeir
(به منبع و مثالش دقت کنید 👇🏾)
https://x.com/PovilasKorop/status/1964988360193155402?s=35

مفهوم Trade-off در توسعه نرم‌افزار
(تعادل میان مزایا و معایب در تصمیم‌های فنی)

در توسعه نرم‌افزار، هیچ تصمیمی رایگان نیست. هر انتخابی، در کنار مزایا، هزینه‌ها و محدودیت‌هایی هم دارد. Trade-off یعنی برقراری تعادل میان این مزایا و معایب، و انتخاب بهترین گزینه متناسب با شرایط واقعی پروژه.

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

و در دنیای نرم‌افزار:

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

تفاوت در معیارهای سنجش
نکته مهم دیگر این است که معیارهای سنجش در هر پروژه متفاوت است:

- یک استارتاپ ممکن است سرعت رسیدن به بازار را مهم‌تر بداند.
- یک سیستم بانکی احتمالاً امنیت و پایداری بلندمدت را در اولویت قرار می‌دهد.
- یک پروژه تحقیقاتی شاید بیشتر به انعطاف‌پذیری و نوآوری اهمیت دهد.

بنابراین حتی اگر دو تیم روی یک زبان یا فریم‌ورک واحد بحث کنند، ممکن است از زاویه‌های متفاوتی آن را ارزیابی کنند و به نتایج متفاوتی برسند.


به همین دلیل، انتخاب زبان، ابزار یا فریم‌ورک هیچ‌وقت یک پاسخ مطلق «بهترین» ندارد.
سؤال درست این نیست که کدام بهترین است؟
بلکه این است که کدام گزینه با توجه به نیازهای فعلی پروژه و توان تیم، بهترین تعادل (Trade-off) را فراهم می‌کند؟

Source

#trade_off

@Syntax_fa

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

لاراول از نسخه‌های جدید متود Rule::anyOf() رو معرفی کرده که این نیاز رو خیلی تمیز حل میکنه.


📌 مثال :
کاربر میتونه برای تماس یا ایمیل بده یا شماره موبایل.

use Illuminate\Validation\Rule;

$request->validate([
    'contact' => [
        Rule::anyOf([
            ['email'],
            ['regex:/^09\d{9}$/'], // شماره موبایل ایران
        ])
    ]
]);

✅ اگه ایمیل معتبر وارد بشه → اوکی
✅ اگه شماره موبایل معتبر وارد بشه → اوکی
❌ اگه هیچکدوم درست نباشه → خطای ولیدیشن

مزیت‌هاش چیه؟

تمیزتر و قابل‌خواندن‌تر از شرط‌های پیچیده

کاربردی برای ورودی‌هایی که میتونن فرمت‌های متفاوت داشته باشن (مثل کد ملی یا پاسپورت، کارت بانکی یا شبا و …)

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

#Laravel #لاراول

@GoldenCodeir

(به‌منبع و مثالش دقت کنید 👇🏾)
https://x.com/PovilasKorop/status/1966051846386012636?t=Erp47hWetRxKXZ7pKJ_GSA&s=3

به افتخار ذهن‌هایی که از دل صفر و یک، جهانی سرشار از امکان می‌سازند؛ روز برنامه‌نویس مبارک ❤️‍🔥 🫡 🙏🏽

یکی از قابلیت های جالبه لاراول اینه که میتونی خیلی ساده برای APIها محدودیت درخواست (Rate Limit) بذاری.
ولی جذابتر اینه که محدودیت میتونه بر اساس شرایط مختلف اعمال بشه،

مثلا:

🔹 اگه کاربر عضو تیم باشه → محدودیت بر اساس team_id

🔹 اگه کاربر پلن اشتراکی داشته باشه → محدودیت بر اساس نوع پلن

🔹 و اگه هیچکدوم نبودش → محدودیت پیش‌فرض بر اساس IP

این یعنی میتونی برای پلن رایگان محدودیت سخت‌تر بذاری، برای پلن حرفه‌ای محدودیت بیشتر، و برای تیم‌ها محدودیت مشترک.

📌 نمونه کد در RouteServiceProvider:

use Illuminate\Support\Facades\RateLimiter;
use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Http\Request;

RateLimiter::for('api', function (Request $request) {
    if ($request->user()?->team_id) {
        // محدودیت مشترک برای کل تیم
        return Limit::perMinute(100)->by($request->user()->team_id);
    }

    if ($request->user()?->plan) {
        // محدودیت بر اساس پلن کاربر
        return Limit::perMinute(200)->by($request->user()->id);
    }

    // محدودیت پیش‌فرض برای آی‌پی
    return Limit::perMinute(60)->by($request->ip());
});

🔥 با همین چند خط کد، میتونی مدیریت مصرف API رو هوشمند و حرفه‌ای کنی، طوریکه هم کاربرا تجربه بهتری دارن، هم از تلاش های مخربه برخی کاربرا جلوگیری میشه.
#Laravel #لاراول

@GoldenCodeir

(به منبع و مثالش دقت کنید👇🏾)
https://x.com/wendell_adriel/status/1967552508647071760?s=35

یکی از دغدغه‌های مهم در طراحی API اینه که اطلاعات اضافی نفرستیم.

چون:

حجم ریسپانس ها زیاد میشه و حجم منابع سرور افزایش پیدا میکنه و...

لاراول یه راهکار خیلی تمیز برای این موضوع داره: استفاده از API Resource‌ها.

🔹 مشکل رایج

فرض کنید می‌خوایم اطلاعات یک کاربر رو همراه با پست‌هاش برگردونیم.
معمولا شاید اینطوری عمل کنیم:

return [
    'id' => $this->id,
    'name' => $this->name,
    'posts' => PostResource::collection($this->posts),
];

اینجا یه مشکل هست: حتی اگر posts رو لود نکرده باشیم، باز هم کلید posts توی JSON میاد (و معمولا query اضافه اجرا میشه).

لاراول متودی به اسم whenLoaded داره. این متود بررسی میکنه که آیا relation مورد نظر واقعاً لود شده یا نه.

return [
    'id' => $this->id,
    'name' => $this->name,
    'posts' => PostResource::collection($this->whenLoaded('posts')),
];

✅ نتیجه:

اگر توی query نوشتیم:

User::with('posts')->get();

اون موقع posts داخل JSON میاد.

اگر with('posts') رو ننوشتیم، اصلا posts توی خروجی دیده نمیشه.


📌 مزایا

شماره ۱ : API سبک‌تر → فقط دیتاهایی که لازم داری ارسال میشن.


شماره ۲: کد تمیزتر → دیگه خبری از if/else‌ های شلوغ داخل Resource نیست.


شماره۳: کنترل کامل → هر relation فقط وقتی لود شده باشه به خروجی اضافه میشه.

خلاصه که:

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

@GoldenCodeir

#Laravel #لاراول

(به منبع و مثالش دقت کنید 👇🏾)
https://x.com/wendell_adriel/status/1967917256446267886?t=nJdmRFIvFlZGiL09jL8LuQ&s=35

مفهوم D (Durability) در ACID

وقتی یک transaction در دیتابیس COMMIT میشه، باید مطمئن باشیم تغییراتش برای همیشه ذخیره شدن و حتی در صورت قطع برق یا crash سیستم از بین نمیرن. این همون Durability (ماندگاری) هستش.

💡یه مثال :
وقتی پول از حساب بانکیت به حسابه دوستت منتقل میشه و پیام "انتقال موفق بود" میگیری، حتی اگه برق دیتاسنتر قطع بشه، دیتابیس تضمین میکنه که تراکنش انجام شده . این همون Durability هستش.


📌 روش‌های اصلی برای تضمین Durability:

شماره ۱. Write-Ahead Logging (WAL)

تغییرات ابتدا در WAL ثبت میشن و بعدش روی داده‌های اصلی اعمال میشن.
تا زمانیکه تغییرات در WAL ثبت نشده باشن، هیچ تضمینی برای ماندگاری داده‌ها وجود نداره.
✅ در صورت crash، تراکنش های commit شده با WAL قابل بازیابی هستنن.


شماره ۲. Redo / Undo Logs

بخش Redo: مکانیزمی برای بازگرداندن تغییرات تراکنش‌های commit شده پس از crash

بخش Undo: مکانیزمی برای rollback تراکنش‌های ناقص یا aborted

📌 رایج در Oracle و SQL Server و بخش مهمی از Crash Recovery هستش.


شماره ۳. fsync / Force-write

بعده هر COMMIT، داده‌ها از حافظه کش و OS به دیسک واقعی منتقل میشن.
این کار امنیت داده‌ها رو بالا میبره، اما سرعت transaction هارو کمی کاهش میده.


شماره ۴. Replication & Backup

تغییرات میتونن روی سرورهای دیگه کپی بشن یا snapshot گرفته بشن.

📌 این روش‌ها به تنهایی Durability رو تضمین نمیکنن و بیشتر برای Disaster Recovery کاربرد دارن.

Trade-off بین سرعت و ماندگاری (Performance vs Durability)

حالت strict: بعده هر transaction، همه تغییرات حتما روی دیسک نوشته میشن. درین حالت Durability بالاست، اما سرعت transaction ها کمتر خواهد بود.

حالت lazy: تغییرات ممکنه کمی دیرتر روی دیسک نوشته بشن. درین حالت سرعت transaction هابالاتره، اما Durability کمی پایینتر خواهد بود.

📌 مثال در دیتابیس‌ها

PostgreSQL – synchronous_commit:

وقتی این تنظیم فعال باشه، بعده هر transaction، تغییرات حتما روی دیسک نوشته میشن تا Durability تضمین بشه. اگه غیرفعال باشه، transaction سریعتر انجام میشه ولی ممکنه تغییرات کمی دیرتر روی دیسک ذخیره بشن.

MySQL – innodb_flush_log_at_trx_commit:

اگه مقدار این پارامتر روی 1 باشه، بعده هر transaction، تغییرات فورا روی دیسک نوشته میشن (Durability بالا، سرعت کمتر). اگه مقدار روی 2 یا 0 باشه، سرعت بالاتره ولی ممکنه در صورت crash، آخرین transaction ها از دست برن.

#ACID #دیتابیس

@GoldenCodeir 🔥

خیلی مواقع بعده گرفتنه داده از دیتابیس، نیاز داریم سریع و تمیز به اطلاعات دسترسی داشته باشیم.
تابع array_column در PHP دقیقا برای همین ساخته شده!

🔹 چی کار میکنه؟

میتونه از یک آرایه چندبعدی، فقط یک ستون رو جداکنه.

حتی میتونه آرایه رو با کلید دلخواهتون reindex کنه.

این یعنی: دیگه لازم نیست هر بار روی آرایه حلقه بزنی و جستجو کنی، دسترسی مستقیم داری.

📌 یه مثال:

$users = [
    ['id' => 1, 'name' => 'Ali',  'email' => 'ali@example.com'],
    ['id' => 2, 'name' => 'Sara', 'email' => 'sara@example.com'],
    ['id' => 3, 'name' => 'Reza', 'email' => 'reza@example.com'],
];

// Reindex بر اساس id
$indexed = array_column($users, null, 'id');

✅ حالا $indexed[2] مستقیما اطلاعات Sara رو برمیگردونه،
بدون هیچ حلقه یا جستجوی اضافه.


کاربردهاش؟

ساخت lookup table سریع

کدنویسی تمیزتر و کوتاه‌تر

عالی برای caching و join کردن دیتاست‌ها

خلاصه که : با array_column میتونیم از یک آرایه ساده، یک ساختار قوی برای دسترسی مستقیم بسازیم.
یک ترفند کوچیک، اما تاثیره بزرگ در سرعت و خوانایی کد.
#php #اموزش_php #php_tip

@GoldenCodeir

(به منبع و مثالش توجه کنید👇🏾)
https://x.com/wendell_adriel/status/1969010695279989061?t=h88vjyQnlMap9vvVDFxhXQ&s=35

یکی از قابلیت‌های جذاب کش در لاراول، Cache Tags هست.
با Tag میتونی چند داده کش شده رو زیر یک تگ مشخص گروه‌بندی کنی. اینطوری مدیریت اونا (پاک‌کردن یا بروزرسانی) خیلی راحتتر میشه.


📌 چرا به درد میخوره؟

فرض کن اپلیکیشن چند تیمی (multi-tenant) داری. هر تیم تنظیمات خودشو داره که توی کش ذخیره میکنی.
حالا اگه بخوای همه کش‌های مربوط به یک تیم خاص رو پاک کنی، با Tag خیلی ساده میشه:

// ذخیره داده‌ها با تگ team-1
Cache::tags(['team-1'])->put('settings', ['lang' => 'fa', 'timezone' => 'Asia/Tehran'], 3600);

// ذخیره داده دیگه با همون تگ
Cache::tags(['team-1'])->put('members', ['Ali', 'Sara'], 3600);

// پاک کردن همه کش‌های team-1
Cache::tags(['team-1'])->flush();

⚠️ یه نکته مهم

این Cache Tags فقط روی درایورهای Redis و Memcached پشتیبانی میشن.
روی file، database یا dynamodb کار نمیکنه.


خلاصه که:

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

#Laravel #Laravel_tip #لاراول

@GoldenCodeir 🔥

(به‌منبع و مثالش دقت کنید 👇🏾)
https://x.com/wendell_adriel/status/1971180406717210806?t=l7I87aVOAwuBep_DjhW18A&s=35

در نسخه‌ی ۱۲ لاراول، یک قابلیت کاربردی اضافه شده:
میتونید ستونهای Eloquent رو بصورت خودکار به رشته HTML امن (HtmlString) cast کنید.

🔹 چرا مهمه؟

وقتی ستونی مثل content یا denoscription شامل HTML باشه، معمولا باید توی Blade با {!! !!} چاپش کنیم. اما حالا لاراول خودش این کار رو مدیریت می‌کنه و مقدار رو به صورت HtmlString برمیگردونه.


📌 یه مثال

use Illuminate\Database\Eloquent\Casts\AsHtmlString;

class Post extends Model
{
    protected $casts = [
        'content' => AsHtmlString::class,
    ];
}

حالا براحتی میتونین در Blade بنویسین:

{{ $post->content }}

و خروجی HTML به درستی رندر میشه


نتیجش:
با AsHtmlString::class کدی تمیزتر، امن‌تر و راحت‌تر برای کار با ستون‌های حاوی HTML در لاراول 12 خواهیم داشت.

#Laravel #Laravel_tip #لاراول

@GoldenCodeir 🔥

(به‌منبع و مثالش دقت کنید 👇🏾)
https://x.com/iamgurmandeep/status/1972171914891207129?t=p2MJGutuSORj99oSJ5woww&s=35

وقتی با Eloquent توی لاراول کار میکنیم، معمولا برای فیلتر کردن رکوردها از where استفاده میکنیم. مثلا:

User::where('email', $email)
    ->where('password', $password)
    ->first();

این روش خوبه، اما لاراول یه قابلیت بهتر و کاربردی داره به اسم Dynamic Where ✨
یعنی میتونیم همون کد بالا رو اینطوری بنویسیم:

User::whereEmailAndPassword($email, $password)->first();

چطوری کار میکنه؟

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

وقتی میگی whereEmailAndPassword، خودش میفهمه باید روی ستون‌های email و password شرط بذاره.

بین فیلدها میتونی از And یا Or استفاده کنی.

مثال‌:

// شرط روی دو ستون
User::whereNameAndAge('Ali', 30)->first();

// شرط OR
User::whereEmailOrUsername($value, $value)->first();

📌 کجا به درد می‌خوره؟

لاگین یا احراز هویت سریع

جستجوهای ساده و کوتاه

کار با کلیدهای ترکیبی (Composite Keys)


خصلاش که:
این Dynamic Where خیلی وقت‌ها باعث میشن کد کوتاه‌تر، خواناتر و باشه.
#Laravel #Laravel_tip #لاراول

@GoldenCodeir 🔥

(به منبع و مثالش دقت کنید 👇🏾)
https://x.com/Akr4mKhan/status/1973387425268507003?t=PqAyceJRXsgErfUOp8_wtQ&s=35

ولی اگه از برنامه نویسی نمی تونین پول دربیارین زیاد خودتونو ناراحت نکنین

ذات درست پول در آوردن از برنامه نویسی بیشتر Passive هستش (یعنی کاری نکنین و پول در بیارین) و نسبت به درآمد های Active خیلی دیرتر نتیجه می‌ده ولی نتیجه بده می‌برتتون هوا، درآمد های Passive همه نوع آزادی بهتون می‌ده از آزادی وقت بگیر تا امنیت پولی و آرامش روانی؛ اگه دارین به صورت Passive حتی یک میلیون در ماه هم در می‌آرین ارزشش رو 100 برابر در نظر بگیرید.

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

@Linuxor

در بسیاری از پروژه‌ها وقتی داخل یک database transaction هستیم، نیاز داریم بعد از ذخیره‌ی موفق دیتاها یک Event اجرا کنیم (مثل ارسال ایمیل، ثبت لاگ یا بروزرسانی سرویس خارجی).

اما اگه Event قبل از commit اجرا بشه و transaction به هر دلیلی rollback بشه، یک ناسازگاری بزرگ به وجود میاد:

کاربر ایمیل "ثبت موفق" دریافت میکنه، در حالیکه دیتایی ذخیره نشده.

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

🔴 این یعنی Event شما از وضعیت واقعی دیتابیس عقب میمونه.

📌 راه‌حل لاراول براش:

لاراول برای این سناریو یک راه‌حل خیلی تمیز ارائه داده:
کافیه Event شما این اینترفیس رو پیاده‌سازی کنه:

use Illuminate\Contracts\Events\ShouldDispatchAfterCommit;

class OrderCreated implements ShouldDispatchAfterCommit
{
    public $order;

    public function __construct($order)
    {
        $this->order = $order;
    }
}

وقتی این Event رو dispatch کنید:

event(new OrderCreated($order));

لاراول تضمین میکنه که اجرای Event فقط بعده موفقیت کامل transaction و commit نهایی اتفاق بیفته.

#Laravel #Laravel_tip #لاراول

@GoldenCodeir 🔥

(به‌منبع و مثالش دقت کنید 👇🏾)
https://x.com/wendell_adriel/status/1974077531943838164?t=ZlSaB6_aM-qXwNDa_ttadw&s=35

این هلپرفانکشن tap() یکی از اون ویژگی‌های جالبه لاراوله که باعث میشه کدها هم تمیزتر بشن، هم خواناتر.

گاهی لازمه روی یه شی عملی انجام بدی (مثلن تغییر، ذخیره یا لاگ گرفتن)
اما در نهایت بخوای خود اون شی رو برگردونی و نه نتیجه‌ی عملیات.
اینجاست که tap() کاربرد داره.

📌 مثال:

$user = tap(new User, function ($user) {
    $user->name = 'Ali';
    $user->email = 'ali@example.com';
    $user->save();
});

در اینجا:

داخل tap() با $user هر کاری خواستیم کردیم؛

ولی خروجی، همون $user هست — نه نتیجه‌ی تابع.

کاربرد اصلی وقتی وسط یه chain از متودها بخوای کاری انجام بدی، بدون اینکه زنجیره قطع بشه:

return tap(User::find(1))
    ->update(['active' => false])
    ->refresh();

یا حتی داخل Query Builder:

$users = tap(DB::table('users'), function ($query) {
    $query->where('active', true);
})->get();

#Laravel #Laravel_tip #لاراول

@GoldenCodeir 🔥

(به منبع و مثالش دقت کنید 👇🏾)
https://x.com/laravelbackpack/status/1974074465010208832?t=neGDBuWocqlJjIOARSUOmg&s=35

🔶 بوت استرپ نسخه ۶

افزودن کلاس های جدید برای ایحاد رنگ بندی جدید

@TheRaymondDev

نگاهی به تغییرات مهم نسخه 6

طبق اعلام تیم Bootstrap، در نسخه‌ی Bootstrap v6 سیستم رنگ و تم به شکل کامل بازطراحی خواهد شد.

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

کلاس‌های سراسری به‌جای کلاس‌های اختصاصی

قبلن برای هر کامپوننت کلاس جدا داشتیم مثل:

.btn-primary یا .alert-primary.

📌 اما در نسخه 6، کلاس‌های رنگی سراسری شدن — مثلن فقط از .theme-primary استفاده میکنید و همه‌ی اجزای داخل اون از همون تم پیروی میکنند.

کد ساده‌تر، طراحی منسجمتر

تطبیق خودکار با حالت تیره/روشن

نسخه جدید از تابع مدرن CSS بنام light-dark() استفاده میکنه،
بنابرین رنگ‌ها به‌صورت خودکار با حالت سیستم (Dark/Light Mode) هماهنگ میشن — بدون نیاز به media query.


رنگ‌ها

رنگ‌های تازه مثل Violet، Amber، Lime، Brown و Pewter اضافه شده‌اند.
همچنین، درجات خیلی روشن و خیلی تیره (025, 050, 950, 975) برای هر رنگ در دسترسه.

📎 در کل:
نسخه‌ی 6 تمرکز داره روی این موارد:

یکپارچه‌سازی تم‌ها،

کاهش تکرار در کلاس‌ها،

و پشتیبانی هوشمند از حالت تیره.

نتیجش هم طراحی ساده‌تر، مدرن‌تر و حرفه‌ای‌تر برای تمام کامپوننت‌ها.

#bootstrap #بوت_استرپ #فرانت

@GoldenCodeir 🔥
(منبع👇🏾 )
https://x.com/getbootstrap/status/1975652460992835762?t=Iqg0G6PDseMk691A4Gbj5A&s=35

اصل S در اصول SOLID یعنی Single Responsibility Principle (اصل تک مسئولیتی)

چی میگه؟
یک کلاس باید فقط یک مسئولیت داشته باشه و فقط یک دلیل برای تغییر. یعنی هر کلاس باید یک نقش مشخص در سیستم داشته باشه و همه کارها رو قاطی نکنه.

چرا این مهمترین اصل SOLIDهستش؟
وقتی یک کلاس چند مسئولیت داشته باشه:

پیدا کردن و رفع باگ سخت میشه،

تغییرات کوچیک تو یه قسمت ممکنه باعث خرابی بخش‌های دیگه بشه،

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

نتیجش:
با رعایت این اصل، کد تمیزتر، قابل فهم‌تر و قابل تست‌تر میشه.
کلاس‌ها ساده‌تر هستند و وقتی نیاز به تغییر باشه، فقط بخش مرتبط اصلاح میشه بدون اینکه باقی سیستم آسیب ببینه.
#SOLID

@GoldenCodeir 🔥
(منبع👇🏾)
https://www.linkedin.com/posts/ali-mohammadi-5b7375389_solid-activity-7382848511261773824-diAJ?utm_source=share&utm_medium=member_android&rcm=ACoAAF-g0BsBHAA03jv74SJdJwUrgHFqATrvXb8

بلاخره React از مِتا جدا شد!

بعد بیش از ۱۰ سال، React قراره تحت یه بنیاد مستقل به نام React Foundation اداره بشه ( زیر چتر Linux Foundation )
یعنی از این به بعد تصمیم گیری ها و سرنوشت ری اکت، دیگه فقط دست Meta نیست و جامعه دولوپرها و شرکت‌های دیگه هم تو جهت دهی آینده React نقش دارن!

و این یعنی شفافیت، مشارکت و تنوع بیشتر در توسعه کتابخونه دوست داشتنی ری اکت

بنظرم React داره یه فصل جدید از داستانش رو شروع میکنه…
ری اکت دیگه صرفا پروژه یه شرکت نیست، بلکه نتیجه ی همکاری یه جامعه ی جهانی از دولوپر هاست


@DevTwitter | <Ahmad Ahmad-Nejad/>