mip-project / mip

MIT License
11 stars 1 forks source link

MIP 静态资源加载方案 #3

Open PengXing opened 6 years ago

clark-t commented 6 years ago

既然 MIP 2.0 允许用户自定义组件,就必然会存在组件之间相互依赖的问题。那么组件在打包的时候有两种方案:

  1. 将组件依赖到的所有的资源全部打包成一个 js,这样能够保证组件自身的完整性,在使用的时候跟 MIP 1.0 一样引入对应的 script 标签即可,也不需要去关心组件相互依赖问题。存在的问题就是代码冗余。
  2. 将组件里依赖到的其他组件给 external 出来,这样就能够解决代码的冗余问题,但是这就涉及到了组件加载顺序的问题。

在 MIP 1.0 里面需要开发者在用到什么组件,就在 <body> 最后面添加相关组件的 <script> 标签即可,一旦涉及到加载顺序问题,就需要开发者去关心 script 引入的先后顺序问题了。这个问题有个解决方法是 MIP-core 内置了类似 requirejs、esl 之类的机制去统一管理组件的加载问题,由于标签跟 <script> 是对应的,<script> 的地址又是固定的(都在 mip 组件的 cdn 上),那么甚至可以进一步让 MIP-core 去分析标签对,并生成资源请求 url 就完事了,这样子后端吐出的模板只有一个 script 标签:

<html>
    <head></head>
    <body>
        <mip-component-1></mip-component-1>
        <mip-component-2></mip-component-2>
        ......
        <script src="path-to-cdn/mip.js"></script>
        <!-- 然后就没别的 script 标签了 -->
    </body>
</html>

上述方案存在的问题就是会比原先直接写 <script> 的方法降低加载效率。

所以还有一种做法就是 mip 开发工具提供页面组件依赖分析,输入 mip 标签对结构,直接能输出排好序的 <script> 标签。但这就需要开发者主动去使用开发工具去做这件事情,以至于在开发页面的过程中,每增加一个组件,就要手动去重新生成 <script> ,再去修改后端模板,整个过程会不会变得非常繁琐,或者是开发的时候使用前面提到的自动加载方案,等上线的时候再要求手动跑一次依赖分析,自行插入 <script> 标签?

另外,工具分析依赖的方式也可以通过接入 jet 服务实现,但遇到的开发繁琐的问题跟上面是一样的,每添加删除一个 url 都会引起 jet bundle js 的 url 发生变化。

以上就是两种组件打包方案缩带来的静态资源加载策略缩存在的问题和解决方法,欢迎大家讨论使用哪种方案更好,也欢迎提出更好的解决方案。