如何管理數量巨大前端組件？

01-02

項目上用的是 react ，組件化後帶來的問題是，一個組件我做了通用的東西，別人有類似的需求時，往往不知道，就直接自己造輪子了。沒有辦法通知到人，組件化的復用沒有體現出。
一個原因是，在放通用組件的文件夾下用很多組件，新組件的更新與效果沒法讓人一下就能明白，總不能一個一個文件打開看組件的功能，而且別人更新了通用組件，其他人往往也不會去看，畢竟不知道和自己的頁面有沒有關係。

二是目前項目人還少，感覺某個組件可以抽象通用時可以口口相傳通知，但是如果組件越來越多，人越來越多，這事就沒法解決了，時間可能都用於重複的造輪子了。都去造輪子了組件化復用的意義何在，這個問題目前組件才有20+就有了，以後怎麼辦呢？
面對這種情況，各位大牛會如何處理？

搞一個頁面，可以列出組件的配置和 demo 效果。然後大家做組件的時候統一按照這個規範來做，打包更新這個頁面。

具體可以參考 ant-design，比如 Button 組件，會有一個 demo 文件放著各種代碼，然後打包的時候回自動讀取相關信息生成頁面。

ant-design/components/button/demo at master · ant-design/ant-design · GitHub

http://ant.design/components/button/

持續維護在線的組件的文檔

清晰的API的和示例代碼都擺在你面前了，你就嘗試用一下吧。

今天，不對，昨天早上的團隊周會中剛剛討論過關於團隊組件管理的問題。

首先，我所在團隊的組件，無論是基礎組件（類似於ant-design）還是業務組件都是有比較詳細的文檔描述，包括相應的介面描述（props）與demo。我們也養成了良好的習慣，拿到視覺稿或是交互demo後，第一反應是看看哪些部分是可以用現有組件復用的，也會詢問一下組內小夥伴，是否有人已經開發過類似組件，同時組件有新增或是較大改動，會在周報/周會中會有所體現。不知道有輪子的情況下造輪子，這是絕對可以避免的。

我們目前遇到的重複造組件輪子的問題，主要來源於組件在具體業務中表現不一致，交互不統一，無法復用之前已開發的組件，改造風險比較高，既要做到向下兼容又要滿足新需求，有哪些項目是依賴了這個組件，依賴這個組件的情況如何又是未知的，在這種情況下，會選擇新造一個輪子來滿足開發需求，也就造成了組件的重複。

當然，我們也想到了一些解決辦法，

1. 組件方面與UED團隊保持視覺和交互上的一致，盡量避免相同組件存在不同交互。

2. 添加組件的單元測試，盡量保證改動組件後不出現問題。

3. 比較特殊的業務組件在現有組件基礎上進行封裝（比如：現有組件外擴展一層Decorator），避免造一個完全新的組件或是將特殊性帶入現有組件中。

謝邀。

第一是寫文檔，第二是要求大家培養寫文檔的習慣。如果文檔做的足夠好，大家自然會先去找一下的。

你提的這個問題其實包括了幾個層面：

1.可能缺乏溝通。在敏捷開發的項目中，誰在做什麼東西（組件）整個項目的人都應該明白，每天的站會很重要的目的就是溝通。有這樣的困惑很可能項目成員嚴重缺乏溝通。類似的例會或者周會其實很重要。

2.可能缺少code review。團隊成員交叉code review是非常關鍵的一個環節，就是為了避免閉門造車，導致結果你的事情什麼都不知道，你寫的代碼誰都看不懂。

3.其他答主提到的Demo頁面。在我們團隊中，有一個內部專門的測試網站來測試框架中所有的功能，包括框架的通信、組件、UI、所有unit test等，團隊中任何人寫了任何新的組件或功能，都會同步更新這個test site，以便其他人查看或者應用。舉個例子，我前兩天寫了一個Listview組件，寫完之後需要更新unit test，更新API文檔，另外還會在test site上把它涉及的功能做出demo。

如下

你們團隊多少人啊，我們團隊的人，都不樂意自己寫組件，做之前先看看別的頁面有沒有，如果有的話去問做這個頁面的人在哪就行了。

你的問題感覺是你們團隊溝通有點問題啊。

不知道題主的組件是否可以公開，如果可以，使用github寫md，記住要配圖

有時候使用者看圖就能判斷這個組建是不是適合自己的項目，如何適合再看看文檔坑不坑！有時一個特別簡單的組件琢磨文檔的功夫，還不如自己這一個，所以文檔要夠簡單，如果有條件可以寫幾個demo實例！

組件的確坑真的通用的就那些一年也總結不出幾個但業務組件寫了一大堆

這個估計要配合了

大家一起定規則

寫文檔，因為我們公司正在做的項目就有一個還在完善的文檔，包括前後端組件啊，各種API啊。建議不要一上來就寫文檔，等技術成熟了，或者有沉澱了再開始寫，反正也得重構。

html2canvas能將dom轉為圖片，或者說可以將react組件效果圖截下來