Ques

 
> Ques是一套由`腾讯课堂团队`开发的组件化系统，解决如何定义、嵌套、扩展、使用组件。
>
> Ques，可以使得开发者通过`Markup`来引入组件，而无需关注组件内部的依赖以及关系，真正做到一处引用，立刻使用。使用统一的接口来管理组件，让代码可预测，逻辑可分辨。

### 快速使用

* 安装依赖

> npm install

* 运行学习环境

> gulp learn

* 浏览DEMO

打开浏览器，打开页面：http://localhost:3000/learn

### 基本命令

* 启动学习环境

> gulp lean

打开浏览器，打开页面：http://localhost:3000/learn

* 启动开发环境

> gulp app

打开浏览器，打开页面：http://localhost/index.html

* 构建

> gulp

生成到dist文件夹，具体请参见`gulpfile.js`。

* 升级

> gulp update

更新到`miniflycn/Ques`主干的最新版本。

### 组件化的含义

未来组件不再是`Javascript插件`，或者是`模版`、`样式`、`逻辑`这种分离的个体。而应当更像`Custom Element`，回想一下我们是如何使用一个`input`标签的？

在页面写下`<input>`，并设置她的初始化`value`，则她便可在页面按其默认样式展示，然后在Javascript中`绑定她的事件`、`设置她的值`、`使用其方法`。

简单的说，`input`标签有她自有的`结构`、`样式`、`逻辑`。于此类似，我们期望的组件具有下面的特点：

1. 可以在页面通过写一个标签引入，例如一个dialog组件，我们可以通过`<dialog></dialog>`简单引入
2. 我们可以通过简单的方式得到他的Javascript实例
3. Javascript实例应当有自己的`数据模型`、`方法`、`事件`，所以我们可以把其看成是一个`状态机`，在数据变化的时候，View会产生变化
4. 组件可以嵌套(即组合)、扩展(即继承)，组件应当可以自行管理自己嵌套的子组件

### 这样做有什么好处？

那么这样做的好处是什么，我先说下不这样做的坏处是什么吧：

1. 传统的组件在使用时需要知道需要使用什么`模版`、`样式`、`脚本`，并且这些东西被分散在`HTML`、`CSS`、`Javascript`不同的地方引用，组件的插拔是非常麻烦的
2. 传统的组件由于没有统一的规范支持，所以`引入`、`调用`方式千差万别，开发人员必须在详细了解清楚之后才可使用
3. 无法简单地或者根本没办法实现组件的嵌套或扩展，或者实际上只是Javascript的组合和继承，CSS和模版没有半毛钱关系。

### 与当前一些好的组件化机制对比

1. 现代的一些组件(例如FIS2)机制，虽然已经Component化，但是无法嵌套、扩展，无法自由控制粒度，复用性较差(暂时了解的情况不知道理解正确不正确)
2. 还有一些组件机制(例如React)，其以Javascript作为容器，在体验上较为反前端，而我们和基本的前端体验是对齐的
3. 最后一些组件机制(例如Polymer)，她比较未来，较长时间内都无法使用