When running the application using npm start the images are not rendered and the browser renders the “broken image” icon instead. I’ve checked that the images are present in the images folder (which they are). Do I need to change something in webpack or is it just a case of overlooking something so simple I should be embarrassed of myself?
The second problem is about running the application in IIS when useUrlFragmentHash is set to false. I’ve created a new site in IIS which refers to the application’s dist directory and when clicking Browse in IIS the application starts without a hitch. However, when I refresh the browser window or open the URL in another browser IIS responds with a 404. When useUrlFragmentHash is set to true the problem seems non-existent. I apologize if this is another case of me embarrassing myself, but I hope someone in the community can help with these two issues.
@elitastic Thx for your reply. I was hoping to avoid using a function as this was supposed to be a vm-less view, but if it fixes the issue I’ll add a vm.
Funny thing is, referring to the image source in html works in an Auralia 1 application we’ve got, i.e.
In Aurelia 1, html remains html, it’s processed by “html-loader” in your webpack config.
In Aurelia 2, html is compiled to JavaScript, processed by “@aurelia/webpack-loader” in webpack config. We have trouble to chain html-loader and our loader together (html-loader would do the img.src preprocess) because html-loader output format is not friendly.
Install the plugin and add something like this into the the webpack config file.
plugins: [
...,
new CopyPlugin({
patterns: [
{ from: 'static', to: '' }
]
})
]
This would assume that in the root of your project you have a folder called static.
So if you have an image in the static folder, e.g. static/logo.png in your html, you could display it like this:
<img src="./logo.png" ...>
Regarding useUrlFragmentHash: false. It might be that it uses PushState routing?
From the docs
PushState requires server-side support. This configuration is different depending on your server setup. For example, if you are using Webpack DevServer, you’ll want to set the devServer.historyApiFallback option to true. If you are using ASP.NET Core, you’ll want to call routes.MapSpaFallbackRoute in your startup code. See your preferred server technology’s documentation for more information on how to allow 404s to be handled on the client with push state.