ساخت پنل سفارش معمولاً با انتخاب فریم‌ورک شروع می‌شود: کدام ابزار سریع‌تر است، کدام کتابخانه جدول بهتری دارد و تیم با چه چیزی راحت‌تر کار می‌کند؟ این پرسش‌ها لازم‌اند، اما اگر هنوز معلوم نیست کاربر از کجا وارد می‌شود و چه سفارشی را باید پیدا کند، پاسخشان زودتر از موعد به دست آمده است.
در این مجموعه، یک پنل مدیریت سفارش را قدم‌به‌قدم می‌سازیم. کنار پنل، چند صفحه عمومی برای معرفی محصول داریم؛ داخل پنل هم فهرست سفارش، جزئیات، فیلتر و عملیات مجاز قرار می‌گیرد. در بخش اول، بدون وابستگی به فریم‌ورک مشخص، مسیرها و حالت‌های محصول را تعریف می‌کنیم. آشنایی مقدماتی با وب کافی است و خروجی مقاله، نقشه‌ای است که بعداً انتخاب شیوه رندر و ساختار پروژه را بر پایه آن انجام می‌دهیم.
صفحه، مسیر و کار کاربر یک چیز نیستند
«صفحه سفارش‌ها» فقط نام یک بخش است. کار واقعی ممکن است پیداکردن سفارش‌های پرداخت‌شده امروز، بررسی آدرس یک خریدار یا پیگیری سفارش معطل‌مانده باشد. اگر فقط نام صفحه را بنویسیم، احتمال دارد جدولی بسازیم که همه داده‌ها را نشان می‌دهد ولی کار اصلی را سخت می‌کند.
برای هر مسیر، سه چیز ثبت کنید: چه کسی وارد آن می‌شود، با چه هدفی و از کدام نقطه. مسئول ارسال ممکن است از یک فیلتر ذخیره‌شده وارد شود؛ مدیر فروش شاید از گزارش روزانه به سفارش برسد. هر دو به همان موجودیت نگاه می‌کنند، اما اطلاعات و عملیات مهمشان متفاوت است.
در مثال ما، ابتدا یک نقش عملیاتی داریم که سفارش‌های مجاز خودش را می‌بیند و می‌تواند وضعیت آماده‌سازی را تغییر دهد. مجوزهای دقیق را در بخش‌های بعد طراحی می‌کنیم. فعلاً همین فرض کمک می‌کند نیازهای کاربر را از نمایش بی‌هدف همه فیلدهای دیتابیس جدا کنیم.
مسیر عمومی را از محیط عملیاتی جدا کنیم
صفحه معرفی محصول برای کسی است که شاید هنوز حساب ندارد. باید بدون ورود، قابل خواندن و قابل اشتراک باشد. در مقابل، فهرست سفارش حاوی اطلاعات کاری است و به احراز هویت و بررسی مجوز نیاز دارد. این تفاوت فقط در نمایش منو نیست؛ روی دریافت داده، کش، متادیتا و رفتار خطا اثر می‌گذارد.
| مسیر نمونه | مخاطب | نیاز اصلی |
|---|---|---|
/ | بازدیدکننده عمومی | شناخت محصول و یافتن مسیر ورود |
/login | کاربر دارای حساب | ورود و بازگشت به مقصد اولیه |
/orders | کاربر مجاز | یافتن سفارش و حفظ فیلترها |
/orders/:id | کاربر مجاز همان سفارش | دیدن جزئیات و عملیات قابل انجام |
این مسیرها قرارداد پیشنهادی مثال‌اند و قرار نیست به‌تنهایی ساختار فایل‌های پروژه را تحمیل کنند. ارزششان در روشن‌کردن مرزهاست. انتخاب اینکه کدام صفحه روی سرور آماده شود و کدام بخش تعاملی باشد، در قسمت بعد و با توجه به همین نیازها انجام می‌شود.
یک سفر اصلی را تا انتها دنبال کنیم
سناریوی اصلی را این‌طور در نظر بگیریم: مسئول ارسال باید یک سفارش پرداخت‌شده را پیدا کند، آدرس و اقلامش را ببیند و آن را برای بسته‌بندی علامت بزند. مسیر از بازکردن پنل شروع می‌شود و با دریافت نتیجه قطعی عملیات تمام می‌شود؛ نمایش پیام «در حال ذخیره» پایان کار نیست.
- ورود به پنل یا بازگشت از صفحه ورود به مقصد قبلی.
- دیدن فهرست با فیلتر وضعیت پرداخت و بازه زمانی موردنظر.
- بازکردن جزئیات سفارش بدون ازدست‌رفتن زمینه فهرست.
- بررسی اطلاعات لازم و انتخاب عملیات مجاز.
- دریافت نتیجه و مشاهده وضعیت تازه سفارش.
- برگشت به همان صفحه و فیلتر قبلی برای ادامه کار.
قدم آخر معمولاً در طرح اولیه فراموش می‌شود. وقتی کاربر هر روز سفارش‌های زیادی را بررسی می‌کند، بازگشت به ابتدای فهرست پس از هر عملیات آزاردهنده است. نگه‌داشتن فیلتر و صفحه در URL می‌تواند راه‌حل مناسبی باشد؛ جزئیات این تصمیم را در بخش مربوط به وضعیت URL دنبال خواهیم کرد.
حالت‌های صفحه را کنار مسیر بنویسیم
یک طرح که فقط داده سالم و آماده دارد، بخش مهمی از تجربه واقعی را نشان نمی‌دهد. فهرست سفارش می‌تواند برای اولین بار بارگذاری شود، با داده قبلی در حال تازه‌شدن باشد، واقعاً خالی باشد یا به‌دلیل فیلتر نتیجه نداشته باشد. در هر حالت، پیام و اقدام بعدی فرق می‌کند.
اگر هنوز هیچ سفارشی ثبت نشده، متن راهنما می‌تواند مسیر شروع کار را نشان دهد. اگر فیلتر اشتباه است، دکمه پاک‌کردن فیلتر مفیدتر است. اگر ارتباط قطع شده، نباید پیام «سفارشی ندارید» نمایش دهیم؛ نبود پاسخ با نبود داده یکی نیست.
- بارگذاری اولیه: ساختار صفحه روشن بماند و کاربر بداند منتظر چه چیزی است.
- خطای دریافت: امکان تلاش دوباره و توضیح کوتاه درباره وضعیت فراهم شود.
- دسترسی ناکافی: پیام و مسیر بازگشت مناسب نشان داده شود، بدون افشای داده سفارش.
- سفارش حذف‌شده یا ناموجود: صفحه جزئیات به یک خطای خام تبدیل نشود.
- ثبت در حال انجام: عملیات تکراری کنترل شود و نتیجه نهایی واضح باشد.
لینک مستقیم را از روز اول جدی بگیریم
تصور کنید همکار، آدرس جزئیات یک سفارش را برای کاربر می‌فرستد. اگر نشست تمام شده باشد، کاربر وارد صفحه ورود می‌شود. بعد از ورود باید بتواند به مقصد مجاز برگردد؛ نباید مجبور شود دوباره سفارش را جست‌وجو کند. البته مقصد بازگشت باید به مسیرهای معتبر داخل برنامه محدود شود تا ورودی دلخواه به مسیر ناامن تبدیل نشود.
همین سناریو هنگام بازکردن صفحه در زبانه جدید هم اهمیت دارد. محصولی که فقط با کلیک‌های متوالی از صفحه اصلی کار می‌کند، از ظرفیت طبیعی وب استفاده نکرده است. برای مسیرهای مهم بررسی کنید تازه‌سازی صفحه، بازگشت مرورگر و اشتراک لینک چه رفتاری دارند.
مرز فرانت و سرور را روشن نگه داریم
مرورگر می‌تواند به کاربر نشان دهد چه عملیاتی در دسترس است، اما اجازه نهایی باید در سرور بررسی شود. مخفی‌شدن دکمه تغییر وضعیت به معنی ممنوع‌شدن درخواست نیست. در نقشه مسیر، کنار هر عملیات حساس بنویسید کدام قاعده باید در API دوباره کنترل شود.
برای نمونه، سفارش لغوشده نباید صرفاً چون صفحه قدیمی هنوز دکمه را نشان می‌دهد وارد بسته‌بندی شود. سرور وضعیت فعلی و مجوز کاربر را می‌سنجد و فرانت باید خطای قابل فهم آن را نمایش دهد. این موضوع را پیش از انتخاب کتابخانه فرم یا مدیریت وضعیت می‌توان و باید مشخص کرد.
دسترس‌پذیری یک مسیر مستقل نیست
قرار نیست بعداً صفحه‌ای به نام «نسخه دسترس‌پذیر» اضافه کنیم. همان مسیر اصلی باید با کیبورد، متن خوانا و فوکوس مشخص قابل انجام باشد. در فهرست سفارش، بازکردن ردیف فقط با کلیک روی یک ناحیه نامعلوم کافی نیست؛ لینک یا دکمه معنایی لازم است. نتیجه عملیات هم باید بدون اتکا به تغییر رنگ قابل تشخیص باشد.
در این مرحله جزئیات فنی صفحه‌خوان را پیاده نمی‌کنیم، اما معیار می‌نویسیم: کاربر بتواند از فیلتر به فهرست، از فهرست به جزئیات و از جزئیات به عملیات برسد، بدون اینکه نیاز به ماوس داشته باشد. این معیار هنگام ارزیابی اجزای آماده هم به کار می‌آید.
حالا چه چیزی را از فریم‌ورک می‌خواهیم؟
بعد از این بررسی، نیازها مشخص‌ترند: مسیرهای عمومی با متادیتای مناسب، بخش محافظت‌شده برای سفارش‌ها، پشتیبانی روشن از دریافت داده و خطا، لینک مستقیم، فرم‌های قابل اتکا و امکان آزمودن سفر اصلی. حالا می‌توان گزینه‌های فنی را با پرسش واقعی مقایسه کرد.
مثلاً از خود بپرسیم در ابزار انتخابی، نشست چگونه به درخواست سرور می‌رسد؟ اطلاعات خصوصی چطور از کش عمومی دور می‌ماند؟ صفحه جزئیات در تازه‌سازی مستقیم چه می‌کند؟ قرارداد دریافت داده و مدیریت خطا برای تیم چقدر روشن است؟ پاسخ این پرسش‌ها از تعداد ستاره‌های مخزن برای این پروژه کاربردی‌تر است.
هیچ‌یک از این‌ها به معنی ضرورت یک معماری پیچیده نیست. پنل کوچک ممکن است با ساختاری ساده به‌خوبی کار کند. مهم این است که ابزار، مسیر محصول را قابل فهم نگه دارد و برای حل مشکلی که فعلاً نداریم، لایه‌های اضافی وارد نکنیم.
یک بازبینی کوتاه پیش از شروع پیاده‌سازی
نقشه مسیر را با کسی مرور کنید که قرار است از پنل استفاده کند. به‌جای نمایش مجموعه‌ای از صفحه‌ها، یک سفارش فرضی بدهید و بخواهید کار روزمره‌اش را تعریف کند. جاهایی که می‌پرسد «بعدش چه کنم؟» یا «چطور برگردم؟» به احتمال زیاد هنوز در طراحی مبهم‌اند.
خروجی این جلسه باید فهرست مسیرها، سفر اصلی، حالت‌های خطا و قواعد دسترسی باشد. لازم نیست همه جزئیات ظاهری نهایی شوند. حتی طرح کاغذی هم می‌تواند نشان دهد آیا ترتیب کار درست است؛ چیزی که باید همین حالا حل شود ابهام رفتار است، نه انتخاب سایه کارت‌ها.
برای تمرین، سناریوی سفارش پرداخت‌نشده را به نقشه اضافه کنید. مشخص کنید کاربر از کجا آن را می‌بیند، چه عملیاتی مجاز است و هنگام تغییر وضعیت توسط همکار چه پیامی دریافت می‌کند. در بخش بعد، از همین مسیرها برای انتخاب CSR، SSR و SSG در بخش‌های مختلف محصول استفاده می‌کنیم.
مطالعه بیشتر
- مرور ارتباط کلاینت و سرور در MDN؛ مبنای تفکیک مسئولیت درخواست و پاسخ.
- مقدمه دسترس‌پذیری وب در MDN؛ برای درنظرگرفتن نیازهای متفاوت کاربران از شروع طراحی.