Rumah  >  Artikel  >  hujung hadapan web  >  assets与static使用案例剖析

assets与static使用案例剖析

php中世界最好的语言
php中世界最好的语言asal
2018-06-09 16:07:362672semak imbas

这次给大家带来assets与static使用案例剖析,assets与static使用的注意事项有哪些,下面就是实战案例,一起来看一下。

资源文件处理

在我们的项目结构里,有两个资源文件的路径,分别是:src/assets 和 static/。那这两个到底有什么区别呢?

Webpacked 资源

为了回答这个问题,我们首先需要理解webpack是怎样处理静态资源的。在*.vue组件中,所有的templates和css都会被vue-html-loader 和 css-loader解析,寻找资源的URL。

举个例子,在 和 background: url(./logo.png), “./logo.png”中,都是相对资源路径,都会被Webpack解析成模块依赖 。

由于logo.png不是JavaScript,当被看成一个模块依赖的时候,我们需要使用url-loader 和 file-loader进行处理。 该模板已经配置好了这些loaders,所以你能够使用相对/模块路径时不需要担心部署的问题。由于这些资源可能在构建的时候被内联/复制/重命名, 所以它们从本质上来说是你源码的一部分。这就是为什么我们建议将交由webpack处理的静态资源和其它源文件一样放在/src路径下面。实际上,你甚至不需要把它们全都放在/src/assets路径下:你可以基于模块/组件的使用来组织文件结构。例如,你可以把每个组件和属于它的静态资源放在它自己的目录下。

资源处理规则

相对URL, e.g. ./assets/logo.png 将会被解释成一个模块依赖。它们会被一个基于你的Webpack输出配置自动生成的URL替代。没有前缀的URL, e.g. assets/logo.png 将会被看成相对URL,并且转换成./assets/logo.png

前缀带~的URL 会被当成模块请求, 类似于require(‘some-module/image.png'). 如果你想要利用Webpack的模块处理配置,就可以使用这个前缀。例如,如果你有一个对于assets的路径解析,你需要使用 来确保解析是对应上的。相对根目录的URL, e.g. /assets/logo.png 是不会被处理的

在 Javascript中获取资源路径

为了能让Webpack返回正确的资源路径,你需要使用require(‘./relative/path/to/file.jpg'),由file-loader进行解析,然后返回处理过的URL。例如:

computed: {
 background () {
  return require('./bgs/' + this.id + '.jpg')
 }
}

注意上面的例子,在最终的构建时将会包含./bgs/路径下的所有图片 这是因为Webpack不能猜出来在运行时会用到其中的哪个,所以会包含所有的。

“真实的” 静态资源

作为对比,在static/下的文件都不会被Webpack处理:它们使用相同的文件名,直接拷贝到最终的路径。你必须使用绝对路径来引用这些文件,取决于在config.js里面加入的build.assetsPublicPath 和 build.assetsSubDirectory。

举个例子,下面的默认值是:

// config/index.js
module.exports = {
 // ...
 build: {
  assetsPublicPath: '/',
  assetsSubDirectory: 'static'
 }
}

所有放在 static/目录下的文件都应该是使用绝对URL/static/[filename]引用的。如果你将assetSubDirectory的值改成assets, 那么这些URL就会被变成 /assets/[filename]

相信看了本文案例你已经掌握了方法,更多精彩请关注php中文网其它相关文章!

推荐阅读:

vue+props传递数据怎样实现

SQL正则与mybatis正则使用详解

Atas ialah kandungan terperinci assets与static使用案例剖析. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan:
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn