HE Shi-Jun
HE Shi-Jun
应该不会再这么干，不是都没有$scope了嘛。
所以即使嵌套，你写变量时总是 {{main.title}} 或 {{inner.title}} 来明确指定，所以不存在$scope继承的场景了吧。其实原本它也可以用 {{InnerCtrl::title}} 或者 {{parent::title}} 这样的语法来明确。不知道为什么要搞一个 prototype 继承，只能理解为当初在实现时一拍脑袋觉得这样很cool……
这个是之前发在 div.io 上的吧。我还没帐号，所以只能看不能回复。还是贴在 github 上好。
民工兄我估计现在某些考虑可能变化了。比如脏检测，总得来讲，A1的方式是有问题的。 大量更新这个事情我觉得不是主要矛盾。比如假设所有更新都是promise——那么至少也不会把浏览器给卡死，那么就算连续触发了上千次更新似乎也不是大问题。
@xufei 有没有比较实际的例子，我总觉得巨量界面更新像是edge case。
如果是普通的 getter/setter 方式我产生了 200 次 set，然后触发 200 次对 input checked 的写……如果是react那样产生200次virtual dom我倒是有点担心，但是如果是直接track到元素的那种方式好像也没啥大不了的。另外，我觉得就算用getter/setter也有一个简单的方式，就是我不是直接触发更新，而是设一个dirty标志就好了，在下一次异步时批处理就好了。
@xufei _公共部分的疑问其实已经有解决方案，就是 SharedWorker。_ [更新] 又想了下，这个场景还是 @yyx990803 说的在createCallback中注入更适合。或者就是通过暴露自定义dom property来做（允许主文档指定不同的数据源）。还有一种可能的方式是用通过es6 module导入公共模块（前提是内部的loader是和主文档相同或衍生的）。
namespace 那个我赞同。现在草案用短横线的方式是过犹不及的愚蠢方式。
我个人对wc持保留意见，倒不是在这些方面，而是自定义标签太容易被滥用。看看polymer的例子，大部分都是实现ui，完全违背语义化。更不要说一个custom element内部的实现（当然作为内部实现，dirty通常是无所谓的）。当初 BECSS 没有进一步标准化，至少也有因此遭到反对的部分原因。
嗯，不知道这个module部分当初是谁挖的坑，有那么多珠玉在前，还做得那么烂，应该拖出来打一顿，呵呵。