Web設計與開發工具之間的衝突一直是業界長期存在的問題。網頁設計的最終成果通常是一個模型，過去開發人員製作網站，而設計師則製作網站的“繪畫作品”，這種脫節造成了巨大的摩擦。究竟哪個才是真相的來源？
如果真的存在單一事實來源呢？如果設計工具與生產網站使用完全相同的代碼呢？這場曠日持久的討論的最新篇章是UXPin。
讓我們先了解一些事實，以便更好地理解這一切。
UXPin是一款功能強大的設計工具，擁有您期望的所有功能，尤其專注於基於數字屏幕的設計和高級原型設計。
它基於代碼這一事實尤其重要。使用所有視覺組件（這些組件實際上植根於代碼）來設計網站，使設計更貼近最終產品。您的設計不僅看起來像網站或應用程序，而且功能也像網站或應用程序。例如，輸入字段不是帶有輪廓的靜態框，而是讓您體驗到用文本填充它的真實感受。
基於代碼的設計已經為每個元素提供了所有規範——例如這個卡片組件；精確的顏色（使用正確的格式），以及精確的像素尺寸等等。在某些情況下，甚至可以提取UI組件的精確代碼供開發人員使用。
Ania Kubów在一個關於UXPin的視頻中很好地闡述了這一點。
十多年前，Jason Santa Maria 認真思考了下一代設計工具的樣子。我們能否直接使用瀏覽器？
我認為瀏覽器還不夠。網頁設計師在解決創意和信息傳遞問題之前就跳入瀏覽器，就像建築師先把木頭敲在一起，然後再測量一樣。工具限制了想像力，而設計之初的想像力或靈感為後續的一切奠定了基礎。
Jason Santa Maria ，“一個真正的網頁設計應用程序”
也許不是直接使用瀏覽器，但基於代碼的工具可以讓UI像您的網站或應用程序一樣工作，這可能是兩全其美的選擇：
網頁是動態的、活生生的空間，訪問者的最小交互都可能改變整個網站的範圍。 […] 因為我們處理的不是靜態媒體，我們需要能夠設計交互和網頁不斷變化的景象[…]應用程序需要查看元素，而不是顏色或文本塊。 Photoshop、Illustrator 和Fireworks 在這方面具有一些低級功能，但對更動態和非破壞性處理的需求是顯而易見的。
這就是單一事實來源的魔力所在。如果設計工具可以輸出React（或任何其他框架）組件，這是一回事。這是一個巧妙的技巧。但這很可能是一次單程旅行。現實世界項目中的組件充滿了其他並非完全屬於設計領域的內容。也許一個組件使用一個鉤子來返回當前用戶的權限，如果他們沒有訪問權限，則禁用一個按鈕。禁用的按鈕具有一定的設計元素，但大部分代碼並非如此。
如果設計工具無法尊重該組件中的其他代碼，並且基本上只是忽略它，那麼它是不切實際的。從本質上講，如果設計工具將組件導出為代碼，但不允許設計師首先導入這些UI組件，那麼它就沒有多大用處。
這就是UXPin Merge的用武之地。
現在，公平地說，這需要一些工作來設置。可能只需要幾個小時，也可能需要幾週時間才能完成一個完整的系統設計。目前，UXPin僅與React一起工作，並使用webpack配置來集成它。
一旦您開始運行，您在UXPin中使用的組件實際上就是您用於構建生產網站的組件。
看到一個設計工具消化預構建的組件並允許它們在全新的畫布上用於原型設計，這確實令人印象深刻。
UXPin幫助您在項目中實現此功能，包括：
組件往往具有屬性，屬性控制設計和內部內容等方面。 UXPin為您提供了屬性的UI，這意味著您可以完全控制組件。
<code><linechart ...="" barcolor="green" data="{[" height="200" showxaxis="false" showyaxis="true" width="500"></linechart></code>了解這一點後，您可以為組件提供一個屬性接口，從而提供大量的設計控制。例如，集成主題切換。
另一個在JavaScript組件領域中非常流行的用於測試和構建組件的工具是Storybook。它不像UXPin那樣是一個設計工具——它更像是一個組件的“動物園”。您可能已經設置好了它，或者您也可能發現使用Storybook很有價值。
好消息是？ UXPin Merge與Storybook完美配合。它使集成變得非常快速和容易。此外，它還支持任何框架，例如Angular、Svelte、Vue等——除了React。
看看速度有多快：
UXPin首席執行官Marcin Treder有一個強烈的願景：
如果設計師可以使用工程師使用的完全相同的組件，並且所有組件都存儲在一個共享的設計系統中（具有準確的文檔和測試）會怎麼樣？設計師和工程師之間許多令人沮喪且代價高昂的誤解將不復存在。
以及一個計劃：
這就是他們在這裡完成的工作。
體驗UXPin Merge
以上是開發人員和設計師與uxpin一起工作的詳細內容。更多資訊請關注PHP中文網其他相關文章！
