Closed easonyq closed 6 years ago
从目前的例子 example/simple 来看,组件的模板是定义在当前使用页面中,如
example/simple
<script type="text/x-template" id="mip-tree-template"> <div></div> </script>
我不确定这是不是最终方案?
如果是,那么 mip-router 在切换页面时也需要将这一段脚本视作组件的一部分,同 mip-tree.js 一同被加载(我暂时就是这么做的);如果不是,例如融合到 mip-tree.js 内部或者其他方案,请周知一下。
mip-tree.js
我认为目前定义在用户页面上:
优点:允许每次使用时定义组件的内部结构,很大限度的扩展了组件复用性。例如某两个组件,数据请求部分相同,仅仅是展现内容/顺序/结构不同,就不需要编写成两个组件了。
缺点:用户页面需要定义每一个用到的组件的模板,会导致用户页面非常长。先不考虑页面变大引起的请求时间变长(可能可以忽略),对于开发者开发页面也可能造成压力和成本。
折中:在 mip-tree.js 内部定义默认模板,并允许开发者重写。重写时必须遵循相同的 id,例如必须为 id="mip-tree-template"
id="mip-tree-template"
组建采用 customElement 之后,模板也被包裹到组建 js 中了,因此用户模板上就没有了。
customElement
从目前的例子
example/simple
来看,组件的模板是定义在当前使用页面中,如我不确定这是不是最终方案?
如果是,那么 mip-router 在切换页面时也需要将这一段脚本视作组件的一部分,同
mip-tree.js
一同被加载(我暂时就是这么做的);如果不是,例如融合到mip-tree.js
内部或者其他方案,请周知一下。我认为目前定义在用户页面上:
优点:允许每次使用时定义组件的内部结构,很大限度的扩展了组件复用性。例如某两个组件,数据请求部分相同,仅仅是展现内容/顺序/结构不同,就不需要编写成两个组件了。
缺点:用户页面需要定义每一个用到的组件的模板,会导致用户页面非常长。先不考虑页面变大引起的请求时间变长(可能可以忽略),对于开发者开发页面也可能造成压力和成本。
折中:在
mip-tree.js
内部定义默认模板,并允许开发者重写。重写时必须遵循相同的 id,例如必须为id="mip-tree-template"