思考組件這件事，對于産品經理的産品思維訓練是有幫助的。本篇文章圍繞組件展開了一系列的思考，包括如何拆解組件以及組件的未來，感興趣的小夥伴們快來一起看看吧，希望對你有所幫助。

這篇文章是我對過去半年工作的一些思考，閱讀過程中需要一些背景知識的支撐，例如你需要理解「應用」、「低代碼」、「組件」等概念。

當然，我會盡可能用簡單的語言去表達，但還是要首先說明，這篇文章有一定的閱讀門檻。

一、組件背後的産品思維

在介紹什麼是組件之前，我想首先說明一下組件背後的産品思維，因為這是理解組件價值的關鍵。

所謂思維，是從感性到理性的提煉結果。感性是我們面對世界看到的現象，理性是我們從繁雜的現象中抽象出來的概念和規律。

例如，在外賣平台沒有出現之前，我們感受到的現象是「無法堂食」和「想要立刻吃到東西」之間的矛盾，當這個矛盾成為一種普遍的社會現象時，能解決矛盾的外賣服務便出現了。

起初是門店給顧客留電話，顧客打電話訂餐品，門店老闆自己送。後來供應商多了，顧客需求多了，就出現了更高效地解決這個矛盾的平台。外賣産品從一種感性的矛盾中脫胎出來，成為了一種新的概念和規律。這種規律就是，我打開外賣 app，就可以獲得我周圍的可配送的美食。

外賣産品不是從天而降的，而是感性層面的現象不斷累積，最終變成了理性的概念。

組件也是一樣。在互聯網早期，可能并沒有組件的概念（産品領域沒有，可能在技術領域是存在的），後來出現了一種現象是什麼呢？那就是不同的業務應用，往往采用的都是同一種或者相似的産品框架來完成。

例如很多公司都有自己的後台管理工具，他們很多時候可以抽象為對數據的增改删查；又例如很多公司内建自己的項目管理工具，内核也是一種狀态機。

哪怕是現在的電商領域，無論是以天貓、京東為代表的貨架式電商，還是以抖音為代表的興趣電商，他們 app 首頁的産品框架也都是以記錄列表（什麼是記錄，此處就不展開）為核心。

這樣的現象随着互聯網的高速發展而愈發明顯，繁雜的業務應用背後是通用的産品架構。但由于每個業務獨立核算、獨立運營，導緻一套産品框架往往要在不同的業務中開發多次，也就是很多人讨厭的重複造輪子現象。

誠然，在方案設計環節，産品經理會通過盡可能複用已有的成熟方案降低開發成本，但隻要有一點點改動，從開發流程上來說就需要走一遍完成的流程。

這就導緻業務方經常會問：“我就改這麼一點點東西，為啥還要排期到那麼晚”。我隻能告訴你，生産關系就是這樣，在原有的系統裡無論你改的是什麼，可能都需要把所有幹系功能都測一遍。

從上述現象中我們可以提煉出哪些矛盾呢？

1. 很多業務應用的内核是相似的，但需要多次開發
2. 凡是動代碼的，可能就是慢的，代碼開發、測試和發布的速度趕不上業務變化的速度

在這種矛盾日益劇增時，組件出現了。

組件背後的産品思維，就是盡可能将邏輯相似的代碼塊抽象為通用的可配置的功能單元，從而高效解決複用和個性化的矛盾。

它背後體現出組件的兩種特性：高通用、高可配。

并帶來兩種鮮明的業務價值：複用價值、兼容價值。

二、為什麼要讨論組件

在介紹組件的具體特性之前，我想說一說「為什麼要讨論組件」。

首先，思考組件這件事，對于産品經理的産品思維訓練是有幫助的。我們知道，大多數産品經理以擁有好的抽象能力而自居。然而他們的抽象能力，大多是建立在業務需求上的抽象能力，非産品角度的抽象能力。

業務需求的抽象能力，追求的是用一個産品化的方案解決多樣化的業務需求。例如業務方希望通過打折的方式在特定時間點對産品做促銷，這是一種從經濟學和心理學角度出發的業務訴求。當然要對哪些商品做促銷，促銷力度如何，促銷規則怎麼樣，都依賴于不同的業務方有不同的玩法。

有些希望做滿減促銷，有些希望做限時打折，有些希望搭贈一些臨期商品，從各自業務的角度看都是合理的，産品經理要做的事情就是用産品來滿足業務訴求。

但組件要求産品經理具備的抽象能力，是對産品的進一步抽象，并對最終抽象而成的模塊做産品化。

例如我們經常在大促期間見到的各種活動頁面，雖然看起來風格不同，且每個頁面也都是跟業務溝通之後，确定下來的共識，但從産品角度看其核心是相似的。

很多電商促銷頁面主要包括商品、券、轉盤、動圖、按鈕、鍊接跳轉等要素，但抽象出來其實都是一系列的組件。

而這種從多樣化的頁面到組件的抽象過程，就是對産品的進一步抽象，這是一種産品思維的訓練。

其次，思考組件這件事，也有助于對産品經理這個行業未來的思考奠定基礎。當我從事低代碼行業的第一天我就在思考，如果我們在做的這件事做成了，那很可能意味着大批的程序員和産品經理的失業或轉型。

本質原因在于，社會的發展會使得資源最終會流轉到最能用好它們的人手中，這是客觀的經濟學規律，不以人的物質為轉移。

還記得我們在第一部分提出的兩點矛盾麼：重複開發和慢叠代。須知這種矛盾的背後是人力和機器資源的巨大投入。這種投入還存在，是因為當下我們沒有更好的解決辦法。

但如果我們往5年、10年後看去，如果産品經理這個崗位帶來的業務價值已經低于他們存在本身帶來的資源消耗，那資源就會轉移到其他崗位上。

會不會出現這種現象呢，我不确定，但我認為應該警惕和思考。

像輕流這樣已經商業化的低代碼産品，正在幫助中小型企業搭建一些簡單的表單應用，那原來準備投入到自研或外包中的資源，就節約下來了。

我一直在想，有沒有可能5 年後的互聯網産品生産端，負責标準化模塊（評論、訂單等）的産品經理會消失，取而代之的是低代碼産品經理和業務産品經理，前者負責不斷完善底層工具和生态，後者負責面向不同業務方落地産品實施。

僅作一猜測，擺在這裡。

三、拆解組件

這節，我将以騰訊微搭産品為例子，帶大家一起拆解組件。要拆解組件，首先要對組件做定義、分類和内部結構分析。

在我看來，組件是可被複用的完整的産品功能模塊。

可被複用是組件最顯著的特征。因為它是對産品的進一步抽象，說明它可以出現在不同的産品中，進而在搭建應用時，它可以出現在不同的頁面中。

完整是指組件代表了一個完整的使用場景。例如下圖中的文本組件，它代表的場景是在頁面中展示一段文本。且頁面中任何使用到文本的地方，都可以拖入這個組件，它也是通用的。

從這個定義出發，線條就不是一個組件，因為單單一個線條不能代表任何完整的使用場景，盡管它是可複用的。

最後，組件是一個功能模塊，我所理解的功能，是它具有處理信息的能力。再抽象一些，它有自己的輸入、作用和輸出。

要進一步拆解組件，首先要對組件做分類。

原子組件：不能被進一步拆解的組件，代表了某個功能場景下的最小粒度。例如上述的文本組件就是一個原子組件，因為我不可能再進一步拆解出一個字符組件。它也代表了當我需要在頁面展示文本信息時，在這個場景下我需要的最小功能模塊。

複合組件：由原子組件組合而成的組件，代表了複雜場景下的功能模塊。

例如下圖的表格組件。這種組件往往更貼合某種實際的使用場景，比如管理一張表格，或者填寫一個問卷，他們的目标是在對應的複雜業務場景下，可以有更便捷的方式搭建出對應的功能模塊來。

原子組件由于粒度小，所以在搭建時的自由度更高，理論上如果一個平台的原子組件足夠豐富，那麼可以搭建出非常複雜的應用出來。但它的劣勢在于，搭建門檻非常高。

以上圖的表格組件為例，拆開來看它包括的原子組件是：按鈕、複選框、文本、搜索框等組件，但如果我隻給你提供這四個原子組件，讓你搭建出上圖這樣的效果，估計你會崩潰的。

複合組件由于更貼近實際使用的場景，所以搭建門檻更低。

例如對上述表格來說，我隻需要給組件關聯對應的數據模型，然後做一些字段和樣式配置，基本上在 5 分鐘内就可以搭建出一個能對數據表做增改删查的管理表格。

但另一方面，它的靈活性也相對被降低了，因為很多布局和樣式都是預設好的，沒有可以進一步編輯的功能，所以兼容性較差。

從上面的分析可以看出，不同的組件盡管都可以代表完整的功能場景，但設計上還是有不同的考慮，這種考慮往往是自由度和使用體驗之間的平衡。這也是組件本身固有的矛盾。

組件的功能拆解，需要從輸入、作用和輸出三個角度來說。我們以經常用到的美食篩選場景為例。

上圖是大衆點評美食頻道頁裡的篩選功能，我可以通過選擇美食的種類，進一步縮小我看到的頁面信息的範圍。那在低代碼産品中，這種功能模塊怎麼搭建出來呢。

首先我們需要使用一個下拉選擇組件，注意，這個組件是一個抽象的組件，它既不代表美食的篩選，也不代表距離的篩選。它表達的意思是：這個組件提供了在下拉框中完成單選的功能。

要給這個組件賦以業務含義，就必須向它注入數據。例如，給這個組件關聯美食品類的數據表，這樣下拉選擇後的每一個選項，代表了一種美食品類。

有了輸入之後，就需要對輸入做處理，那下拉選擇組件是怎麼處理的呢？它提供了一種特性，叫做用戶在 app 上點擊選中的數據，就代表了這個組件最新的值。

你選擇了火鍋，業務上代表了你在美食品類中選擇了火鍋，産品上代表了你在下拉選擇組件中，通過前端頁面的點擊，給組件賦值，這個值就是火鍋這個選項數據。

最後是輸出，輸出是該組件作為一個獨立的功能模塊，能夠給頁面、或者頁面内的其他模塊傳遞的信息。在上述例子中，從業務上看，當我們選擇了火鍋之後，商戶列表就完成了一次刷新，并且刷新之後隻展示跟火鍋相關的商戶。

但産品原理上并不簡單。首先，在搭建的時候，需要在頁面内建立下拉選擇組件和商戶列表組件之間的關系，是的，看起來内容很多的商品列表，其實也是一個組件。建立的是什麼關系呢？是一種篩選邏輯關系。

在商戶列表組件的篩選條件中，我們需要加上，這個列表中每個商戶的美食品類需要等于下拉組件中選擇的美食品類。

在這個邏輯關系中，下拉組件的值作為輸出，就被商戶列表組件使用了，這種關系，用偏技術的話說叫做「消費」，就是我用了你給我的東西。

以上隻是下拉選擇組件在實際 app 中的一個很簡單的應用，事實上組件的輸入、處理和輸出遠比這個場景要複雜很多。但無論有多麼複雜，從這三個角度去分析組件的功能我理解基本都是可以的。

如何設計一款組件呢？這是很多低代碼産品經理面臨的課題，也是我在過去半年内從事的主要工作。一個完整的組件設計方案，需要重點考慮三個問題：

1. 屬性：這個組件的功能是什麼
2. 樣式：它長什麼樣子
3. 行為：它跟其他模塊之間如何交互

屬性如我們剛剛所述，需要考慮組件的輸入、處理和輸出。還是以微搭中最簡單的文本組件為例。

可以看到微搭的文本組件提供了兩個最基本的屬性配置項：内容和格式。它解決的就是一個問題：這個組件需要以什麼方式展示什麼内容。

樣式決定了這個組件長什麼樣子，例如它在展示區域内的間距、位置，它是否有背景色等等。樣式的配置能力跟很多設計軟件提供的能力很像，在此就不贅述。

最後是行為，它告訴系統的就是一個問題：當發生了什麼事情時，會執行什麼動作。發生了什麼事情，我們一般叫做觸發事件。

它往往是一個可被捕獲的前端事件，例如點擊、失焦、hover 等。而執行的動作，就是産生了這些事件時，接下來需要做什麼。

例如下圖是一個表單複合組件，當我們點擊提交按鈕時，它捕捉到的是 click 這個事件，接着會執行的動作可能就是，将提交的數據更新到數據庫。

行為往往是進行組件和組件之間以及系統和系統之間通信的橋梁，如果有機會我們可以再好好聊聊組件的行為。

四、組件的未來

我先抛出我的看法：組件未來一定要建立起生态，且組件生态一定是市場化的。

組件要解決的問題，類似于 SaaS 産品在現階段想要解決的矛盾：以标準化的解決方案滿足多樣化的業務訴求。

從發展的眼光看，業務訴求豐富度的增長，一定是快過産品解決方案能滿足的場景的增長，所以一定要部分場景是标準化的解決方案覆蓋不了的。這一點從國内外的 SaaS 廠商紛紛布局自己的 PaaS 能力可以看出。

同樣的，雖然組件滿足的是快速搭建業務應用的場景，但目前絕大多數的低代碼産品，其組件的設計還是中心化的：平台負責設計，開發者使用。當開發者的訴求無法被滿足時，他們提出了新的需求，平台開發新的組件。

問題是：這種中心化開發的模式下，組件可以被稱為組件的前提是，它必須要有一定的通用性，不受場景的局限。這個前提本身就限制了組件模式的天花闆。

事實上回歸組件的定義：可複用的完整功能模塊。在這個定義下，我們并不強調組件一定要由平台生産和定義，平台能不能提供生産組件的能力，由衆多開發者自己生産，自行使用呢。我理解是可以的，且在國外産品中已經構建起這樣的市場了。

在一款低代碼産品中，我們已經能看到，當系統提供的組件不能滿足你的搭建訴求時，你可以在組件市場中安裝更多的組件，而這些組件可能就是由第三方服務商開發完成的。

通過平台，充分連接起組件生産者、組件使用者、應用使用者等不同的利益相關方，這樣的生态會使得有越來越多的為垂直行業而服務的複合組件出現。

五、結語

這篇文章大緻呈現了我對組件相關的思考，由于篇幅的限制，以及出于可讀性的考慮，與組件相關的頁面、流程、模型、變量等概念就沒有提及，但你需要知道對于一款完整應用來說，以上這些都是很重要的系統。

其實，從 0 到 1 開發一款應用并沒有那麼容易，當我從事低代碼之後，我才體會到一款應用産生的背後會牽涉到如此複雜的系統，這是我以前工作的盲區。

在這之前我作為産品經理，更多關注的是用戶和客戶的價值，較少關注産品的實現邏輯。這也是絕大多數産品經理的通病，否則也不會出現「這個需求很簡單，怎麼實現我不管」這樣的段子。

但如果你真正走到産品背後，去從搭建的角度思考一款應用的從 0 到 1 ，你會對這份工作産生更多的敬畏之心的。

這是我半年來最大的收獲。

專欄作家

大力哥呀，大力哥，人人都是産品經理專欄作家。一個90後産品經理，已經寫了6年的公衆号，通過輸出獲得了許多意料外的成長。

本文原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部