B 端组件法律规范定义撰写编辑导语：组件库的搭建在一定程度上可以提高产品开发效率，减少业务流程中的疑惑产生。那么，应该如何设计组件、快速定义 B 端的组件法律规范？本篇文章里，作者结合自身撰写、升级组件库的经验，从阶段出发，对如何定义B 端组件法律规范做了总结，一起来看一下。 各大设计团队为了释放设计人力，会根据业务情况封装组件库，后续开发成代码，方便前端同学进行组件调取，也同时节约了开发成本。 写这篇文章是根据自己撰写并升级了原有组件库的经验，让大家大概了解设计组件背后需要做哪些工作，日后制定组件法律规范可以直接套用。一、写组件的目的 在工作中做一件事情首先要思考做了之后要达到什么样的效果。写组件的目的就是要让每一个场景下的操作都具有合理性，让产品变得好用、易用、可用。让各个业务在遇到类似的业务需求时，不要产生：应该使用哪个组件？组件操作应该包含哪些状态反馈给用户？不同业务，同一品牌下如何保证交互一致性？组件不能满足应该怎么办？ 一系列模棱两可的疑问。二、写组件的前期准备：组件结构层梳理 从层级上排列：产品——应用——页面——模块——组件。组件在页面中属于原子级的元素。 首先对团队业务组件进行盘点、同时对比行业内竞品组件，比如 Ant Design、飞冰 Iceworks、Element、SUI、iView、Admui、Zent。 第一步：根据组件的作用进行分类，梳理组件清单，比如：组件分为通用类、导航类、数据输入类、数据展示类、反馈类等。 第二步：梳理完成后划分组件设计优先级，参考维度：『我们』有+行业内有（p0）、『我们』有+行业没有（p1）、『我们』没有+行业有（p2）。『我们』有+行业内有（p0）：代表了这类组件是解决行业内产品问题高频应用的刚需组件，比如搜索、按钮等。『我们』有+行业没有（p1）：代表这类组件多为业务类型组件，是业务的特别性产生了这类组件，比如：卡片、折叠面板等。『我们』没有+行业有（p2）：代表了这类组件可能是行业内潜在有某种业务形态，列在『我们』范围内以免以后遇到类似的，无法律规范可查。 第三步：对组件进行结构层、行为层和表现层元素进行拆解，参考标准为是否常变动。 三、写组件前期准备：行为场景梳理 其实结构层分为组件种类（导航类、按钮类、提示类……）和组件类别（下拉菜单、顶部 tab、走马灯……）分析到现在应该得到的是原子级的组件类别，接下来就需要根据场景继续细分组件的形态，从而得到组件形态的分...
