Importing a static asset like an image in V will return the resolved public URL when it's served. Let's take a look at an example. vue, I'll import the Vue logo from the assets directory and console log in. When we take a look at this in the console, you'll see that we just get a plain, simple string.
This string represents the public absolute path to the resource. End. If I visit that path directly, sure enough, the browser loads up the image. Perfect.
While we're in development, the image name is exactly the same as the actual file name. But when we build for production, it'll have a random hash in it to help with cache busting. Let's see that real quick. To build our application, we can stop the dev server and then run npm run build then.
We'll also run npm run serve. And what this command does is allow us to preview our built app locally. Notice here that the port on the link is different than that of the dev server. In my case, it's 5,000.
And it'll probably be the same for you as well if that port isn't already busy. So just don't let that confuse you. If I were to refresh our page here on the right now, yeah, it'd break. because it's still looking for the development server at port 3000.
Let's just change it to 5000 in the URL to see our built app. Cool. This time when we look at the console log, you'll see the file name has a cache-busting hash in it, and we didn't have to do anything extra to get that. Pretty sweet.
Once again, visiting that URL directly in the browser, sure enough, we get the logo. Another thing to notice... is that when referencing assets in the template area of a single file component, V actually automatically converts these into imports, such as when the logo is used in the image tag. If we inspect the logo on the built production site, once again we see the hash.
Nice! One thing worth noting about this auto-importing is that it only works when the image path is hard-coded in the template area. If you were to store it in a variable and reference that variable in the template, it would not work. This has bit me before, so let me show you.
I'll comment out our import of logo and remove the console log. Then I'll create a variable called logo in the script section and assign the view logo's path to it. Then I'll reference that variable in the template where it was previously hard-coded. Now if I stop my preview server and rerun the development server and visit it at the proper port in the browser.
Yeah, you'll see that the image no longer works. Okay, so how do we fix this? Well, we have a couple options. We could reinstate the import we just commented out and use it instead.
Sweet! Yeah, that works. url. and that looks something like this.
Doing this allows us to obtain the full resolved URL as a static asset using a relative path from the current JavaScript module. This actually works natively in modern browsers, meaning that Vite actually doesn't need to process this code at all during development. Cool, that's a big plus for speed. This approach can also be really useful when the paths of your static assets are more dynamic and can't be hard-coded directly in the file.
Nice. I'll just hard-code it again in the template though, since we do know the file path isn't dynamic in this case. Alright, if you ever have any images that you don't need processed at all, or don't want to have the filename hashed in production, you could put those images in the public directory. To demonstrate, let's move the view logo to public.
Now, instead of referencing it via a relative path, we need to use the absolute path instead. The absolute path is in relation to the public directory. So . slash assets slash logo dot png becomes slash logo dot png.
Cool. And you can see the image now working on the development server. Also, if I stop the development server, run build, and start up the preview server again, when I visit the proper URL in the browser, and inspect the element, you'll see that the image name doesn't include the hash. It's the filename exactly as we saved it in the file system.
Awesome! Finally, let me show you one more feature that V provides before we wrap up this lesson on images. Alright, in the video's description below, you'll find a link to a tiny version of the Vue logo. You can download it and use that image for this portion.
I've got it right here on my file system already though, and it's only about 3k. So, Let's move that file into the assets directory of our project. Then we can import that for our image tag. Once again, I'll stop the preview server, rebuild the app, and rerun the preview server.
This time when we inspect the image tag instead of the source being a URL. And whoops, let's refresh the page. Yeah, this time it's a Base64 encoded image. Vite does this automatically for us.
for any image that's under 4 kilobytes, or any other size that we choose to configure it for, and we'll see how to configure that in a later lesson. What this does, though, is save our application from making round trips to the server for data that could be downloaded alongside the rest of the page. It's just one more way that Vite makes things fast. Not just for us, the dev, but for our end users as well.
Importing a static asset like an image in V will return the resolved public URL when it's served. Let's take a look at an example. vue, I'll import the Vue logo from the assets directory and console log in. When we take a look at this in the console, you'll see that we just get a plain, simple string.
This string represents the public absolute path to the resource. End. If I visit that path directly, sure enough, the browser loads up the image. Perfect.
While we're in development, the image name is exactly the same as the actual file name. But when we build for production, it'll have a random hash in it to help with cache busting. Let's see that real quick. To build our application, we can stop the dev server and then run npm run build then.
We'll also run npm run serve. And what this command does is allow us to preview our built app locally. Notice here that the port on the link is different than that of the dev server. In my case, it's 5,000.
And it'll probably be the same for you as well if that port isn't already busy. So just don't let that confuse you. If I were to refresh our page here on the right now, yeah, it'd break. because it's still looking for the development server at port 3000.
Let's just change it to 5000 in the URL to see our built app. Cool. This time when we look at the console log, you'll see the file name has a cache-busting hash in it, and we didn't have to do anything extra to get that. Pretty sweet.
Once again, visiting that URL directly in the browser, sure enough, we get the logo. Another thing to notice... is that when referencing assets in the template area of a single file component, V actually automatically converts these into imports, such as when the logo is used in the image tag. If we inspect the logo on the built production site, once again we see the hash.
Nice! One thing worth noting about this auto-importing is that it only works when the image path is hard-coded in the template area. If you were to store it in a variable and reference that variable in the template, it would not work. This has bit me before, so let me show you.
I'll comment out our import of logo and remove the console log. Then I'll create a variable called logo in the script section and assign the view logo's path to it. Then I'll reference that variable in the template where it was previously hard-coded. Now if I stop my preview server and rerun the development server and visit it at the proper port in the browser.
Yeah, you'll see that the image no longer works. Okay, so how do we fix this? Well, we have a couple options. We could reinstate the import we just commented out and use it instead.
Sweet! Yeah, that works. url. and that looks something like this.
Doing this allows us to obtain the full resolved URL as a static asset using a relative path from the current JavaScript module. This actually works natively in modern browsers, meaning that Vite actually doesn't need to process this code at all during development. Cool, that's a big plus for speed. This approach can also be really useful when the paths of your static assets are more dynamic and can't be hard-coded directly in the file.
Nice. I'll just hard-code it again in the template though, since we do know the file path isn't dynamic in this case. Alright, if you ever have any images that you don't need processed at all, or don't want to have the filename hashed in production, you could put those images in the public directory. To demonstrate, let's move the view logo to public.
Now, instead of referencing it via a relative path, we need to use the absolute path instead. The absolute path is in relation to the public directory. So . slash assets slash logo dot png becomes slash logo dot png.
Cool. And you can see the image now working on the development server. Also, if I stop the development server, run build, and start up the preview server again, when I visit the proper URL in the browser, and inspect the element, you'll see that the image name doesn't include the hash. It's the filename exactly as we saved it in the file system.
Awesome! Finally, let me show you one more feature that V provides before we wrap up this lesson on images. Alright, in the video's description below, you'll find a link to a tiny version of the Vue logo. You can download it and use that image for this portion.
I've got it right here on my file system already though, and it's only about 3k. So, Let's move that file into the assets directory of our project. Then we can import that for our image tag. Once again, I'll stop the preview server, rebuild the app, and rerun the preview server.
This time when we inspect the image tag instead of the source being a URL. And whoops, let's refresh the page. Yeah, this time it's a Base64 encoded image. Vite does this automatically for us.
for any image that's under 4 kilobytes, or any other size that we choose to configure it for, and we'll see how to configure that in a later lesson. What this does, though, is save our application from making round trips to the server for data that could be downloaded alongside the rest of the page. It's just one more way that Vite makes things fast. Not just for us, the dev, but for our end users as well.