Scroll Shadow
لایهٔ نازکی از سایه که روی لبهٔ یک ناحیهٔ اسکرولپذیر مینشیند و فقط وقتی محتوای بیشتری در آن جهت هست دیده میشود. جای اسکرولبار سفارشی را نمیگیرد؛ کنارش یا بهجای اسکرولبار بومی استفاده میشود تا سرریز محتوا بدون هیچ عنصر اضافهای حس شود.
این کامپوننت فعلاً برای ۱ فریمورک از ۴ فریمورک آماده است.
دیزاینسیستم مجموعهای از قطعههای آماده، قاعدههای تصمیم و زبان مشترک است که تیم طراحی و توسعه را همجهت نگه میدارد. هدفش این نیست که خلاقیت را محدود کند؛ برعکس، با حذف تصمیمهای تکراری روی جزئیات، وقت تیم را برای مسائل واقعی محصول آزاد میکند.
هر کامپوننت در دیگ سه لایه دارد: خودِ نشانهگذاری، رفتار تعاملی و توکنهای بصری. این جدایی یعنی تغییر رنگ برند یا اندازهٔ فونت هیچوقت به معنی نوشتن دوبارهٔ منطق نیست.
راستبهچپبودن یک ویژگیِ اضافه نیست؛ از همان لایهٔ اول تصمیمگیری بخشی از معماری بوده. جهت نوشتار، جای دکمهها، انیمیشنهای ورود و حتی آیکونهای جهتدار همه با dir صفحه هماهنگ میشوند.
سایهٔ اسکرول یک نشانهٔ ظریف بصری است، نه یک اسکرولبار سفارشی. وقتی محتوا از کادر بیرون میزند، کاربر باید بدون نیاز به اسکرول کردن حدس بزند که ادامهای هست؛ یک محو تدریجی در لبه دقیقاً همین کار را میکند.
در بسیاری از رابطهای کاربری، اسکرولبار بهخاطر دلایل زیباییشناسی پنهان میشود. اما پنهانکردن اسکرولبار بدون جایگزین بصری، نشانهٔ سرریز محتوا را از بین میبرد؛ سایهٔ اسکرول دقیقاً همین خلأ را پر میکند.
تفاوت حالت خودکار و حالت ثابت در دیدپذیری سایه مهم است: در حالت خودکار سایه واقعاً موقعیت اسکرول را دنبال میکند، اما در حالت ثابت طراح میتواند برای یک قاب یا تصویر ثابت، سایه را عمداً روی یک لبه قفل کند.
اندازهٔ سایه و حاشیهٔ فعالسازی هر دو قابل تنظیماند تا این کامپوننت هم برای یک لیست باریک کناری و هم برای یک ناحیهٔ بزرگ محتوا به یک اندازه خوب کار کند.
در نهایت، هر قطعهای در این سیستم باید بدون وابستگی بیرونی کار کند؛ فقط Tailwind و ریاکت. این یعنی نصب یک کامپوننت هیچوقت باعث نمیشود بستهٔ نهاییِ پروژهٔ شما بزرگتر از حد لازم شود.
این نمونه هنوز برای Vue پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Svelte پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Angular پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
نصب
با CLI اختصاصی dig-ui کامپوننت را از رجیستری دیگ نصب کنید؛ وابستگیها و فایلها خودکار اضافه میشوند.
pnpm dlx dig-ui@latest add https://design-system-tau-green.vercel.app/r/scroll-shadow.jsonnpx dig-ui@latest add https://design-system-tau-green.vercel.app/r/scroll-shadow.jsonyarn dlx dig-ui@latest add https://design-system-tau-green.vercel.app/r/scroll-shadow.jsonbunx --bun dig-ui@latest add https://design-system-tau-green.vercel.app/r/scroll-shadow.jsonاین کامپوننت هنوز برای Vue پورت نشده است.
نسخهٔ ریاکت آماده است؛ پورت این فریمورک روی Reka UI در دست کار است.
این کامپوننت هنوز برای Svelte پورت نشده است.
نسخهٔ ریاکت آماده است؛ پورت این فریمورک روی Bits UI در دست کار است.
این کامپوننت هنوز برای Angular پورت نشده است.
نسخهٔ ریاکت آماده است؛ پورت این فریمورک روی Angular CDK در دست کار است.
استفاده
import { ScrollShadow } from "@/components/ui/scroll-shadow"
<div className="h-72 w-full max-w-sm overflow-hidden rounded-md border">
<ScrollShadow className="h-full">محتوای بلند…</ScrollShadow>
</div>این کامپوننت هنوز برای Vue پورت نشده است.
نسخهٔ ریاکت آماده است؛ پورت این فریمورک روی Reka UI در دست کار است.
این کامپوننت هنوز برای Svelte پورت نشده است.
نسخهٔ ریاکت آماده است؛ پورت این فریمورک روی Bits UI در دست کار است.
این کامپوننت هنوز برای Angular پورت نشده است.
نسخهٔ ریاکت آماده است؛ پورت این فریمورک روی Angular CDK در دست کار است.
ترکیب اجزا
دسترسپذیری
- چون خودِ عنصر overflow-auto دارد، با چرخ ماوس، لمس و کشیدن اسکرولبار بومی کار میکند؛ چیزی از رفتار پیشفرض مرورگر گرفته نمیشود.
- سایه فقط یک نشانهٔ بصری اضافه است، نه جایگزین اطلاعرسانی؛ برای کاربرانی که mask-image پشتیبانی نمیشود (مرورگرهای بسیار قدیمی) محتوا هنوز کامل قابل اسکرول است، فقط سایه دیده نمیشود.
- برای دسترسی با صفحهکلید یک tabIndex={0} و aria-label مناسب روی ScrollShadow بگذارید تا با کلیدهای جهتدار قابل اسکرول شود.
- در حالت hideScrollbar کاربرانی که با موس کار میکنند نشانهٔ کمتری برای «چقدر مانده» دارند؛ برای فهرستهای خیلی بلند اسکرولبار را پنهان نکنید.
مرجع API
ScrollShadow
| ویژگی | نوع | پیشفرض | توضیح |
|---|---|---|---|
| orientation | "vertical" | "horizontal" | "vertical" | محور اسکرول و در نتیجه لبههایی که سایه میگیرند. |
| size | number | 40 | اندازهٔ ناحیهٔ محوشوندهٔ سایه به پیکسل. |
| offset | number | 0 | حاشیهای به پیکسل که پیش از رسیدن دقیق به لبه، سایه را نگه میدارد یا حذف میکند. |
| hideScrollbar | boolean | false | پنهانکردن نوار اسکرول بومی؛ اسکرول با چرخ ماوس/لمس همچنان کار میکند. |
| visibility | "auto" | "top" | "bottom" | "left" | "right" | "both" | "none" | "auto" | «auto» سایه را از روی موقعیت واقعیِ اسکرول محاسبه میکند. مقادیر دیگر آن را روی یک لبهٔ ثابت قفل میکنند (top/bottom برای عمودی، left/right برای افقی). |
| enabled | boolean | true | با false کاملاً سایه را خاموش میکند؛ اسکرول خودش دستنخورده میماند. |
| onVisibilityChange | (visibility: "top" | "bottom" | "left" | "right" | "both" | "none") => void | — | هر بار لبهٔ سرریز واقعاً عوض شود صدا زده میشود؛ صرفنظر از مقدار visibility. |
| className | string | — | اینجا حتماً ارتفاع یا عرض بدهید؛ بدون اندازهٔ ثابت هیچوقت سرریزی برای نشاندادن نیست. اگر کادر دور میخواهید، آن را روی یک والدِ overflow-hidden بگذارید نه اینجا. |
data-slot
| ویژگی | نوع | پیشفرض | توضیح |
|---|---|---|---|
| scroll-shadow | div | — | عنصر اسکرولپذیر؛ data-orientation و data-edge («none»/«both» یا برحسب جهت: «top»/«bottom»/«left»/«right») هم روی همین عنصرند. |
این کامپوننت هنوز برای Vue پورت نشده است.
نسخهٔ ریاکت آماده است؛ پورت این فریمورک روی Reka UI در دست کار است.
این کامپوننت هنوز برای Svelte پورت نشده است.
نسخهٔ ریاکت آماده است؛ پورت این فریمورک روی Bits UI در دست کار است.
این کامپوننت هنوز برای Angular پورت نشده است.
نسخهٔ ریاکت آماده است؛ پورت این فریمورک روی Angular CDK در دست کار است.
نمونهها
Horizontal Scroll
با orientation=«horizontal» سایه روی لبهٔ راست و چپ مینشیند؛ فرزند داخلی باید عرض ثابتی بزرگتر از کادر داشته باشد.
دیزاینسیستم مجموعهای از قطعههای آماده، قاعدههای تصمیم و زبان مشترک است که تیم طراحی و توسعه را همجهت نگه میدارد. هدفش این نیست که خلاقیت را محدود کند؛ برعکس، با حذف تصمیمهای تکراری روی جزئیات، وقت تیم را برای مسائل واقعی محصول آزاد میکند.
هر کامپوننت در دیگ سه لایه دارد: خودِ نشانهگذاری، رفتار تعاملی و توکنهای بصری. این جدایی یعنی تغییر رنگ برند یا اندازهٔ فونت هیچوقت به معنی نوشتن دوبارهٔ منطق نیست.
راستبهچپبودن یک ویژگیِ اضافه نیست؛ از همان لایهٔ اول تصمیمگیری بخشی از معماری بوده. جهت نوشتار، جای دکمهها، انیمیشنهای ورود و حتی آیکونهای جهتدار همه با dir صفحه هماهنگ میشوند.
سایهٔ اسکرول یک نشانهٔ ظریف بصری است، نه یک اسکرولبار سفارشی. وقتی محتوا از کادر بیرون میزند، کاربر باید بدون نیاز به اسکرول کردن حدس بزند که ادامهای هست؛ یک محو تدریجی در لبه دقیقاً همین کار را میکند.
در بسیاری از رابطهای کاربری، اسکرولبار بهخاطر دلایل زیباییشناسی پنهان میشود. اما پنهانکردن اسکرولبار بدون جایگزین بصری، نشانهٔ سرریز محتوا را از بین میبرد؛ سایهٔ اسکرول دقیقاً همین خلأ را پر میکند.
تفاوت حالت خودکار و حالت ثابت در دیدپذیری سایه مهم است: در حالت خودکار سایه واقعاً موقعیت اسکرول را دنبال میکند، اما در حالت ثابت طراح میتواند برای یک قاب یا تصویر ثابت، سایه را عمداً روی یک لبه قفل کند.
اندازهٔ سایه و حاشیهٔ فعالسازی هر دو قابل تنظیماند تا این کامپوننت هم برای یک لیست باریک کناری و هم برای یک ناحیهٔ بزرگ محتوا به یک اندازه خوب کار کند.
در نهایت، هر قطعهای در این سیستم باید بدون وابستگی بیرونی کار کند؛ فقط Tailwind و ریاکت. این یعنی نصب یک کامپوننت هیچوقت باعث نمیشود بستهٔ نهاییِ پروژهٔ شما بزرگتر از حد لازم شود.
این نمونه هنوز برای Vue پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Svelte پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Angular پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
Custom Shadow Size
size اندازهٔ ناحیهٔ محوشونده را به پیکسل مشخص میکند؛ پیشفرض ۴۰ است.
دیزاینسیستم مجموعهای از قطعههای آماده، قاعدههای تصمیم و زبان مشترک است که تیم طراحی و توسعه را همجهت نگه میدارد. هدفش این نیست که خلاقیت را محدود کند؛ برعکس، با حذف تصمیمهای تکراری روی جزئیات، وقت تیم را برای مسائل واقعی محصول آزاد میکند.
هر کامپوننت در دیگ سه لایه دارد: خودِ نشانهگذاری، رفتار تعاملی و توکنهای بصری. این جدایی یعنی تغییر رنگ برند یا اندازهٔ فونت هیچوقت به معنی نوشتن دوبارهٔ منطق نیست.
راستبهچپبودن یک ویژگیِ اضافه نیست؛ از همان لایهٔ اول تصمیمگیری بخشی از معماری بوده. جهت نوشتار، جای دکمهها، انیمیشنهای ورود و حتی آیکونهای جهتدار همه با dir صفحه هماهنگ میشوند.
سایهٔ اسکرول یک نشانهٔ ظریف بصری است، نه یک اسکرولبار سفارشی. وقتی محتوا از کادر بیرون میزند، کاربر باید بدون نیاز به اسکرول کردن حدس بزند که ادامهای هست؛ یک محو تدریجی در لبه دقیقاً همین کار را میکند.
در بسیاری از رابطهای کاربری، اسکرولبار بهخاطر دلایل زیباییشناسی پنهان میشود. اما پنهانکردن اسکرولبار بدون جایگزین بصری، نشانهٔ سرریز محتوا را از بین میبرد؛ سایهٔ اسکرول دقیقاً همین خلأ را پر میکند.
تفاوت حالت خودکار و حالت ثابت در دیدپذیری سایه مهم است: در حالت خودکار سایه واقعاً موقعیت اسکرول را دنبال میکند، اما در حالت ثابت طراح میتواند برای یک قاب یا تصویر ثابت، سایه را عمداً روی یک لبه قفل کند.
اندازهٔ سایه و حاشیهٔ فعالسازی هر دو قابل تنظیماند تا این کامپوننت هم برای یک لیست باریک کناری و هم برای یک ناحیهٔ بزرگ محتوا به یک اندازه خوب کار کند.
در نهایت، هر قطعهای در این سیستم باید بدون وابستگی بیرونی کار کند؛ فقط Tailwind و ریاکت. این یعنی نصب یک کامپوننت هیچوقت باعث نمیشود بستهٔ نهاییِ پروژهٔ شما بزرگتر از حد لازم شود.
این نمونه هنوز برای Vue پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Svelte پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Angular پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
Hide Scrollbar
hideScrollbar نوار اسکرول بومی را پنهان میکند؛ خود سایه جایگزین نشانهٔ سرریز میشود، ولی چرخ ماوس و لمس دستنخورده باقی میماند.
این نمونه هنوز برای Vue پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Svelte پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Angular پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
Offset
offset یک حاشیه (به پیکسل) قبل از لبهٔ واقعی تعریف میکند؛ تا وقتی اسکرول داخل این حاشیه است، سایهٔ همان طرف هنوز نمایش داده میشود.
این نمونه هنوز برای Vue پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Svelte پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Angular پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
Fixed Visibility
visibility پیشفرض «auto» است و سایه را بر اساس موقعیت واقعیِ اسکرول نشان میدهد. با دادن top/bottom/both/none سایه از موقعیت واقعی مستقل میشود و همیشه همان لبه را نشان میدهد، برای وقتی طراح میخواهد نشانهای ثابت داشته باشد، نه واکنشی.
دیزاینسیستم مجموعهای از قطعههای آماده، قاعدههای تصمیم و زبان مشترک است که تیم طراحی و توسعه را همجهت نگه میدارد. هدفش این نیست که خلاقیت را محدود کند؛ برعکس، با حذف تصمیمهای تکراری روی جزئیات، وقت تیم را برای مسائل واقعی محصول آزاد میکند.
هر کامپوننت در دیگ سه لایه دارد: خودِ نشانهگذاری، رفتار تعاملی و توکنهای بصری. این جدایی یعنی تغییر رنگ برند یا اندازهٔ فونت هیچوقت به معنی نوشتن دوبارهٔ منطق نیست.
راستبهچپبودن یک ویژگیِ اضافه نیست؛ از همان لایهٔ اول تصمیمگیری بخشی از معماری بوده. جهت نوشتار، جای دکمهها، انیمیشنهای ورود و حتی آیکونهای جهتدار همه با dir صفحه هماهنگ میشوند.
سایهٔ اسکرول یک نشانهٔ ظریف بصری است، نه یک اسکرولبار سفارشی. وقتی محتوا از کادر بیرون میزند، کاربر باید بدون نیاز به اسکرول کردن حدس بزند که ادامهای هست؛ یک محو تدریجی در لبه دقیقاً همین کار را میکند.
در بسیاری از رابطهای کاربری، اسکرولبار بهخاطر دلایل زیباییشناسی پنهان میشود. اما پنهانکردن اسکرولبار بدون جایگزین بصری، نشانهٔ سرریز محتوا را از بین میبرد؛ سایهٔ اسکرول دقیقاً همین خلأ را پر میکند.
تفاوت حالت خودکار و حالت ثابت در دیدپذیری سایه مهم است: در حالت خودکار سایه واقعاً موقعیت اسکرول را دنبال میکند، اما در حالت ثابت طراح میتواند برای یک قاب یا تصویر ثابت، سایه را عمداً روی یک لبه قفل کند.
اندازهٔ سایه و حاشیهٔ فعالسازی هر دو قابل تنظیماند تا این کامپوننت هم برای یک لیست باریک کناری و هم برای یک ناحیهٔ بزرگ محتوا به یک اندازه خوب کار کند.
در نهایت، هر قطعهای در این سیستم باید بدون وابستگی بیرونی کار کند؛ فقط Tailwind و ریاکت. این یعنی نصب یک کامپوننت هیچوقت باعث نمیشود بستهٔ نهاییِ پروژهٔ شما بزرگتر از حد لازم شود.
این نمونه هنوز برای Vue پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Svelte پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Angular پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
Disabled Shadow
با enabled={false} سایه کاملاً خاموش میشود و فقط یک اسکرول عادی و بدون محوشدگی میماند؛ برای مقایسه با حالتهای بالا.
دیزاینسیستم مجموعهای از قطعههای آماده، قاعدههای تصمیم و زبان مشترک است که تیم طراحی و توسعه را همجهت نگه میدارد. هدفش این نیست که خلاقیت را محدود کند؛ برعکس، با حذف تصمیمهای تکراری روی جزئیات، وقت تیم را برای مسائل واقعی محصول آزاد میکند.
هر کامپوننت در دیگ سه لایه دارد: خودِ نشانهگذاری، رفتار تعاملی و توکنهای بصری. این جدایی یعنی تغییر رنگ برند یا اندازهٔ فونت هیچوقت به معنی نوشتن دوبارهٔ منطق نیست.
راستبهچپبودن یک ویژگیِ اضافه نیست؛ از همان لایهٔ اول تصمیمگیری بخشی از معماری بوده. جهت نوشتار، جای دکمهها، انیمیشنهای ورود و حتی آیکونهای جهتدار همه با dir صفحه هماهنگ میشوند.
سایهٔ اسکرول یک نشانهٔ ظریف بصری است، نه یک اسکرولبار سفارشی. وقتی محتوا از کادر بیرون میزند، کاربر باید بدون نیاز به اسکرول کردن حدس بزند که ادامهای هست؛ یک محو تدریجی در لبه دقیقاً همین کار را میکند.
در بسیاری از رابطهای کاربری، اسکرولبار بهخاطر دلایل زیباییشناسی پنهان میشود. اما پنهانکردن اسکرولبار بدون جایگزین بصری، نشانهٔ سرریز محتوا را از بین میبرد؛ سایهٔ اسکرول دقیقاً همین خلأ را پر میکند.
تفاوت حالت خودکار و حالت ثابت در دیدپذیری سایه مهم است: در حالت خودکار سایه واقعاً موقعیت اسکرول را دنبال میکند، اما در حالت ثابت طراح میتواند برای یک قاب یا تصویر ثابت، سایه را عمداً روی یک لبه قفل کند.
اندازهٔ سایه و حاشیهٔ فعالسازی هر دو قابل تنظیماند تا این کامپوننت هم برای یک لیست باریک کناری و هم برای یک ناحیهٔ بزرگ محتوا به یک اندازه خوب کار کند.
در نهایت، هر قطعهای در این سیستم باید بدون وابستگی بیرونی کار کند؛ فقط Tailwind و ریاکت. این یعنی نصب یک کامپوننت هیچوقت باعث نمیشود بستهٔ نهاییِ پروژهٔ شما بزرگتر از حد لازم شود.
این نمونه هنوز برای Vue پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Svelte پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Angular پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
Card Scroll
کاربرد رایج اسکرول افقی: یک ردیف کارت همعرض که بدون نوار اسکرول کنار هم مینشینند و سایهٔ دو طرف نشان میدهد ادامه دارند.
این نمونه هنوز برای Vue پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Svelte پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
این نمونه هنوز برای Angular پورت نشده است؛ آنچه میبینید نسخهٔ ریاکت است.
کدام نمونه برای کدام موقعیت
| نمونه | کجا به کار میآید |
|---|---|
| Horizontal Scroll | با orientation=«horizontal» سایه روی لبهٔ راست و چپ مینشیند؛ فرزند داخلی باید عرض ثابتی بزرگتر از کادر داشته باشد. |
| Custom Shadow Size | size اندازهٔ ناحیهٔ محوشونده را به پیکسل مشخص میکند؛ پیشفرض ۴۰ است. |
| Hide Scrollbar | hideScrollbar نوار اسکرول بومی را پنهان میکند؛ خود سایه جایگزین نشانهٔ سرریز میشود، ولی چرخ ماوس و لمس دستنخورده باقی میماند. |
| Offset | offset یک حاشیه (به پیکسل) قبل از لبهٔ واقعی تعریف میکند؛ تا وقتی اسکرول داخل این حاشیه است، سایهٔ همان طرف هنوز نمایش داده میشود. |
| Fixed Visibility | visibility پیشفرض «auto» است و سایه را بر اساس موقعیت واقعیِ اسکرول نشان میدهد |
| Disabled Shadow | با enabled={false} سایه کاملاً خاموش میشود و فقط یک اسکرول عادی و بدون محوشدگی میماند؛ برای مقایسه با حالتهای بالا. |
| Card Scroll | کاربرد رایج اسکرول افقی: یک ردیف کارت همعرض که بدون نوار اسکرول کنار هم مینشینند و سایهٔ دو طرف نشان میدهد ادامه دارند. |
دستورالعمل استفاده
ارتفاع یا عرض ثابت مشخص
دیزاینسیستم مجموعهای از قطعههای آماده، قاعدههای تصمیم و زبان مشترک است که تیم طراحی و توسعه را همجهت نگه میدارد. هدفش این نیست که خلاقیت را محدود کند؛ برعکس، با حذف تصمیمهای تکراری روی جزئیات، وقت تیم را برای مسائل واقعی محصول آزاد میکند.
هر کامپوننت در دیگ سه لایه دارد: خودِ نشانهگذاری، رفتار تعاملی و توکنهای بصری. این جدایی یعنی تغییر رنگ برند یا اندازهٔ فونت هیچوقت به معنی نوشتن دوبارهٔ منطق نیست.
راستبهچپبودن یک ویژگیِ اضافه نیست؛ از همان لایهٔ اول تصمیمگیری بخشی از معماری بوده. جهت نوشتار، جای دکمهها، انیمیشنهای ورود و حتی آیکونهای جهتدار همه با dir صفحه هماهنگ میشوند.
سایهٔ اسکرول یک نشانهٔ ظریف بصری است، نه یک اسکرولبار سفارشی. وقتی محتوا از کادر بیرون میزند، کاربر باید بدون نیاز به اسکرول کردن حدس بزند که ادامهای هست؛ یک محو تدریجی در لبه دقیقاً همین کار را میکند.
در بسیاری از رابطهای کاربری، اسکرولبار بهخاطر دلایل زیباییشناسی پنهان میشود. اما پنهانکردن اسکرولبار بدون جایگزین بصری، نشانهٔ سرریز محتوا را از بین میبرد؛ سایهٔ اسکرول دقیقاً همین خلأ را پر میکند.
تفاوت حالت خودکار و حالت ثابت در دیدپذیری سایه مهم است: در حالت خودکار سایه واقعاً موقعیت اسکرول را دنبال میکند، اما در حالت ثابت طراح میتواند برای یک قاب یا تصویر ثابت، سایه را عمداً روی یک لبه قفل کند.
اندازهٔ سایه و حاشیهٔ فعالسازی هر دو قابل تنظیماند تا این کامپوننت هم برای یک لیست باریک کناری و هم برای یک ناحیهٔ بزرگ محتوا به یک اندازه خوب کار کند.
در نهایت، هر قطعهای در این سیستم باید بدون وابستگی بیرونی کار کند؛ فقط Tailwind و ریاکت. این یعنی نصب یک کامپوننت هیچوقت باعث نمیشود بستهٔ نهاییِ پروژهٔ شما بزرگتر از حد لازم شود.
انجام بده
همیشه روی ScrollShadow یک ارتفاع یا عرض ثابت بدهید، وگرنه چیزی سرریز نمیکند و سایه هیچوقت دیده نمیشود.
دیزاینسیستم مجموعهای از قطعههای آماده، قاعدههای تصمیم و زبان مشترک است که تیم طراحی و توسعه را همجهت نگه میدارد. هدفش این نیست که خلاقیت را محدود کند؛ برعکس، با حذف تصمیمهای تکراری روی جزئیات، وقت تیم را برای مسائل واقعی محصول آزاد میکند.
هر کامپوننت در دیگ سه لایه دارد: خودِ نشانهگذاری، رفتار تعاملی و توکنهای بصری. این جدایی یعنی تغییر رنگ برند یا اندازهٔ فونت هیچوقت به معنی نوشتن دوبارهٔ منطق نیست.
راستبهچپبودن یک ویژگیِ اضافه نیست؛ از همان لایهٔ اول تصمیمگیری بخشی از معماری بوده. جهت نوشتار، جای دکمهها، انیمیشنهای ورود و حتی آیکونهای جهتدار همه با dir صفحه هماهنگ میشوند.
سایهٔ اسکرول یک نشانهٔ ظریف بصری است، نه یک اسکرولبار سفارشی. وقتی محتوا از کادر بیرون میزند، کاربر باید بدون نیاز به اسکرول کردن حدس بزند که ادامهای هست؛ یک محو تدریجی در لبه دقیقاً همین کار را میکند.
در بسیاری از رابطهای کاربری، اسکرولبار بهخاطر دلایل زیباییشناسی پنهان میشود. اما پنهانکردن اسکرولبار بدون جایگزین بصری، نشانهٔ سرریز محتوا را از بین میبرد؛ سایهٔ اسکرول دقیقاً همین خلأ را پر میکند.
تفاوت حالت خودکار و حالت ثابت در دیدپذیری سایه مهم است: در حالت خودکار سایه واقعاً موقعیت اسکرول را دنبال میکند، اما در حالت ثابت طراح میتواند برای یک قاب یا تصویر ثابت، سایه را عمداً روی یک لبه قفل کند.
اندازهٔ سایه و حاشیهٔ فعالسازی هر دو قابل تنظیماند تا این کامپوننت هم برای یک لیست باریک کناری و هم برای یک ناحیهٔ بزرگ محتوا به یک اندازه خوب کار کند.
در نهایت، هر قطعهای در این سیستم باید بدون وابستگی بیرونی کار کند؛ فقط Tailwind و ریاکت. این یعنی نصب یک کامپوننت هیچوقت باعث نمیشود بستهٔ نهاییِ پروژهٔ شما بزرگتر از حد لازم شود.
انجام نده
بدون کلاس ارتفاع/عرض، ناحیه با محتوا رشد میکند و کل صفحه اسکرول میشود؛ ScrollShadow هیچ کاری نمیکند.
برای سرریز واقعی، نه تزیین
دیزاینسیستم مجموعهای از قطعههای آماده، قاعدههای تصمیم و زبان مشترک است که تیم طراحی و توسعه را همجهت نگه میدارد. هدفش این نیست که خلاقیت را محدود کند؛ برعکس، با حذف تصمیمهای تکراری روی جزئیات، وقت تیم را برای مسائل واقعی محصول آزاد میکند.
هر کامپوننت در دیگ سه لایه دارد: خودِ نشانهگذاری، رفتار تعاملی و توکنهای بصری. این جدایی یعنی تغییر رنگ برند یا اندازهٔ فونت هیچوقت به معنی نوشتن دوبارهٔ منطق نیست.
راستبهچپبودن یک ویژگیِ اضافه نیست؛ از همان لایهٔ اول تصمیمگیری بخشی از معماری بوده. جهت نوشتار، جای دکمهها، انیمیشنهای ورود و حتی آیکونهای جهتدار همه با dir صفحه هماهنگ میشوند.
سایهٔ اسکرول یک نشانهٔ ظریف بصری است، نه یک اسکرولبار سفارشی. وقتی محتوا از کادر بیرون میزند، کاربر باید بدون نیاز به اسکرول کردن حدس بزند که ادامهای هست؛ یک محو تدریجی در لبه دقیقاً همین کار را میکند.
در بسیاری از رابطهای کاربری، اسکرولبار بهخاطر دلایل زیباییشناسی پنهان میشود. اما پنهانکردن اسکرولبار بدون جایگزین بصری، نشانهٔ سرریز محتوا را از بین میبرد؛ سایهٔ اسکرول دقیقاً همین خلأ را پر میکند.
تفاوت حالت خودکار و حالت ثابت در دیدپذیری سایه مهم است: در حالت خودکار سایه واقعاً موقعیت اسکرول را دنبال میکند، اما در حالت ثابت طراح میتواند برای یک قاب یا تصویر ثابت، سایه را عمداً روی یک لبه قفل کند.
اندازهٔ سایه و حاشیهٔ فعالسازی هر دو قابل تنظیماند تا این کامپوننت هم برای یک لیست باریک کناری و هم برای یک ناحیهٔ بزرگ محتوا به یک اندازه خوب کار کند.
در نهایت، هر قطعهای در این سیستم باید بدون وابستگی بیرونی کار کند؛ فقط Tailwind و ریاکت. این یعنی نصب یک کامپوننت هیچوقت باعث نمیشود بستهٔ نهاییِ پروژهٔ شما بزرگتر از حد لازم شود.
انجام بده
از ScrollShadow روی محتوایی استفاده کنید که واقعاً ممکن است طولانیتر از کادر شود؛ سایه یک نشانهٔ کاربردی است.
انجام نده
روی محتوای کوتاه که هیچوقت سرریز نمیکند نگذارید؛ سایه هیچوقت ظاهر نمیشود و فقط یک overflow-auto بیفایده اضافه کردهاید.