Home >Web Front-end >JS Tutorial >Assets and static use case analysis

Assets and static use case analysis

php中世界最好的语言
php中世界最好的语言Original
2018-06-09 16:07:362685browse

This time I will bring you an analysis of the use cases of assets and static. What are the precautions for using assets and static? The following is a practical case, let's take a look.

Resource file processing

In our project structure, there are two resource file paths, namely: src/assets and static/. So what is the difference between the two?

Webpacked Resources

In order to answer this question, we first need to understand how webpack handles static resources. In the *.vue component, all templates and css will be parsed by vue-html-loader and css-loader to find the URL of the resource.

For example, in and background: url(./logo.png), "./logo.png", they are all relative resources Paths will be parsed into module dependencies by Webpack.

Since logo.png is not JavaScript, when it is regarded as a module dependency, we need to use url-loader and file-loader for processing. The template already has these loaders configured, so you can use relative/module paths without worrying about deployment issues. Since these resources may be inlined/copied/renamed at build time, they are essentially part of your source code. This is why we recommend placing static resources processed by webpack under the /src path like other source files. In fact, you don't even need to put them all under /src/assets: you can organize the file structure based on module/component usage. For example, you can put each component and its static resources in its own directory.

Resource processing rules

Relative URLs, e.g. ./assets/logo.png will be interpreted as a module dependency. They will be replaced by an automatically generated URL based on your Webpack output configuration. URLs without a prefix, e.g. assets/logo.png will be treated as relative URLs and converted to ./assets/logo.png

URLs prefixed with ~ will be treated as module requests, similar to require( 'some-module/image.png'). Use this prefix if you want to take advantage of Webpack's module handling configuration. For example, if you have a path resolution for assets, you need to use to ensure that the resolution is correct. URLs relative to the root directory, e.g. /assets/logo.png will not be processed

Get the resource path in Javascript

In order to allow Webpack to return the correct For the resource path, you need to use require('./relative/path/to/file.jpg'), which will be parsed by file-loader and then the processed URL will be returned. For example:

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

Note that in the above example, the final build will include all the images in the ./bgs/ path. This is because Webpack cannot guess which one of them will be used at runtime, so it will All inclusive.

"Real" static resources

As a comparison, files under static/ will not be processed by Webpack: they use the same file name and are copied directly to final path. You must use absolute paths to reference these files, depending on build.assetsPublicPath and build.assetsSubDirectory added in config.js.

For example, the default value below is:

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

All files placed in the static/ directory should be referenced using the absolute URL /static/[filename]. If you change the value of assetSubDirectory to assets, then these URLs will become /assets/[filename]

I believe you have mastered the method after reading the case in this article. For more exciting information, please pay attention to other php Chinese websites. related articles!

Recommended reading:

How to transfer data through vue props

Detailed explanation of the use of SQL regular and mybatis regular

The above is the detailed content of Assets and static use case analysis. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn