update

.gitignore

@@ -0,0 +1,2 @@
+node_modules
+yarn.lock

docs/README.md

@@ -0,0 +1 @@
+# Hello VuePress

package.json

@@ -0,0 +1,15 @@
+{
+  "name": "FineUI-100-Questions",
+  "version": "1.0.0",
+  "main": "index.js",
+  "repository": "gitea@git.fanruan.com:dailer/FineUI-100-Questions.git",
+  "author": "zsmj <zsmj1994@gmail.com>",
+  "license": "MIT",
+  "scripts": {
+    "docs:dev": "vuepress dev docs",
+    "docs:build": "vuepress build docs"
+  },
+  "devDependencies": {
+    "vuepress": "^1.9.7"
+  }
+}

questions/10.BI.config的执行顺序是什么,为什么这么设计.md

@@ -1 +1,83 @@
 # BI.config的执行顺序是什么,为什么这么设计.md
+
+BI.config配置的方法除了`bi.provider.system`直接执行之外,全都是在获取资源的时候执行
+
+对于旧版本的FineUI, config配置的函数是在`BI.init()`中执行的,`BI.init()`又是在什么时候调用的呢,是在第一次`BI.createWidget()`时候调用的.
+
+这样带来了一个弊端,如果`BI.init()`先被调用了,那么后续`BI.config()`的内容将不再执行
+
+例如如下代码,javascript文件加载顺序为abcd,在旧有设计中,d.js获取的items长度是几?答案是1,因为在b.js中调用了`BI.Msg.toast`方法,而这个方法一定会间接的调用到`BI.init()`,这是不可控的,因为我们无法控制开发者要怎么写代码.很多时候出了bug,但是面对茫茫多的插件,完全不知道是由哪个文件引发的.
+
+```
+//  a.js
+BI.constant("bi.constant.items", [
+    {
+        id: 1,
+        text: 1,
+    },
+]);
+
+// b.js
+BI.Msg.toast("123");
+
+// c.js
+BI.config("bi.constant.items", items => {
+    items.push({
+        id: 2,
+        text: 2,
+    });
+    return items;
+});
+
+// d.js
+var items = BI.Constants.getConstant("bi.constant.items");  // 有几个?
+```
+
+BI.config注册的方法结构是什么样呢?
+
+```
+interface configFunctions {
+    [key: string]: Function[];
+}
+```
+
+`BI.config`的配置函数是如何执行的呢?
+
+对于每一个资源,都有一个配置函数队列,在每次获取资源的时候执行队列中的配置方法,顺序执行然后清空队列,如果之后再调用`BI.config`配置当前资源,重新讲配置函数加入队列中
+
+```
+BI.constant("bi.constant.items", [
+    {
+        id: 1,
+        text: 1,
+    },
+]);
+
+//  此时资源bi.constant.items的配置函数队列中只有一个配置方法等待执行
+BI.config("bi.constant.items", items => {
+    items.push({
+        id: 2,
+        text: 2,
+    });
+    return items;
+});
+
+//  获取资源的是执行并清空了队列
+var items = BI.Constants.getConstant("bi.constant.items");  // 2个
+
+//  又给资源bi.constant.items的配置函数队列中增加了一个配置方法等待执行
+BI.config("bi.constant.items", items => {
+    items.push({
+        id: 3,
+        text: 3,
+    });
+    return items;
+});
+
+//  获取资源的是又执行并清空了队列
+items = BI.Constants.getConstant("bi.constant.items");  // 3个
+```
+
+这样设计有什么好处呢?
+
+首先在获取资源时候才执行配置函数,完全避免了js加载顺序所带来的隐患,其次使配置可以无需立即执行并且可以多次配置.

questions/9.BI.config都可以做那些事情.md

@@ -0,0 +1,86 @@
+# BI.config都可以做哪些事情,有哪些应用场景?
+
+1. 修改组件的props
+
+```
+//  本示例修改了组件的type属性,也是常用的一种场景,讲一个组件替换为另外一个
+BI.config("bi.button", props => {
+    props.type = "my.button";
+    return props;
+});
+```
+
+2. 修改组件的默认props
+
+```
+//  本示例修改了bi.button的默认属性,配置方法是在组件的shortcut后面添加.props
+BI.config("bi.button.props", props => {
+    props.minWidth = 100;
+    return props;
+});
+```
+
+3. 修改常量资源
+
+```
+//  有如下常量资源
+BI.constant("bi.constant.items", [
+    {
+        id: 1,
+        text: 1,
+    },
+]);
+//  通过config方法拓展常量资源
+BI.config("bi.constant.items", items => {
+    items.push({
+        id: 2,
+        text: 2,
+    });
+    return items;
+});
+```
+
+4. 修改provider
+
+```
+//  定义provider
+var Provider = function () {
+
+    var items = [
+        {
+            id: 1,
+            text: 1,
+        },
+    ];
+
+    this.inject = function (item) {
+        items.push(item);
+    };
+
+    this.$get = function () {
+        return BI.inherit(BI.OB, {
+            getItems: function () {
+                return items.slice(0);
+            },
+        });
+    };
+};
+
+BI.provider("bi.provider.demo", Provider);
+
+//  配置provider,对外开放的拓展接口大多采用provider的形式. 这样有什么好处? 和直接配置constant有什么比优点吗
+BI.config("bi.provider.demo", (provider) => {
+    provider.inject({
+        id: 2,
+        text: 2,
+    });
+});
+```
+
+5. 配置一些系统级的配置
+
+```
+BI.config("bi.provider.system", (provider) => {
+    // Size相关,响应式,worker,模块依赖等
+});
+```