پیکربندی v/s ترکیب – طراحی اجزای قابل استفاده مجدد

سلام مردم!! در این مقاله، ما با نحوه طراحی API های مؤلفه برای سیستم طراحی خود و قابل استفاده مجدد آن در تیم های مختلف، با بهینه ترین روش و پیروی از دستورالعمل های اصول طراحی آشنا خواهیم شد.

ما رویکردهای مختلف برای ساختن APIهای مؤلفه را بررسی خواهیم کرد.

🎯 الزامات جزء

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

ایجاد یک را در نظر بگیرید هشدار کامپوننت که چیزی شبیه به این به نظر می رسد:

اجازه دهید ابتدا کل مؤلفه را به زیر مؤلفه های کوچکتر تقسیم کنیم.

را هشدار جزء شامل زیربخش های زیر است:

1. عنوان

   می تواند یک باشد string یا ممکن است اختیاری باشد

2. پیام

   پیام می تواند شامل متن چند خطی یا هر جزء دیگر باشد. بنابراین ما می توانیم نوع آن را به درست کنیم string | ReactNode

3. دکمه های اکشن

   این شامل هر جزء است که در آن ورودی از کاربر مورد نیاز است. ممکن است از چندین دکمه یا هر جزء دیگر تشکیل شده باشد یا ممکن است یک فیلد اختیاری باشد.

   نوع آن تنظیم شده است ReactNode | undefined

4. آیکون

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

5. انواع

   

   مؤلفه هشدار می تواند تحت چندین گونه باشد و بر اساس نوع رنگ انواع، سبک قلم زیربخش های آن (عنوان، پیام، نماد) تغییر می کند.

6. الگوها

   از آنجایی که برخی از زیربخش‌ها در مؤلفه Alert اختیاری هستند و کاربر می‌تواند مؤلفه سفارشی خود را نیز اضافه کند، این منجر به الگوهای متعدد می‌شود.

   

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

🎯 پیکربندی

در رویکرد Configuration، کاربر می‌تواند داده‌ها را از طریق props به کامپوننت ارسال کند، و کامپوننت باید دقیقاً بداند که چگونه خود را بر اساس آن props ارائه کند.

بیایید با مثال بالا از مولفه Alert حرکت کنیم و ببینیم که چگونه API آن را با استفاده از یک رویکرد پیکربندی طراحی کنیم.

const Alert = (props) => {
    const {
        title,
        description,
        actions,
        iconName, 
        iconSize, 
        iconPosition='left', 
        iconColor, 
        variant 
    } = props;

    return (
        <div className={variantClass}>
          {iconName && 
            <Icon 
              name={iconName} 
              size={iconSize} 
              position={iconPosition} 
              appearance={iconColor} 
            />
          }
          <div>
            {title && <Heading>{title}</Heading>}
            {message && <Paragraph>{description}</Paragraph>}
            {actions && (
              <div>{actions}</div>
            )}
         </div>
        </div>

    )
}

export default Alert;

کاربران می توانند با استفاده از API زیر از این مؤلفه استفاده کنند:

<Alert 
  title='Title goes here'
  description='Message goes here'
  variant='warning'
  iconName='warning_check'
  iconPosition='right'  
  actions={
    <div>
      <Button>Action 1</Button>
      <Button>Action 2</Button>
    </div>
  }
/>

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

📍 جوانب مثبت:

• سریع و آسان برای استفاده. عملکردهای مختلف و انواع بصری را می توان با پیکربندی پایه ها کنترل کرد.

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

📍 معایب:

• افزودن ویژگی‌های بیشتر به لوازم بیشتر و منطق شرطی نیاز دارد. بنابراین نگهداری یک جزء سخت تر می شود.

• تمدید آسان نیست.

• نادیده گرفتن آن آسان نیست

• اگر کامپوننتی را نمی توان گسترش داد، ممکن است نیاز به ساخت نسخه جدید باشد.

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

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

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

🎯 ترکیب بندی

در رویکرد ترکیب، کاربران باید بتوانند بلوک های ساختمانی کوچک را بگیرند و آنها را به هر ترتیبی که دوست دارند با هم ترکیب کنند.

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

<Alert variant='warning'>
    <Alert.Container>
        <Alert.Title>
            Title goes here
        </Alert.Title>
        <Alert.Description>
            <div>Hello World!!</div>
            <Badge>Description</Badge>
            <Paragraph>Short Description</Paragraph>
        </Alert.Description>
        <Alert.Action>
          <div>
            <Button>Action 1</Button>
            <Button>Action 2</Button>
          </div>
        </Alert.Action>
        <Alert.Icon name='warning_check' />
    <Alert.Container>
</Alert>

در کد بالا، کاربر می تواند به جای ارسال چندین props، از زیرمجموعه های کوچکتر برای سفارشی سازی استفاده کند. به عنوان مثال، به جای ارسال توضیحات به عنوان a string آنها همچنین می توانند شرح سفارشی طراحی شده را بر اساس مورد استفاده خود ارسال کنند. و همچنین موقعیت آیکون را به سمت راست تغییر دهید.

همه اینها فقط بلوک های ساختمانی هستند که به آنها عادت کرده اند ساختن عملکرد بر اساس موارد استفاده مختلف.

📍 جوانب مثبت:

📍 معایب:

• برای ایجاد یک جزء/ویژگی کاملاً کارآمد، باید بلوک‌های ساختمان را خودتان بسازید.

• زمان و کد بیشتری می گیرد.

• جدا شدن از سیستم طراحی و ارائه رابط کاربری و رفتار ناسازگار به راحتی امکان پذیر است.

🎯 از کدام رویکرد استفاده کنیم؟

هر دو روش همانطور که در بالا می بینیم دارای مزایا و معایب خود هستند. سپس سوال این است که از کدام و چه زمانی استفاده کنیم؟

رویکردی که می خواهید استفاده کنید کاملاً به مورد استفاده و الگوی طراحی شما بستگی دارد. ممکن است مواردی وجود داشته باشد که بتوانیم از هر دو رویکرد برای برآورده کردن موارد استفاده خود به طور مناسب استفاده کنیم.

🎯 خلاصه

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

از سوی دیگر، پیکربندی رویکرد کمتر انعطاف‌پذیر است، اما استفاده از آن ساده‌تر است و پایبندی به سیستم طراحی را آسان‌تر می‌کند.

🎯 بسته شدن!!

این همه برای این مقاله است. ممنون بخاطر وقتی که گذاشتید!! بیایید برای یادگیری و رشد با هم ارتباط برقرار کنیم. لینکدین توییتر اینستاگرام