[設計師篇-第1期]答疑：前端常說的前端框架，是指各類組件庫嗎 ？

先說答案：不是，但組件庫和前端框架有關係。請往下看

咱們先來個通俗的理解

1. 前端寫代碼，幹活，寫業務，有點相似種地的感受(碼農 哈哈哈哈哈，你爲什笑的這麼開心😓)

2. 種地須要工具對吧。而 Javascript 就是生鐵疙瘩，你拿鐵疙瘩去種地，效率很低。即便給這個鐵疙瘩包了很漂亮的錫紙（CSS），效率仍是很低。

3. 人羣中有一些聰明絕頂的傢伙（😂），想了些辦法，把這些鐵疙瘩，進行了煉化，把他們作成了 熟鐵（Vue、React 等開發框架）

4. 因而又有人用這些熟鐵，作成了各類零件（組件）

   1. 車燈（button）
   2. 座椅（表格）
   3. 發動機（輪播圖）
   4. 輪子（日期選擇器）

5. 把這些零件拼接在一塊兒，就成了拖拉機、汽車、收割機 ，極大提升了生產效率。這裏的拖拉機、汽車，就是你們的在工做中，在 sketch 中用各類組件作的 A後臺，B管理系統

6. 而你在使用sketch的時候，你的同事可能會問你:

   Hi，你的按鈕、下拉菜單作的不錯，能分享給我嗎？`

   因而你就把它存成一個組件分享給你的同事了，後來，你同事有點不想整了，直接和你說：

   你還能把按鈕、輪播圖、表格、下拉菜單、日期選擇器、導航條 都分享給我啊？

   你和他說

   阿西吧，奶茶拿來！

常見的設計規範/組件庫的 按鈕

1. material design
2. bootstrap
3. element
4. ant design
5. sales force

這是 按鈕的一些規範，能夠發現大部分是相同的。 這時候，就能夠發現了：和sketch相似，不管是 PC 端的 UI 設計仍是移動端的 UI 設計，頁面都是由每一個模塊拼接組成（功能點組成）。 而這些模塊再進行拆分，發現均可以由一些基礎組件拼接而成，基礎組件列表不外乎以下這些，這也是design system 構建的基礎。

• Button
• Icon
• Dropdown
• Menu
• Select
• Steps
• Form
• DatePicker
• DateRangePicker
• MonthPicker
• Checkbox
• Radio
• Switch
• Input
• Input-Number
• TextArea
• Rate
• Loading

這也是最近可能比較火的設計理念吧：原子設計。

從前端的角度來講，原子設計貌似是一件理所固然的事情，畢竟全部的大東西都是靠這小東西拼接而成的，因此對工程師來講，作小東西是划算的，這樣比較靈活 + 複用性比較強，可以應對更多的場景和需求。 說白了：這樣可以提升工做效率，方便擴展，也可以知足設計師的大部分需求

設計和前端合做的一些基礎知識

不知道你是否知道，前端通常的開發語言爲：JavaScript + CSS + HTML

其中：

1. JavaScript 爲主，負責交互邏輯 + 業務邏輯
2. CSS負責樣式，用來負責裝飾頁面是否美觀
3. HTML 最次之，用來負責總體骨架（能夠忽略）

前端工程師70%的時間是和JavaScript打交道的(我的經驗之談)

1. 其中以 JavaScript 爲主，CSS 爲輔， HTML 最次之(我的見解)

2. 你們在開發的過程當中，一些業界大牛不光技術很厲害，思想也很厲害，好比Twitter 的兩位，一位前端工程師 + 一位設計師，發現Twitter的不少地方都用到了樣式相同的

   1. 按鈕（靜態的，偏向於靜態，多數只是展現使用，）
   2. 卡片、導航條等等，這些都是相對偏靜態的

3. 除了這些靜態的，還有一些不光樣式相同，還有一些交互也很類似的，好比：

   1. 彈窗（modal）

   1. 獨立於頁面之上，中間是一個矩形的區域，用於操做，四周是偏向於透明的黑色（樣式統一）
   2. 點擊中間的區域的取消、或者右上角的關閉、或者按鍵盤的 Esc 都會關閉這個彈框（交互統一）

   2. 表格
   3. 下拉菜單
   4. 輪播圖

4. 以上這些，在長期的項目演進迭代過程當中，Twitter的兩位發現，這些東東均可以進行抽象，把不一樣平臺的彈框、表格、下拉菜單、輪播圖的樣式和交互進行儘可能統一，通過迭代和演進。有一天，有一個叫Bootstrap 的東東問世了

解答問題：前端常說的前端框架，是指各類組件庫嗎

1. 前端說的組件庫：是指在各大Design System的指導下，經過某種前端框架進行開發落地的東東。
2. 有點在馬克思主義的引導下，進行社會主義建設的感受。
3. Design System === 前端UI 的設計規範
4. 這裏的前端框架，如今多數指的是 Vue、React、Angular 這三個主流開發框架了
5. 這算是開發層面的東西了，和設計師同窗也是有關係的（關係不大，但瞭解這些開發語言 和 設計師之間的關係，可能更好）

這裏的 在 Design System 指導下，進行開發落地，通常是須要指定一種前端框架的

意味着：

1. 其對應的開發者衆多，衆人拾柴火焰高，好比國內使用 Vue、React 的比較多。
2. 也就是說，在某個設計規範(好比Material Design) + 前端框架(好比React) 對應的組件庫會更完善
3. 若是有了bug，修復的時間和效率也更高

實際工做

這裏的 在 Design System 指導下，進行開發落地，通常是須要指定一種前端框架的。 好比國內使用 Vue、React 的比較多，也就表明着其對應的開發者衆多，衆人拾柴火焰高，也就是說，《這些開發語言 + 某個設計規範》的組件庫會更完善，有了bug，fix 的效率也更高

回到這裏，在決定作設計稿以前以前，能夠找大家的工程師問下，他們用的組件庫是什麼？這個組件庫背後的設計團隊，有沒有對外輸出 Sketch 文件

據我所知，國內的 餓了麼UED、螞蟻金服UED 會產出：設計規範 + Sketch + 在設計規範指導下的，代碼組件庫

特別是在大家項目已經採用一些組件庫或者框架的前提下，最好提早溝通。 不然可能會出現：開發會抗拒你設計的新的東西

1. 你們畢竟不想從頭開始作。接觸一個新的設計規範，極可能意味着其不成熟，可能設計規範說的很明白的，好比對錶格的每一行的高度都有說明，但苦逼的是，沒有人寫代碼去落地，致使空有理論
2. 這也是開發最抵觸的地方：沒有人去落地，最終多是大家開發去落地，在國內這種大環境下，老大無論你採用什麼設計規範，只要最終項目可以定期上線便可，因此也請設計師同窗多多理解開發同窗吧
3. 畢竟雙方的編輯成本不一樣：設計師同窗在sketch上一個小時作的，可能開發們，要作兩三天，並且還要考慮不少實際的交互問題，和後端工程師的數據交互，異常狀況處理等等問題，還有就是代碼的擴展性等等問題 😂

完結撒花 🎉🎉🎉🎉🎉