برای یک طراح شاغل، سایت پورتفولیو در یک جایگاه میانی دشوار قرار دارد. سایت باید ظاهر جذابی داشته باشد، فوراً بارگذاری شود و بدون اینکه از ساعات کاری قابل پرداخت (billable hours) کم کند، به‌روز بماند. چیدمان قدیمی من روی Webflow بود که نسبت به اکثر ابزارها، شکاف بین صفحه‌سازهای کشیدن و رها کردن (drag-and-drop) و خروجی‌های حرفه‌ای را بهتر پر می‌کرد. اما وقتی اعلان تمدید با صورت‌حساب سالانه ۳۰۰ پوندی رسید، مجبور شدم یک سوال سخت از خودم بپرسم: آیا من در واقع برای ارزش دریافت می‌کنم یا فقط برای راحتی؟

تصمیم گرفتم همه چیز را از صفر بازسازی کنم. مجموعه ابزار (stack) جدید من Astro و Sanity است. پس از مدتی کار با آن‌ها، در اینجا دقیقاً می‌گویم چه چیزی خوب کار کرد، چه چیزی نکرد و در مقایسه با ابزارهایی که قبلاً استفاده می‌کردم، در چه جایگاهی قرار می‌گیرند.

چرا Astro برای یک پورتفولیو؟

بیشتر فریم‌ورک‌های مدرن وب، ابتدا جاوااسکریپت را ارسال می‌کنند و بعد به فکر بقیه چیزها می‌افتند. Astro این فرض را زیر سوال می‌برد. این فریم‌ورک در زمان ساخت (build time)، کدهای HTML استاتیک ساده تولید می‌کند و فقط زمانی که یک کامپوننت خاص واقعاً به آن نیاز داشته باشد، جاوااسکریپت را به مرورگر می‌فرستد. آن‌ها این را معماری جزیره‌ای (islands architecture) می‌نامند، اما نتیجه عملی آن ساده‌تر است: صفحات پورتفولیوی من تقریباً هیچ حجمی ندارند.

مسیریابی (Routing) مبتنی بر فایل است، بنابراین ایجاد یک صفحه جدید به سادگیِ انداختن یک فایل در یک پوشه است. کامپوننت‌ها از سینتکسی استفاده می‌کنند که اگر با React، Vue یا Svelte کار کرده باشید، برایتان آشنا خواهد بود. من مجبور نیستم هر بار که می‌خواهم یک مطالعه موردی (case study) پروژه را اضافه کنم، به دنبال یک پارادایم جدید باشم.

با این حال، من از Astro برای ساخت یک اپلیکیشن وب پیچیده استفاده نمی‌کنم. اگر در حال پیاده‌سازی احراز هویت، مدیریت وضعیت سراسری (global state) یا مدیریت داده‌های بلادرنگ هستید، با این فریم‌ورک به مشکل خواهید خورد. اما برای سایت‌های مارکتینگ، وبلاگ‌ها و پورتفولیوها، Astro کاملاً بی‌دردسر است. صفحات سریع به نظر می‌رسند چون واقعاً سریع هستند. هیچ سربار هیدریشن (hydration overhead) برای رندر شدن یک تیتر یا یک پاراگراف وجود ندارد.

انتقال از WordPress به Sanity

قبل از این بازسازی، گزینه جایگزین من همیشه WordPress به همراه Advanced Custom Fields بود. ACF به WordPress قدرت‌های فوق‌العاده‌ای می‌دهد، اما شما همچنان در حال پیکربندی خانه‌ی شخص دیگری هستید. Sanity برعکس عمل می‌کند. شما یک شمای (schema) در کد می‌نویسید که دقیقاً تعریف می‌کند مدل محتوای شما چگونه باشد، و Sanity رابط کاربری ویرایش را بر اساس تصمیمات شما می‌سازد.

من از آن کنترل برای ساخت یک صفحه‌ساز ساده از بلوک‌های قابل استفاده مجدد استفاده کردم. یک بار بخش هیرو (hero section) را تعریف کردم. یک بار کاروسل نظرات (testimonial carousel) را تعریف کردم. یک بار شبکه‌ی کارت‌ها (card grid) را تعریف کردم. حالا می‌توانم با چیدن آن بلوک‌ها به هر ترتیبی، بدون نوشتن کد جدید یا دست زدن به قالب صفحه، صفحات جدید بسازم.

تفاوت در طرز فکر اهمیت دارد. با WordPress، اغلب احساس می‌کردم دارم با ابزاری کلنجار می‌روم که می‌خواهد یک وبلاگ باشد. با Sanity، احساس می‌کنم در حال ساخت نرم‌افزار هستم. محتوا به جای HTML استایل‌گذاری شده که با شورت‌کدها (shortcodes) مخلوط شده، به داده‌های ساختاریافته و تمیز تبدیل می‌شود. توضیحات پروژه‌های من به صورت اشیاء قابل انتقال (portable objects) ذخیره می‌شوند که اگر بخواهم، می‌توانم آن‌ها را به یک اپلیکیشن موبایل یا یک خبرنامه منتقل کنم.

یک گردش کار استقرار (deployment workflow) تمیز

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

گردش کار جدید کوتاه است:

  • تغییرات را به صورت محلی اعمال می‌کنم و بلافاصله آن‌ها را می‌بینم.
  • وقتی کد آماده بود، آن را در GitHub کامیت می‌کنم.
  • Vercel تغییرات را دریافت کرده و سایت را به طور خودکار مستقر (deploy) می‌کند.

دیگر خبری از کلاینت FTP نیست. خبری از دیتابیس استیجینگ برای همگام‌سازی نیست. مخزن کد (repository) منبع اصلی حقیقت (source of truth) است.

محتوا هم به همین ترتیب کار می‌کند. وقتی پستی را در Sanity منتشر یا به‌روزرسانی می‌کنم، یک وب‌هوک (webhook) به Vercel می‌گوید که سایت را دوباره بسازد. صفحات استاتیک با محتوای تازه بازسازی می‌شوند و CDN بدون اینکه من به سروری دست بزنم، به‌روز می‌شود. همه چیز بدون کپی کردن دستی، خروجی گرفتن یا دعا کردن برای اینکه مهاجرت پایگاه داده‌ی یک پلاگین واقعاً درست کار کرده باشد، همگام می‌ماند.

پیوند دادن طراحی و کد با استفاده از توکن‌ها

یکی از دستاوردهای آرام اما مهم در این بازسازی، راه‌اندازی یک سیستم توکن مناسب بود. من یک فایل JSON واحد دارم که مالک هر رنگ، مقیاس تایپوگرافی (type scale) و مقدار فاصله‌گذاری در سایت است. آن فایل رئیس است.

من از Token Studio استفاده می‌کنم تا همان مقادیر را مستقیماً به Figma بیاورم. وقتی فایل طراحی من surface-default را نشان می‌دهد، دقیقاً به همان عددی اشاره می‌کند که کد از آن استفاده می‌کند. یک اسکریپت کوچک، در زمان ساخت، JSON را به ویژگی‌های سفارشی CSS تبدیل می‌کند، بنابراین استایل‌شیت‌های من به جای کدهای رنگی هگز هاردکد شده، به متغیرهایی مانند --color-surface-default ارجاع می‌دهند.

در عمل، دلیل اهمیت این موضوع این است: اگر متوجه شوم رنگ قرمز برند من در صفحات موبایل کمی بیش از حد تند است، فقط یک مقدار را در فایل JSON تغییر می‌دهم. کتابخانه Figma به‌روز می‌شود. CSS به‌روز می‌شود. تمام موارد استفاده شده در سراسر سایت به‌روز می‌شوند. نیازی به grep کردن ندارم