Framer Motion را برای بازخورد بگذار، نه برای اینکه صفحه زنده به نظر برسد

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

در React مدت‌ها یا CSS محدود داشتی یا کتابخانه‌ای که با چرخه حیات کامپوننت خوب کنار نمی‌آمد. Framer Motion، بسته‌ای که خیلی کدبیس‌ها هنوز به اسم `framer-motion` می‌شناسند و خانواده Motion ادامه داده، API اعلانی می‌دهد که به کامپوننت می‌چسبد. اسم بسته و مسیر import را با نسخه‌ای که در ریپوی خودت pin شده یکی کن. سند بازاریابی را به‌جای `package.json` منبع حقیقت نگیر.

چه چیزی را واقعاً از آن می‌خواهی

چیزهایی که در کار روز می‌ارزند محدودند. حالت نام‌دار با variants تا ورود، هاور، و فشار یک واژگان مشترک داشته باشند. `AnimatePresence` تا کامپوننت شرطی قبل از حذف از DOM خروج را تمام کند. ژست ساده مثل `whileHover` و `whileTap` برای بازخورد فوری. و در جایی که چیدمان واقعاً عوض می‌شود، prop مربوط به layout تا جابه‌جایی اندازه و جایگاه پرش نکند.

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

`motion.button` هنوز دکمه است. نوع، فوکوس، و برچسب دسترس‌پذیر را برندار چون حالا متحرک است. اگر حرکت جایگزین وضعیت متنی شود، کاربر صفحه‌خوان و کسی که حرکت را خاموش کرده هر دو گم می‌شوند.

خروج را طراحی کن، نه فقط ورود

سخت‌ترین جای انیمیشن React حذف است. React کامپوننت شرطی را فوراً از درخت برمی‌دارد. بدون `AnimatePresence` خروج را نمی‌بینی. مودال، توست، و پنلی که ظاهر و غیب می‌شود باید حضور را با کلید پایدار بپیچد و حالت `exit` داشته باشد.

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

گذار مسیر هم همین مسئله است در مقیاس صفحه. اگر هر ناوبری یک پرده تمام‌صفحه باشد، حرکت خودش کندی حس می‌شود. گذار کوتاه روی محتوای عوض‌شده معمولاً بهتر از انیمیشن کل پوسته است. ناوبری فوری قرارداد محصول است. انیمیشن نباید این قرارداد را با تأخیر مصنوعی عوض کند.

ویژگی‌هایی که روان می‌مانند

ویژگی‌هایی مثل `x`، `y`، `scale`، `rotate`، و `opacity` معمولاً روی compositor می‌مانند و برای حرکت نرم انتخاب پیش‌فرض‌اند. انیمیت کردن `width`، `height`، `top`، یا `left` چیدمان را دوباره حساب می‌کند و زیر بار، روی فهرست بلند، یا روی دستگاه ضعیف می‌لرزد.

اگر واقعاً به تغییر اندازه نیاز داری، layout را آگاهانه روشن کن و محدوده را کوچک نگه دار. کل صفحه را layout نکن چون یک کارت باز می‌شود. پدر مشترک کوچک‌ترین را متحرک کن.

هماهنگی چند عنصر با variants بهتر از ده `useEffect` با تأخیر دستی است. تأخیر پله‌ای کوتاه برای فهرست قابل قبول است. فهرست پنجاه‌تایی که دانه‌دانه می‌رقصد کاربر را معطل می‌کند و کار را کند نشان می‌دهد. برای داده زیاد، حرکت را به ورود ظرف محدود کن نه به هر ردیف.

`useAnimation` یا کنترل برنامه‌ای را وقتی بیاور که منطق محصول باید حرکت را قطع یا ادامه دهد، مثلاً وقتی درخواست شکست می‌خورد و باید از حالت میانی به خطا بروی. برای هاور لازم نیست.

حرکت کم، و احترام به reduced motion

اشتباه رایج زیاد متحرک کردن است. هر عنصر لازم نیست محو یا بلغزد. حرکت ظریف که وضعیت را توضیح می‌دهد معمولاً اثر بیشتری از حرکت نمایشی دارد. اگر حذف انیمیشن معنی را عوض نمی‌کند، شاید از اول لازم نبوده.

بعضی کاربرها حرکت کم می‌خواهند، از جمله به خاطر اختلال دهلیزی. `prefers-reduced-motion` را احترام بگذار. یا گذار را به محو خیلی کوتاه کاهش بده یا همان تغییر حالت را بدون جابه‌جایی مکانی انجام بده. یک تنظیم سراسری در سیستم طراحی بهتر از این است که هر کامپوننت یادش بماند.

ژست کشیدن مرز و نقطه رها شدن می‌خواهد. اگر فقط `drag` را روشن کنی و محدودیت نگذاری، عنصر از ظرف خارج می‌شود و هیچ کار محصولی انجام نمی‌دهد. کشیدن را وقتی بگذار که رها کردن معنی دارد: مرتب‌سازی، بستن، یا انتقال. و مسیر غیرلمسی معادل داشته باش. صفحه‌کلید نباید تنها راه را از دست بدهد.

قبل از افزودن حرکت بپرس

این حرکت کدام وضعیت را توضیح می‌دهد؟ اگر جواب «زنده‌تر به نظر برسد» است، نگذار. اگر جواب «کاربر بفهمد پنل بسته شد» یا «بفهمد دکمه فشرده شد» است، کوتاه و قابل‌قطع بگذار.

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

وابستگی را مثل بقیه UI مالک شو. اگر فقط یک محو ورود لازم داری، CSS کافی است و باندل اضافه نمی‌خواهد. Motion را وقتی بیاور که هماهنگی حالت، خروج، یا ژست واقعاً در محصول تکرار می‌شود.

یک واژگان حرکت برای محصول کافی است

در سیستم طراحی سه حالت نام‌دار بس است: ظاهر شدن کوتاه، تأیید فشار، و جابه‌جایی چیدمان وقتی سطح واقعاً عوض می‌شود. بقیه صفحه‌ها از همین سه تا استفاده کنند. اگر هر ویژگی duration و easing خودش را اختراع کند، رابط ناهماهنگ می‌شود و کسی نمی‌تواند بگوید کدام حرکت «مال ما» است.

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

پرسش‌های کوتاه

**همه دکمه‌ها whileHover داشته باشند؟** نه. جایی که هاور اطلاعات جدید یا تأیید فشار می‌دهد بگذار. تغییر رنگ کوچک CSS اغلب کافی است.

**layout را پیش‌فرض روشن کنم؟** نه. فقط روی تکه‌ای که اندازه یا ترتیبش در تعامل کاربر عوض می‌شود.

**کتابخانه را به آخرین اصلی ارتقا بدهم چون سند جدید گفته؟** نه تا یادداشت نسخه و کد خودت را بخوانی. pin را عمدی عوض کن، نه با کپی نمونه کد وبلاگ.