ایده‌هات رو سریع‌تر از همیشه بساز

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

این ایده توی UX به Edit in Place معروفه؛ یعنی کاربر بتونه یه مقدار رو همون جایی که میبینه، ویرایش کنه.

مثلاً توی یه پنل مدیریت فروشگاه، لیست محصولات رو داریم و موجودی هر محصول هم کنار اون نمایش داده میشه.

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

کاربر برای یه تغییر ساده مجبور نیست صفحه رو ترک کنه، چیزی رو پیدا کنه و دوباره برگرده.

یجورایی لازم نیست برای یه کار ساده، کاربر رو از چند مرحله رد کنیم :)

توی TypeScript اگه بخوایم از یه Type استفاده کنیم ولی چندتا property اون رو نداشته باشیم، می‌تونیم از Omit استفاده کنیم.

مثلاً:

type User = {
  id: number
  name: string
  email: string
}

type CreateUser = Omit<User, 'id'>

اینجا CreateUser همه‌ی propertyهای User رو داره، به جز id.

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

اگه بیشتر از یه property رو هم نخواستیم، اسم propertyها رو با | از هم جدا می‌کنیم:

type CreateUser = Omit<User, 'id' | 'email'>

اینجا CreateUser فقط name رو داره.

برای Typeهایی که خیلی شبیه هم هستن، این می‌تونه جلوی کلی تکرار رو بگیره.

یه اصطلاح توی برنامه‌نویسی هست با عنوان Technical Debt یا بدهی فنی.

وقتی برای اینکه سریع‌تر به نتیجه برسیم، یه راه‌حل موقتی یا نه‌چندان اصولی انتخاب می‌کنیم و می‌ذاریم تمیز کردن یا بهتر کردنش رو برای بعد، در واقع داریم Technical Debt ایجاد می‌کنیم.

مثلاً یه بخشی از کد رو می‌دونیم میشه بهتر نوشت، ولی چون الان عجله داریم یا کارهایی با اولویت بالاتری وجود داره، همونطوری که هست نگهش می‌داریم و میگیم بعداً برمی‌گردیم سراغش.

این کار همیشه هم اشتباه نیست؛ گاهی یه تصمیم آگاهانه‌ست برای اینکه سریع‌تر جلو بریم. چیزی که مشکل‌ساز میشه اینه که این بدهی‌ها زیاد بشن و هیچ‌وقت براشون وقت نذاریم.

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

گاهی سریع‌تر جلو رفتن ارزش ایجاد کردن بدهی فنی رو داره؛ به شرطی که بعداً فراموشش نکنیم :)

وقتی تو ایران زندگی می‌کنی، Ctrl+C بخشی از فرایند ارسال پرامپته :)

برای پیاده‌سازی قابلیت چندزبانه توی Laravel می‌تونیم از پکیج laravel-translatable از Spatie استفاده کنیم.

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

اول پکیج رو نصب می‌کنیم:

composer require spatie/laravel-translatable

مثلاً فرض کنیم مدل Product داریم و می‌خوایم name و description چندزبانه باشن. توی migration، این فیلدها رو به‌صورت json تعریف می‌کنیم:

$table->json('name');
$table->json('description');

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

use Spatie\Translatable\HasTranslations;

class Product extends Model
{
    use HasTranslations;

    public array $translatable = [
        'name',
        'description',
    ];
}

حالا مقدار name می‌تونه چیزی شبیه این باشه:

{
    "fa": "محصول جدید",
    "en": "New product"
}

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

$product->setTranslation('name', 'fa', 'محصول جدید');
$product->setTranslation('name', 'en', 'New product');

$product->save();

اینجوری اضافه شدن زبان جدید هم به تغییر ساختار جدول نیاز نداره؛ فقط ترجمه‌ی زبان جدید به همون JSON اضافه می‌شه.

ایده‌ی اصلی پکیج هم دقیقاً همینه: چندزبانه بودن رو داخل خود فیلد مدیریت کنیم، نه با اضافه کردن ستون برای هر زبان.

🔗 مشاهده در GitHub

از وقتی دسترسی تولید محتوا توی Signal رو برای همه باز کردم، باز هم فقط خودم دارم می‌نویسم 😐

بعضی وقت‌ها فکر می‌کنم دارم با خودم حرف می‌زنم 😂

شما هم هرچی دوست دارید بنویسید، راحت باشید 🌹😬

تقریبا تمام صفحات SpaceDev رو با Livewire ساختم و تا الان واقعاً از انتخابم راضی بودم. با اینکه SpaceDev نسبت به چیزی که اول بود بزرگ‌تر شده، هنوز موردی ندیدم که باعث بشه فکر کنم انتخاب اشتباهی کردم یا باید سراغ گزینه دیگه‌ای می‌رفتم.

توی نسخه‌های قدیمی‌تر Livewire برای داشتن navigation بدون reload میشد Turbolinks رو کنارش استفاده کرد. اون موقع همین ترکیب تجربه نسبتاً خوبی می‌داد.

اما الان با "wire:navigate" این کار خیلی راحت‌تر شده و برای جابه‌جایی بین صفحات، دیگه لازم نیست راه‌حل جداگانه‌ای کنارش داشته باشیم..

شاید یه روزی برسه که Livewire دیگه برای نیازهای SpaceDev کافی نباشه و مجبور بشم مسیر دیگه‌ای رو انتخاب کنم؛ ولی فعلاً که راضی‌ام :)

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

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

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

مینیمال یعنی ساده‌تر کردن UI، نه خالی‌تر کردنش.

minimal ≠ empty

توی لاراول، متد undot() برای تبدیل کلیدهای دارای . به یک ساختار تو‌در‌تو در Collection استفاده می‌شه.

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

$settings = collect([
    'notifications.email' => true,
    'notifications.sms' => false,
    'appearance.theme' => 'dark',
]);

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

$settings = $settings->undot();

نتیجه:

[
    'notifications' => [
        'email' => true,
        'sms' => false,
    ],
    'appearance' => [
        'theme' => 'dark',
    ],
]

با undot() می‌تونیم کلیدهای دارای . رو به ساختار تو‌در‌تو تبدیل کنیم، بدون اینکه خودمون این ساختار رو بسازیم.