Figma Make تازه به یک ابزار واقعی تبدیل طراحی به کد تبدیل شد
Figma Make حالا React متصل به design token های واقعی و نگاشتهای Code Connect شما را خروجی میدهد، نه markup دورریختنی. اینجا میبینید چه چیزی در ۱۸ ژوئن تغییر کرد، کجا هنوز نیاز به انسان دارد، و یک workflow که همین هفته میتوانید اجرا کنید.
خلاصهاش این است: Figma Make حالا کدی تحویلتان میدهد که یک مهندس front-end فوراً آن را پاک نمیکند. این دقیقاً دلیلی است که طراحان دارند دربارهاش حرف میزنند، و این قضیه بزرگتر از یک بهبود سرعت ساده است.
در ۱۸ ژوئن، Figma یک بهروزرسانی production-grade برای Make منتشر کرد. تیتر اصلی "سریعتر شد" نیست. تیتر اصلی دقت است. Make حالا کامپوننتهایی خروجی میدهد که به design token های واقعی و نگاشتهای Code Connect شما متصل هستند، نه markup سست و یکبار مصرفی که قبلاً تولید میکرد.
این تفاوت خط فاصل بین یک شعبدهبازی و یک ابزار واقعی است. کد دورریختنی دور انداخته میشود. کدی که به سیستم شما ارجاع میدهد، merge میشود.
diff هایی که همه دارند پست میکنند
این بهروزرسانی مهار را شکست چون مردم دارند مدرک نشان میدهند. thread اعلامیه @figma در عرض چند روز به تقریباً ۹٫۲ هزار repost رسید، و reply ها پر شد از diff های مقایسهای Figma-to-React از تیمهایی که آن را روی سیستمهای خودشان اجرا کرده بودند.
این نشانهای است که ارزش توجه دارد. بلندترین سیگنال متن بازاریابی Figma نیست، بلکه مهندسانی هستند که diff های قبل و بعد پست میکنند و از نتیجه متنفر نیستند. وقتی شکاکان ساکت میشوند، یعنی چیزی تغییر کرده.
طراحان یک دهه است که وعدههای "design to code" میشنوند. این وعده همیشه به محض برخورد با یک codebase واقعی میمرد، چون خروجی سیستمی را که codebase روی آن ساخته شده بود نادیده میگرفت. این بار diff ها از این برخورد جان سالم به در میبرند.
چه چیزی واقعاً تغییر کرد (token ها و Code Connect، نه hex خام و markup)
آنلاین در figma.com/make ببینید
Make قدیم یک frame میخواند و توصیف میکرد که چه میبیند. یک دکمه آبی میدید و #2D7FF9 مینوشت. padding میدید و یک مقدار pixel مینوشت. نتیجه درست به نظر میرسید و به هیچچیزی متصل نبود.
Make جدید همان frame را میخواند و آن را در برابر سیستم شما resolve میکند. دکمه آبی به یک ارجاع token کامپایل میشود، نه یک مقدار hex منجمد. کامپوننت به نگاشت واقعی Code Connect شما کامپایل میشود، پس به کامپوننت واقعی در codebase شما اشاره میکند به جای اینکه یکی از نو بسازد.
تمام این تغییر در یک جمله است. خروجی دیگر pixel توصیف نمیکند و شروع کرده به ارجاع به source of truth شما.
اهمیت عملیاش این است: ارجاعات token یعنی کد شما تغییرات theme را به رایگان به ارث میبرد. token را تغییر دهید، هر خروجی آن را دنبال میکند. نگاشتهای Code Connect یعنی خروجی همان Button ای را که تیم شما نگهداری میکند مجدداً استفاده میکند، به جای اینکه یک تقریباًتکراری بسازد که به محض اینکه کسی دستش بزند drift میکند.
خروجی Make قدیم در برابر بهروزرسانی ۱۸ ژوئن
اینجا مقایسه است، چون مقایسه خودش استدلال است.
| بُعد | Make/خروجی سال گذشته | بهروزرسانی ۱۸ ژوئن |
|---|---|---|
| مقادیر رنگ | hex خام داخل کامپوننت | ارجاعات token که تغییرات theme را به ارث میبرند |
| فاصلهگذاری | مقادیر pixel یکبار مصرف | فاصلهگذاری نگاشتشده به token |
| کامپوننتها | markup تازه برای هر frame | نگاشت Code Connect به کامپوننت موجود شما |
| رابطه با سیستم شما | هیچ، خروجی مستقل بود | متصل به token ها و کتابخانه کامپوننت شما |
| اولین حرکت مهندس | پاک کردن و بازنویسی | خواندن، نگهداشتن ساختار، پالایش |
| برچسب صادقانه | دمو | ابزار |
ستون راست تنها چیزی است که جایی در یک pull request به دست میآورد. ستون چپ دلیل این است که تا همین الان کسی به "design to code" اعتماد نداشت.
کجا هنوز به شما نیاز دارد
Make بدنه را میسازد، نه مغز. بزرگنمایی این موضوع به هیچکس کمک نمیکند، پس اینجا محدودیت صادقانه چیزی است که بهروزرسانی ۱۸ ژوئن برای شما انجام میدهد.
Layout، token ها و scaffold های استاتیک کامپوننت تمیز بیرون میآیند. هر چیزی که نیاز به تصمیم دارد، هنوز نیاز به شما دارد. خروجی نمیداند که یک حالت loading باید چه احساسی داشته باشد، در خطا چه اتفاقی بیفتد، یا اینکه حالت empty شما باید تشویق کند یا عذرخواهی.
| Make این کار را خوب انجام میدهد | اینها هنوز نیاز به شما دارند |
|---|---|
| Layout و ساختار | منطق state (loading، error، empty، success) |
| استایلدهی نگاشتشده به token | رفتار تعامل و انیمیشن |
| scaffold های استاتیک کامپوننت | دسترسیپذیری فراتر از موارد آشکار (ترتیب focus، هدف ARIA، live region ها) |
| فاصلهگذاری و سلسلهمراتب وفادار | داده واقعی، موارد لبهای، رشتههای طولانی، فیلدهای خالی |
| ساختار اولیه React | تصمیمات سیستمی: چه زمان باید یک کامپوننت را مجدداً استفاده کرد در مقابل ایجاد کامپوننت جدید |
دسترسیپذیری سزاوار یک خط جداگانه است. Make میتواند ویژگیهای alt و تگهای تقریباًsemantic بزند، اما نمیتواند ترتیب focus را تعیین کند، یک live region را اعلام کند، یا بفهمد که modal شما باید focus را محدود کند و برگرداند. اینها قضاوتهایی هستند درباره اینکه یک انسان چطور در رابط کاربری شما حرکت میکند، و قضاوت در خروجی نیست.
داده واقعی کشنده بیسروصدای دیگر است. یک frame یک ردیف کامل نشان میدهد. Production کاربری را نشان میدهد که اسمش ۴۰ کاراکتر است، قیمتی که null است، لیستی که روز اول خالی است.
Make مسیر happy path را scaffold میکند. واقعیت را شما مدیریت میکنید.
یک workflow منطقی با Figma Make در حلقه برای این هفته
نیازی نیست فرآیندتان را از نو بسازید. باید Make را در نقطه درست وارد کنید و یک انسان را روی درزها نگه دارید. اینجا نسخهای است که میتوانید همین هفته روی یک کامپوننت واقعی اجرا کنید.
- اول token ها و Code Connect را واقعاً نگاشت کنید. این پیشنیاز بیجلا است. Make فقط به اندازه سیستمی که به آن ارجاع میدهد خوب است، پس اگر token هایتان نیمهنامگذاری شدهاند و پوشش Code Connect ضعیف است، قبل از اینکه خروجی را مقصر بدانید آن را درست کنید.
- Make را روی یک کامپوننت خوبساخته اجرا کنید، نه یک صفحه کامل. چیزی با ساختار واضح و داستان token تمیز انتخاب کنید. دارید دقت را آزمایش میکنید، نه معجزه میخواهید.
- diff را مثل یک code reviewer بخوانید، نه یک طرفدار. تأیید کنید که به ارجاعات token resolve شده و به کامپوننت واقعی شما نگاشت شده. اگر یک مقدار hex یا یک کامپوننت تکراری ساخت، آن frame system-clean نبود. منبع را درست کنید.
- scaffold را به مهندس بدهید با state، داده و کار دسترسیپذیری که به وضوح به عنوان مسئولیت او علامتگذاری شده. خروجی ساختار شروع است. تصمیمات خود کار هستند.
- آنچه یاد گرفتید را به سیستم بازگردانید. هر جایی که Make حدس زد، جایی بود که token ها یا نگاشتهای Code Connect شما مبهم بودند. محکمکردن آنها خروجی بعدی را بهتر میکند. سیستم تجمیع میشود.
الگو human-in-the-loop است، نه human-out-of-the-job. Make مرحله ترجمه خستهکننده را حذف میکند. تفکر را حذف نمیکند.
این چه کاری با deliverable شما میکند
آنلاین در atlassian.design ببینید
این آهسته تغییر میدهد که "تمام" برای یک طراح چه معنایی دارد. سالهاست که deliverable یک frame pixel-perfect بود و امید مؤدبانهای که مهندسی آن را تطبیق دهد. تطبیق همیشه با افت بود.
حالا frame به قرارداد نزدیکتر است. اگر طراحی شما به token های واقعی ارجاع دهد و کامپوننتهایتان از طریق Code Connect نگاشت شوند، خروجی هدف شما را با drift کمتر به کد میبرد. handoff دیگر ترجمه نیست و به انتقال تبدیل میشود.
این ارزش کار سیستمی را بالا میبرد و ارزش screenshot های زیبا را کاهش میدهد. طراحانی که سال آینده برنده میشوند کسانی هستند که فایلهایشان به قدری ساختاریافته است که Make خروجی تمیز تولید کند. یک فایل آشفته کد آشفته را سریعتر تولید میکند، در حالی که یک سیستم منضبط کد قابل ارثبری تولید میکند.
پس ارتقای واقعی هوش مصنوعی نیست. فشاری است برای اینکه بالاخره token هایتان را درست نامگذاری کنید و کامپوننتهایتان را نگاشت کنید. Make فقط این نظم را به جای اینکه بالاخره نتیجه بدهد، فوری نتیجهبخش کرد.
FAQ
بهروزرسانی ۱۸ ژوئن پاسخهای واقعی به سؤالاتی را که طراحان بیشتر از همه درباره Figma Make میپرسند تغییر میدهد.
آیا Figma Make حالا React آماده production مینویسد؟
نزدیکتر، اما نه به تنهایی. بهروزرسانی React متصل به token های واقعی و نگاشتهای Code Connect شما تولید میکند که محکم و ارزشمند است. هنوز state، دسترسیپذیری و داده واقعی را به شما واگذار میکند. آن را به عنوان یک پیشنویس اولیه قوی در نظر بگیرید، نه یک ویژگی تمامشده.
Code Connect چیست و چرا برای خروجی اهمیت دارد؟
Code Connect یک کامپوننت در فایل Figma شما را به کامپوننت واقعی در codebase شما نگاشت میکند. این تفاوت بین Make ای است که یک دکمه تازه میسازد و Make ای که Button ای را که تیم شما نگهداری میکند مجدداً استفاده میکند، پس خروجی به source of truth شما اشاره میکند به جای اینکه یک تکراری بسازد.
آیا Make از design token های من استفاده میکند یا مقادیر خودش را میسازد؟
از token های شما استفاده میکند که هسته تغییر ۱۸ ژوئن است. خروجیهای قدیم hex خام را مستقیم در markup میپختند. بهروزرسانی مقادیر را به ارجاعات token resolve میکند، پس کد شما تغییرات theme را به ارث میبرد به جای اینکه یک snapshot منجمد کند. یک hex خام در خروجی یعنی آن frame هیچوقت به یک token نگاشت نشده بود.
Figma Make هنوز کجا کوتاهی میکند؟
پنج جا هنوز نیاز به انسان دارند، همانهایی که جدول بالا فهرست کرده:
- منطق state: loading، error، empty، success
- رفتار تعامل و انیمیشن
- دسترسیپذیری فراتر از موارد آشکار
- داده واقعی، موارد لبهای و رشتههای طولانی
- چه زمان باید یک کامپوننت را مجدداً استفاده کرد در مقابل ایجاد کامپوننت جدید
Make لایهبندی، استایلدهی نگاشتشده به token و scaffold های استاتیک را مدیریت میکند. قضاوتها جایی هستند که کار واقعی در آنجاست.
آیا باید workflow ام را همین هفته تغییر دهم؟
بله، به یک روش کوچک. Make را روی یک کامپوننت تمیز اجرا کنید، diff را مثل یک مهندس بررسی کنید، و از آنچه آشکار میکند برای محکمکردن token ها و پوشش Code Connect استفاده کنید. کل تیم را یکشبه به handoff هوش مصنوعی تبدیل نکنید.
نتیجهگیری
Figma Make در ۱۸ ژوئن خط را از دمو به ابزار پشت سر گذاشت. اثبات تقریباً ۹٫۲ هزار repost در thread اعلامیه @figma نیست، بلکه diff های production است که مهندسان زیرش پست کردند و پاک نکردند.
مکانیزم ساده است. Make دیگر pixel ها را با hex خام و markup یکبار مصرف توصیف نمیکند، و شروع کرده به ارجاع به token های واقعی و نگاشتهای Code Connect شما. این تفاوت بین کدی است که دور میاندازید و کدی است که merge میکنید.
آن را به تیمتان بیش از حد نفروشید. Make اسکلت را میسازد. State، تعامل، دسترسیپذیری و موارد لبهای هنوز کار شما هستند، و همیشه خواهند بود. هوشمندانهترین حرکت این هفته این است که از بهروزرسانی به عنوان دلیلی استفاده کنید تا بالاخره token ها و Code Connect را درست کنید، چون یک سیستم تمیز است که این ویژگی را از یک اسباببازی به ابزاری تبدیل میکند که واقعاً میتوانید با آن عرضه کنید.
Need a design system your code actually inherits? We build them.
Get Started
