如何利用组件，高效解决复用和共性化的矛盾？

webwuyan

思考组件这件事，关于产品经理的产品思惟训练是有帮忙的。本篇文章环抱组件展开了一系列的思考，包罗如何拆解组件以及组件的将来，感兴致的小火伴们快来一同看看吧，但愿对你有所帮忙。

这篇文章是我对过来半年任务的一些思考，浏览过程当中需求一些配景常识的撑持，例如你需求了解「运用」、「低代码」、「组件」等概念。
固然，我会尽量用简略的言语去表白，但仍是要首先阐明，这篇文章有一定的浏览门坎。
一、组件面前的产品思惟
在引见甚么是组件以前，我想首先阐明一下组件面前的产品思惟，由于这是了解组件价值的症结。
所谓思惟，是从理性到感性的提炼后果。理性是咱们面对世界看到的景象，感性是咱们从复杂的景象中笼统出来的概念和法则。
例如，在外卖平台没有泛起以前，咱们感触到的景象是「无奈堂食」和「想要立刻吃到货色」之间的矛盾，当这个矛盾成为一种广泛的社会景象时，能解决矛盾的外卖办事便泛起了。
后来是门店给顾客留电话，顾客打电话订餐品，门店老板本人送。起初供给商多了，顾客需要多了，就泛起了更高效地解决这个矛盾的平台。外卖产品从一种理性的矛盾中脱胎出来，成了一种新的概念和法则。这类法则就是，我关上外卖 app，就能获取我四周的可配送的美食。
外卖产品不是突如其来的，而是理性层面的景象不停累积，终究变为了感性的概念。
组件也是同样。在互联网初期，可能并无组件的概念（产品畛域没有，可能在技术畛域是存在的），起初泛起了一种景象是甚么呢？那就是不同的业务运用，往往采取的都是同一种或者类似的产品框架来实现。
例如得多公司都有本人的后盾办理工具，他们得多时分能够笼统为对数据的增改删查；又例如得多公司内建本人的名目办理工具，内核也是一种形态机。
哪怕是当初的电商畛域，无论是以天猫、京东为代表的货架势电商，仍是以抖音为代表的兴致电商，他们 app 首页的产品框架也都是以记载列表（甚么是记载，此处就不展开）为中心。
这样的景象跟着互联网的高速开展而愈创造显，复杂的业务运用面前是通用的产品架构。但因为每个业务独立核算、独立经营，致使一套产品框架往往要在不同的业务中开发屡次，也就是得多人厌恶的反复造轮子景象。
诚然，在计划设计环节，产品经理会经过尽量复用已有的成熟计划升高开发本钱，但只有有一点点改变，从开发流程下去说就需求走一遍实现的流程。
这就致使业务方常常会问：“我就改这么一点点货色，为啥还要排期到那末晚”。我只能告知你，出产瓜葛就是这样，在原本的零碎里无论你改的是甚么，可能都需求把一切干系功用都测一遍。
从上述景象中咱们能够提炼出哪些矛盾呢？
得多业务运用的内核是类似的，但需求屡次开发但凡动代码的，可能就是慢的，代码开发、测试和公布的速度赶不上业务变动的速度在这类矛盾日趋剧增时，组件泛起了。
组件面前的产品思惟，就是尽量将逻辑类似的代码块笼统为通用的可配置的功用单元，从而高效解决复用和共性化的矛盾。
它面前体现出组件的两种特性：高通用、高可配。
并带来两种光鲜的业务价值：复用价值、兼容价值。
二、为何要探讨组件
在引见组件的详细特性以前，我想说一说「为何要探讨组件」。
首先，思考组件这件事，关于产品经理的产品思惟训练是有帮忙的。咱们知道，大少数产品经理以具有好的笼统才能而自居。但是他们的笼统才能，大可能是建设在业务需要上的笼统才能，非产品角度的笼统才能。
业务需要的笼统才能，寻求的是用一个产品化的计划解决多样化的业务需要。例如业务方但愿经过打折的形式在特按时间点对产品做促销，这是一种从经济学和心思学角度登程的业务诉求。固然要对哪些商品做促销，促销力度如何，促销规定怎样，都依赖于不同的业务方有不同的弄法。
有些但愿做满减促销，有些但愿做限时打折，有些但愿搭赠一些临期商品，从各自业务的角度看都是公道的，产品经理要做的事件就是用产品来知足业务诉求。
但组件要求产品经理具备的笼统才能，是对产品的进一步笼统，并对终究笼统而成的模块做产品化。
例如咱们常常在大促期间见到的各种流动页面，虽然看起来格调不同，且每个页面也都是跟业务沟通之后，肯定上去的共鸣，但从产品角度看其中心是类似的。
得多电商促销页面次要包罗商品、券、转盘、动图、按钮、链接跳转等因素，但笼统出来其实都是一系列的组件。
而这类从多样化的页面到组件的笼统进程，就是对产品的进一步笼统，这是一种产品思惟的训练。
其次，思考组件这件事，也有助于对产品经理这个行业将来的思考奠定根底。当我从事低代码行业的第一天我就在思考，假如咱们在做的这件事做成为了，那极可能象征着大批的顺序员和产品经理的失业或转型。
实质缘故在于，社会的开展会使得资源终究会流转到最能用好它们的人手中，这是主观的经济学法则，不以人的物资为转移。
还记得咱们在第一部份提出的两点矛盾么：反复开发和慢迭代。须知这类矛盾的面前是人力和机器资源的微小投入。这类投入还存在，是由于当下咱们没有更好的解决方法。
但若咱们往5年、10年后看去，假如产品经理这个岗位带来的业务价值曾经低于他们存在自身带来的资源损耗，那资源就会转移到其余岗位上。
会不会泛起这类景象呢，我不肯定，但我以为应该警觉和思考。
像轻流这样曾经商业化的低代码产品，正在帮忙中小型企业搭建一些简略的表单运用，那原来筹备投入到自研或外包中的资源，就勤俭上去了。
我始终在想，有无可能5 年后的互联网产品出产端，担任规范化模块（评论、定单等）的产品经理会隐没，取而代之的是低代码产品经理和业务产品经理，前者担任不停完美底层工具和生态，后者担任面向不同业务方落地产品实行。
仅作一猜测，摆在这里。
三、拆解组件
这节，我将以腾讯微搭产品为例子，带大家一同拆解组件。要拆解组件，首先要对组件做定义、分类和外部构造剖析。
在我眼里，组件是可被复用的残缺的产品功用模块。
可被复用是组件最明显的特点。由于它是对产品的进一步笼统，阐明它能够泛起在不同的产品中，进而在搭建运用时，它能够泛起在不同的页面中。
残缺是指组件代表了一个残缺的使用场景。例如下图中的文本组件，它代表的场景是在页面中展现一段文本。且页面中任何使用到文本之处，均可以拖入这个组件，它也是通用的。


从这个定义登程，线条就不是一个组件，由于单繁多个线条不克不及代表任何残缺的使用场景，只管它是可复用的。
最初，组件是一个功用模块，我所了解的功用，是它拥有处置信息的才能。再笼统一些，它有本人的输出、作用和输入。
要进一步拆解组件，首先要对组件做分类。
原子组件：不克不及被进一步拆解的组件，代表了某个功用场景下的最小粒度。例如上述的文本组件就是一个原子组件，由于我不成能再进一步拆解出一个字符组件。它也代表了当我需求在页面展现文本信息时，在这个场景下我需求的最小功用模块。
复合组件：由原子组件组合而成的组件，代表了繁杂场景下的功用模块。
例如下图的表格组件。这类组件往往更贴合某种实际的使用场景，好比办理一张表格，或者填写一个问卷，他们的指标是在对应的繁杂业务场景下，能够有更便捷的形式搭建出对应的功用模块来。


原子组件因为粒度小，所以在搭建时的自在度更高，实践上假如一个平台的原子组件足够丰硕，那末能够搭建出十分繁杂的运用出来。但它的优势在于，搭建门坎十分高。
以上图的表格组件为例，拆开来看它包罗的原子组件是：按钮、复选框、文本、搜寻框等组件，但若我只给你提供这四个原子组件，让你搭建出上图这样的成果，估量你会解体的。
复合组件因为更贴近实际使用的场景，所以搭建门坎更低。
例如对上述表格来讲，我只需求给组件关联对应的数据模型，而后做一些字段和款式配置，根本上在 5 分钟内就能搭建出一个能对数据表做增改删查的办理表格。
但另外一方面，它的灵敏性也相对于被升高了，由于得多规划和款式都是预设好的，没有能够进一步编纂的功用，所以兼容性较差。
从下面的剖析能够看出，不同的组件只管均可以代表残缺的功用场景，但设计上仍是有不同的斟酌，这类斟酌往往是自在度和使用体验之间的均衡。这也是组件自身固有的矛盾。
组件的功用拆解，需求从输出、作用和输入三个角度来讲。咱们以常常用到的美食筛选场景为例。


上图是公众点评美食频道页里的筛选功用，我能够经过选择美食的品种，进一步放大我看到的页面信息的规模。那在低代码产品中，这类功用模块怎么搭建出来呢。
首先咱们需求使用一个下拉选择组件，留意，这个组件是一个笼统的组件，它既不代表美食的筛选，也不代表间隔的筛选。它表白的意思是：这个组件提供了在下拉框中实现单选的功用。
要给这个组件赋以业务含意，就必需向它注入数据。例如，给这个组件关联美食物类的数据表，这样下拉选择后的每一个个选项，代表了一种美食物类。
有了输出之后，就需求对输出做处置，那下拉选择组件是怎么处置的呢？它提供了一种特性，叫做用户在 app 上点击选中的数据，就代表了这个组件最新的值。
你选择了火锅，业务上代表了你在美食物类中选择了火锅，产品上代表了你在下拉选择组件中，经过前端页面的点击，给组件赋值，这个值就是火锅这个选项数据。
最初是输入，输入是该组件作为一个独立的功用模块，可以给页面、或者页面内的其余模块传递的信息。在上述例子中，从业务上看，当咱们选择了火锅之后，商户列表就实现了一次刷新，而且刷新之后只展现跟火锅相干的商户。
但产品原理上其实不简略。首先，在搭建的时分，需求在页面内建设下拉选择组件和商户列表组件之间的瓜葛，是的，看起来内容得多的商品列表，其实也是一个组件。建设的是甚么瓜葛呢？是一种筛选逻辑瓜葛。
在商户列表组件的筛选前提中，咱们需求加之，这个列表中每个商户的美食物类需求等于下拉组件中选择的美食物类。
在这个逻辑瓜葛中，下拉组件的值作为输入，就被商户列表组件使用了，这类瓜葛，用偏技术的话说叫做「消费」，就是我用了你给我的货色。
以上只是下拉选择组件在实际 app 中的一个很简略的运用，事实上组件的输出、处置和输入远比这个场景要繁杂得多。但无论有如许繁杂，从这三个角度去剖析组件的功用我了解根本都是能够的。
如何设计一款组件呢？这是得多低代码产品经理面临的课题，也是我在过来半年内从事的次要任务。一个残缺的组件设计计划，需求重点斟酌三个问题：
属性：这个组件的功用是甚么款式：它长甚么模样行动：它跟其余模块之间如何交互属性如咱们刚刚所述，需求斟酌组件的输出、处置和输入。仍是以微搭中最简略的文本组件为例。
能够看到微搭的文本组件提供了两个最根本的属性配置项：内容和格局。它解决的就是一个问题：这个组件需求以甚么形式展现甚么内容。


款式抉择了这个组件长甚么模样，例如它在展现区域内的间距、地位，它是不是有配景色等等。款式的配置才能跟得多设计软件提供的才能很像，在此就不赘述。


最初是行动，它告知零碎的就是一个问题：当产生了甚么事件时，会履行甚么举措。产生了甚么事件，咱们个别叫做触发事情。
它往往是一个可被捕捉的前端事情，例如点击、失焦、hover 等。而履行的举措，就是发生了这些事情时，接上去需求做甚么。
例如下图是一个表单复合组件，当咱们点击提交按钮时，它捕获到的是 click 这个事情，接着会履行的举措可能就是，将提交的数据更新到数据库。


行动往往是进行组件和组件之间以及零碎和零碎之间通讯的桥梁，假如无机会咱们能够再好好聊聊组件的行动。
四、组件的将来
我先抛出我的看法：组件将来一定要建设起生态，且组件生态一定是市场化的。
组件要解决的问题，相似于 SaaS 产品在现阶段想要解决的矛盾：以规范化的解决计划知足多样化的业务诉求。
从开展的目光看，业务诉求丰硕度的增长，一定是快过产品解决计划能知足的场景的增长，所以一定要部份场景是规范化的解决计划掩盖不了的。这一点从国际外的 SaaS 厂商纷纭规划本人的 PaaS 才能能够看出。
一样的，虽然组件知足的是疾速搭建业务运用的场景，但目前绝大少数的低代码产品，其组件的设计仍是核心化的：平台担任设计，开发者使用。当开发者的诉求无奈被知足时，他们提出了新的需要，平台开发新的组件。
问题是：这类核心化开发的模式下，组件能够被称为组件的条件是，它必需要有一定的通用性，不受场景的局限。这个条件自身就限度了组件模式的天花板。
事实上回归组件的定义：可复用的残缺功用模块。在这个定义下，咱们其实不强调组件一定要由平台出产和定义，平台能不克不及提供出产组件的才能，由泛滥开发者本人出产，自行使用呢。我了解是能够的，且在国外产品中曾经构建起这样的市场了。


在一款低代码产品中，咱们曾经能看到，当零碎提供的组件不克不及知足你的搭建诉求时，你能够在组件市场中装置更多的组件，而这些组件可能就是由第三方办事商开发实现的。
经过平台，充沛衔接起组件出产者、组件使用者、运用使用者等不同的利益相干方，这样的生态会使得有愈来愈多的为垂直行业而办事的复合组件泛起。
五、结语
这篇文章大抵呈现了我对组件相干的思考，因为篇幅的限度，以及出于可读性的斟酌，与组件相干的页面、流程、模型、变量等概念就没有提及，但你需求知道关于一款残缺运用来讲，以上这些都是很首要的零碎。
其实，从 0 到 1 开发一款运用并无那末容易，当我从事低代码之后，我才领会到一款运用发生的面前会关涉到如斯繁杂的零碎，这是我之前任务的盲区。
在这以前我作为产品经理，更多关注的是用户和客户的价值，较少关注产品的完成逻辑。这也是绝大少数产品经理的通病，不然也不会泛起「这个需要很简略，怎么完成我不论」这样的段子。
但若你真正走到产品面前，去从搭建的角度思考一款运用的从 0 到 1 ，你会对这份任务发生更多的畏敬之心的。
这是我半年来最大的播种。
专栏作家
鼎力哥呀，微信大众号：鼎力哥，人人都是产品经理专栏作家。一个90后产品经理，曾经写了6年的大众号，经过输入获取了许多意料外的生长。
本文原创公布于人人都是产品经理。未经许可，阻止转载。
题图来自Unsplash，基于CC0协定。
该文观念仅代表作者自己，人人都是产品经理平台仅提供信息存储空间办事。