Gray Zhang

> 我有点纠结：这里的都注入一次，是同一个实例，还是不同的实例？ 我建议可以暴力点用不同实例，在设计上我们就应该避免这样的情况，当然可以允许在`config`上就配置一些什么来告诉你用`setXxx`还是`setter`，这个可以以后再加强且对auto起不了作用

大致看了一下，定义接口这个东西，简单的方法就是每个对象注入的时候去判断是否符合已经定义的接口，符合的话按接口的配置先注入，然后再跑对象自己的注入 但这对性能是有些影响的，因此是否可以引入一个“预编译”的过程，可能有以下几点： 1. 接口定义判断“类型”而不是“实例”，即要`typeof type.prototype.xxx === 'function'`来判断，因为预编译时没有实例 2. 对象的模块第一次被加载下来（未实例化）时，要预编译一次，即去匹配接口，有的话把配置混合到这个配置上（接口的优先级低） 3. 获取对象逻辑就不变了 我比较不爽的是第1点要去判断类型而非实例，觉得访问类型的`prototype`其实不是个好的决定

> 很难确保不会在实例上添加方法 我认为直接无视，或者给个接口重新config > 很难保证说对象一定是 new 出来的，这样就不一定能够保证带有 prototype 嗯这是个问题 > 我想是初始化的时候从实例获取接口依赖，然后缓存，接下来就不需要去解析接口依赖了，仅仅在第一次会有点性能消耗 这个……如果不是单例，会有多次实例化，这个缓存后不是依旧会有你说的1的问题吗

是啊，所以第2次实例化前有给`prototype`加方法改变类型的定义，缓存还是会出问题，所以我觉得把1给无视掉

本质是个方法，简化写法用来生成这个方法好了，因为有些接口会是要求多个方法合在一起才算一个的啊

我们现在主要有哪些场景对同步获取组件有需求？在我的概念里2016年了，async/await已经大规模使用了，用异步组织逻辑也应该比较自然了

场景是，下一代的ESUI我规划可以和IoC接入 比如我们的`ActionPanel`，它会依赖一个`Controller`实例来加载Action，但是就现在来说，只能使用默认的那个实例（就是`er/controller`模块），这不是一个合理的设计，因为用户可能定制自己的`Controller`实例在那用 因此我希望在创建了`ActionPanel`之后，可以经过IoC把它管理的`Controller`实例注入进去 另一种方法是所有控件都让IoC创建，这是一个方法但直观感觉会遇上不少的问题不见得容易实现

1. 我不想让`ActionPanel`知道IoC所以不能控件直接找IoC要东西 2. 除了`ActionPanel`，也有别的控件需要别的在IoC中的东西，而哪些IoC中有可以拿，哪些没有，这个事ESUI或者业务系统写的`UIParser`（对应现在的`esui/main`的东西）都不应该知道 所以我的想法是，有一个特殊的`UIParser`，会在每一个控件创建出来以后（某个事件），去IoC中加工一遍，然后再往上加`uiProperties`等信息，再返回，而加工一遍里做了什么，这个让`UIParser`的子类来实现或者在IoC中实现理论上都可以，IoC来做的话应用面会更广

我的想法是： ``` javascript // UIParser.js var control = createControlFromElement(currentElement); ioc.inject(control); control.render(); ``` 这样`control`里所有IoC能注入的属性都会完成注入

以后ESUI的`init`肯定是异步的这个没问题，在真正生产环境上这里的异步一般不会有网络开销 那如果可以提供一个config id的话，注入应该就很容易做了吧？