组件化编程及API设计

Posted by liveipool on July 15, 2017

组件化编程及API设计

最近在写图腾项目中的一个组件,下面是一些觉得值得注意的点。

组件命名

组件命名应该遵从以下几点原则

  1. 有意义: 名字不要太详细,也不要太抽象。
  2. 短: 名字最好是2-3个单词。
  3. 可读的:容易让人能读出来以便我们可以更容易的讨论它。
  4. 在我们的项目中尽量使用连字符。
<!-- 建议这样 -->
<app-header></app-header>
<user-list></user-list>
<range-slider></range-slider>

<!-- 避免这样 -->
<btn-group></btn-group> <!-- 足够短但是不容易发音,使用`button-group`代替 -->
<ui-slider></ui-slider> <!-- 所有的组件都是ui元素,所以这样命名无意义 -->
<slider></slider> <!--不是我们适应的风格 -->

保证组件模板中的表达式简短

把复杂的语法移动到methods或者计算属性中,这个在官方文档中也写到了,表达式太长容易表述不明。

保证组件的props简单

  • 尽管vue支持通过props传递复杂的object,但是你要尽量保持props传递的数据简单,尽量只传递基本数据类型(strings, numbers, booleans)
  • props只传递简单类型数据和函数,让我们组件的api看起来更像原生html的属性。
  • props传递复杂数据类型,让你的组件很难重构,也会造成代码冗余。
<!-- recommended -->
<range-slider
  min="0"
  max="100"
  :on-end="updateResults">
</range-slider>

<!-- avoid -->
<range-slider :config="complexConfigObject"></range-slider>

对你组件的props做一些限制

  • vue 组件中props就是api,健壮且可预测的api让别人更容易使用你的组件
  • 对props做一些限制保证你的组件正常工作,即使别人没有按照你预想的方式调用你的组件。
  • 属性设置默认值
  • 属性设置数据类型校验
  • 使用组件之前检查props是否存在

单一职责原则

保持组件的单一职责很重要

API设计

  • 命名尽量不要超过三个单词,易读易记
  • 保持接口的流畅性,即降低映射成本和记忆成本
  • 保持接口风格的一致性
  • 永远不修改接口,只扩展它!可扩展性同时会要求接口的职责单一,多职责的接口很难扩展。
// 保持接口风格的一致性
Nightware:
setColor,
letBackGround,
changefontSize,
makedisplay,

dream:
setColor,
setBackground,
setFontSize,
set.........

设计思想

  • 尽量简单
  • 保持可扩展性

以上内容只是刚开始学习进行组件开发时上网查到的一些觉得好的点,但这种东西肯定要慢慢在自己的编码过程中体会和总结,因此这篇博客还会根据组件的开发过程进行持续更新…

开发组件一个多星期后对整个组件开发的一些体会

这一周多的时间主要对组件进行编码实现,感觉前期的认真分析需求还是帮助很大,以致于在开发过程中没有太大程度需求变更。API的设计改动也不算太大。

设计、开发组件的流程

其实一个组件主要也是分为设计和开发两个阶段,先设计好,再开发,因此这里主要记录一下设计组件的顺序。
感觉这次开发这个组件时的设计顺序还是不错的:
1.首先理清需求,汇总原型图、高保真图,记录下所有需求点。
2.根据需求点、原型图等,对其进行功能点的拆分,再对每个功能点的重要性和优先级等进行标注,列出来,使得各个阶段应该实现什么功能显得清晰。
3.思考应用场景,我感觉将这一步放在这里的作用有两点,一是可以看看是在某些特定的应用场景下,会不会有一些前面没有考虑到的实际场景中可能会需要的功能点;二是为后面的api设计思考一下将组件提交给客户程序员去用时,需要考虑写什么东西。
4.进行api设计。
5.记录交互设计、设计思想等。

下面是一些在上面某些阶段中的一些更细的点总结。

进行功能点的划分时要判断是否有依赖

在最开始划分功能点时,我将一个缩放功能放到了比较靠后的位置,将做标记这个功能放到最先完成,但还好及时有人提醒,因为在进行缩放之后进行的标注也要对应变动,因此需要先做完缩放功能,再在其基础上进行开发,难以想象如果我一开始就开始做标记,等到后来才发现标记需要对应缩放或移动时,那时候的返工率就相当高了。
因此,以后在划分功能点时,要考虑清楚,有没有哪些点是需要前置条件的,那些前置条件一定要提前先完成了。

尽量暴露多一些东西给客户代码使用

这样能使组件的灵活性更高,尽量不要在组件里写死什么东西,交互、样式等,尽量都让客户能够控制。因为就算你的组件功能再强大,但客户无法将其背景色改为灰色,那么很可能客户就不会使用这个组件了。为了避免这种情况,一定要考虑全一点,特别是写完后检查一下,把自己当作使用这个组件的客户来思考,比如我要实现一个什么什么样的功能,是不是能够满足要求。

动态的比静态的更好

在最开始设计API时,我没有考虑到这个问题,我设计的接口,比如能否缩放,能否拖动,都是静态的数据,我想的是在进行初始配置时读取这个数据来判断是否可以缩放、拖动等。但是参考了其他人的做法后,我觉得更好的实施是将其写为能够动态控制的,因为客户可能会在某个事件后禁止拖动,只有动态的API能满足这个需求。

确定好输入和输出

对组件的输入和输出一定要确认清楚,清楚到数据结构,因为如果对这个没搞清楚,以后很可能会经常要改动api,而api是尽量不要改动的。

在api文档中提供一些默认的或参考的具体代码

只是一些参数名或方法名的话,使用组件的人会有一定的学习成本,而给出一些默认的或参考的代码(参考逻辑、样式)等,会降低这个成本。
赞赏码.jpeg