什么是数据驱动型组件？
其实，目前来说，也只有HEYUI组件库是这种方式的尝试者，这也是我在设计组件库的过程中，慢慢思考的成果。
所以，关于这一种定义，还没有人运用过。 当然，这也是HEYUI区别于其他组件库很重要的一点。 不熟悉HEYUI的人，可以移步：。 或者也看下我们自我介绍的文章：。前言
有很多人对于我写的关于HEYUI的不是很容易理解。
所以，今天这篇文章主要是用于仔细说明HEYUI这个“数据驱动型组件”到底是什么？ 并由数据驱动型组件引发的全局配置又是如果使用的。数据双向绑定
在说组件之前，我们来说说数据双向绑定。
我们目前终于摆脱使用jquery操作dom的方式来完成所有的交互，而是使用数据双向绑定的机制来完成我们的前端交互。 那为什么越来越多的人选择使用双向绑定呢？ 因为我们希望，我们只需要来处理交互的逻辑就好，这样逻辑的变动引发的dom变动，如果能变成自动的，那么我们的开发速度，以及代码质量将会大大的增高。 想起以前，我们的修改了一个值，jquery修改一个地方的展示，修改了第二个地方的展示，还悲催的漏了第三个的改动。那同理，我们来说说数据驱动型的组件。
数据驱动型组件
在数据双向绑定的基础之上，我们简化了dom的操作，甚至已经抛弃了jquery。
而依据于双向绑定机制开发的组件，越来越多。那数据驱动型组件，到底和普通的组件有什么不一样的呢？
首先，我想问，大多数前端组件，到底是用来做什么的呢？我给的答案是：给用户一组数据，让用户去选择
我将我写在heyui的全局配置的文字拿过来说明一下：
- 1~5个选择项单选：Radio, 或者Select
- 1~5个选择项多选：Checkbox, 或者Select(multiple)
- 5~15个选择项单选/多选：Select
- 15~40个选择项单选/多选：Select(filterable), 或者AutoComplete
- 40个以上或者需要远程模糊查询：AutoComplete
- 拥有层级信息的数据选择：TreePicker
不管设计是什么样子的，但是数据和交互都是一致的。
我不在乎组件是什么样子的，我们要做的，是帮你将数据与内部的交互机制封装好，让你可以按照自己的需求开发，不需要重复写一套又一套，逻辑一模一样的代码。下面，我们通过示例来说明。
示例
线上代码&运行：
简单应用
我们以demo1的示例来说明。
所有的组件都是通过datas来做处理的。复制代码
我们再看看element的示例，包括iview与ant-design都是这一种方式。
复制代码
这里主要的区分是我们没有option选项的标签编写。
其实option标签的编写，还是继承了html原生模式的思维模式。如果你仔细看heyui的select组件，你会发现，其实我们是通过单选，双选，有没有‘请选择’选择项等配置来设定select的行为，而本身select的选择来源，我们通过dict统一配置。
有兴趣的可以去 查看。代码说明
1、展示数据驱动型组件
通过使用datas的数据，我们可以渲染不同的组件。
代码目录：src/components/demo/datas2、定义字典
代码目录：src/js/config/dict-config.js
3、使用字典配置
代码目录：src/components/demo/dict
4、更多的应用
优势
更少的重复代码量
select 等组件，原则上面都key与title的数据，然后进行选择。
当然，我们也拥有更复杂的展现形式，这个heyui是支持的。复制代码
复制代码
当在你的系统复用无数遍的select，你会发现你的代码极其简洁。
代码可读性
当你编写一个庞大的Form，代码量的减少，一行一个组件，这样的方式可以让我们的代码可读性非常的高。
而在一些代码的复制上面，你只需要关心v-model绑定的函数，减少了无数个for循环的代码。 代码可控性
使用dict config，通用的字典集中化配置，更好的调用，更好的维护。
dict属性的配置即可完成。 背景图--LAN（摄于四川若尔盖）