We have a service worker that pre-caches a dynamic set of URLs, and that's fantastic, but there's an issue with development assets. Let's investigate. The issue that we are encountering is if we are in offline mode and we are also using the VEET development server, our offline page is not showing, you know, well, it's showing the offline page, but it's not styled the way that it needs to be styled. So that means, of course, that the CSS is not being loaded. And by looking at the network tab, we can definitely see that it failed. Now, if we take a look at our cache, we will see that the app CSS file is being cached as well as app.js. It's not JSON. So those files are being cached, but they aren't being applied here with our offline page. And this is a problem of, well, because of me. So let's take a look at our fetch event listener. So of course, here, if it is a navigation, then we, of course, make the request.

our offline page. And this is a problem of, well, because of me. So let's take a look at our fetch event listener. So of course, here, if it is a navigation, then we, of course, make the request. Otherwise, we show the offline, and that's where we currently are. But let's move on down past that because we need to focus on static assets because a CSS file is a static asset. And if we take a look at this check, if the origin of the request is the same as the service worker, and if it is a static asset, then, you know, we want to, you know, essentially cache it and use it. That's the first problem because remember that I'm using the Vite development server. Well, we all are using the Vite development server, and that has a different origin because there is a port with the Vite development server. So this, of course, is going to fail because there are two different origins. So we could do this a little smarter by checking if the request

port with the Vite development server. So this, of course, is going to fail because there are two different origins. So we could do this a little smarter by checking if the request URL starts with the origin of the service worker. Because at least in my case, since I'm using herd, my URL is HTTPS field-logger.test. And the Vite development server has that same host, but it has a port. So as long as the request has this same origin, or at least if it starts with the same origin, then everything should work as far as loading the assets from the Vite development server. So that's the first issue, and that's going to be fine there. The second issue is just this right here, is static assets. And I'm pretty sure that you are screaming at me through the screen, and unfortunately, I couldn't hear you. But what we had before resembles nothing like what we needed. We needed some logical ORs here. So if the path starts with build, or if it ends

screen, and unfortunately, I couldn't hear you. But what we had before resembles nothing like what we needed. We needed some logical ORs here. So if the path starts with build, or if it ends with CSS, or if it ends with JS, so on, then it's a static asset. We want to work with that. So those were two distinct problems with the service worker that would hopefully fix this particular problem. So let's go into offline mode. Let's unregister this. Let's also clear out all the errors, and let's do a hard refresh. So now we can see that the service worker is loaded. We don't have any errors, and we are seeing our page because we are in online mode. We now have a connection. So let's go back to our meter list. The style isn't being applied here. We can refresh. Same thing. We can do a hard refresh, and then we can see, of course, we have our styling. But if we go to any other page, once again, the CSS isn't being loaded. So there's another issue,

Same thing. We can do a hard refresh, and then we can see, of course, we have our styling. But if we go to any other page, once again, the CSS isn't being loaded. So there's another issue, and this one is a little harder to find. I mean, the first issue was, of course, me being stupid. This particular issue isn't clear because, once again, if we take a look at our cache, our assets are being cached. In fact, we have more assets now because now that we are successfully caching things from the Vite development server, we have node modules. Well, it's Axios, so we have that. We have app.css, app.js, and now we have bootstrap.js as well. So we are successfully caching things from the Vite development server, but we aren't seeing the CSS. And once again, we are in online mode. We are not in offline. So what's the problem? Let's do this. If we go offline, and if we go back, of course, well, we see we're offline,

the CSS. And once again, we are in online mode. We are not in offline. So what's the problem? Let's do this. If we go offline, and if we go back, of course, well, we see we're offline, but there's no styling. So again, it's a styling issue, or at least it's an issue that the CSS isn't being loaded. So what's the problem? So there's a couple of different ways that we could find this, but the key really is going to be not necessarily the error that's listed here, because we can see that there's some WebSocket issues, and that's because we couldn't connect to the Vite development server. So that really isn't going to help us. What can help us, however, is the network tab. So let's go to the network tab. And here we are loading just meters. Once again, we are online. We have a connection. So if we refresh this, and if we take a look, everything is a 200, nothing was missed. But here we can see app.css. Here it is, 200,

again, we are online. We have a connection. So if we refresh this, and if we take a look, everything is a 200, nothing was missed. But here we can see app.css. Here it is, 200, style sheet, and it was handled by the service worker. So we are successfully loading that from the service worker. But let's inspect that request. We don't really care about the headers, but look at the preview. Look at the response. What is this? This is JavaScript. This is not CSS. So we are essentially, yes, we are caching the CSS, but it's really we are caching the hot reload. That's not what we want. We want the actual CSS here. So this is an issue. Now, if we hard refresh, we are going to see different results because now we can see that app.css is pulled successfully with a 200. It is not coming from the service worker. We are pulling this from the server. So if we inspect this request, we can see now we have the CSS. So if we are pre-caching our CSS

with a 200. It is not coming from the service worker. We are pulling this from the server. So if we inspect this request, we can see now we have the CSS. So if we are pre-caching our CSS from the Vite development server, then we aren't actually caching the CSS. We are caching the hot reload. Now, there's another way that we could find this out, and it involves just running some code inside of the console. But this is code that is essentially going to go into our cache. It's going to find where we have app.css cached, and then it's going to give us some information such as the type of request, as well as the content type. So we can see that the type is cores, and that's perfectly fine. The status is 200, which is fine. But notice the content type, text slash JavaScript. So what is being stored in the cache is JavaScript, meaning that it's part of that pre-cache thing. So whenever we are pre-caching it, it's before we have actual CSS

text slash JavaScript. So what is being stored in the cache is JavaScript, meaning that it's part of that pre-cache thing. So whenever we are pre-caching it, it's before we have actual CSS to cache. So what's the solution there? Well, I mean, what we could do is open up our pre-cache manifest controller, and we could just not cache the CSS. Well, it's the CSS there. Okay. We could just not cache the CSS, and that would be okay, except that, yes, we do want to cache that eventually, in which case we need to do something inside of our service worker. So here, where we are dealing with static assets, and in particular right here, if the response is okay, if the type is basic or if it's cores, then we want to cache it here. Now, we're going to run into a couple of issues here, because while the file that we actually cached does have a type of cores, does have a status of 200, which is okay, this isn't going to be what we actually get when

into a couple of issues here, because while the file that we actually cached does have a type of cores, does have a status of 200, which is okay, this isn't going to be what we actually get when it comes to the actual CSS. The type is going to be different. It's going to be called opaque, which means that when it comes to our if statement, we're going to need to do something a little bit different. But I think if we just keep this simple so that we will, first of all, check if the response is okay, if it's basic, if it's cores, then great. Or if the request URL ends with app.css, then we want to cache that request, which means that back inside of the browser, we can go to the application tab. Let's unregister our service worker so that we can do a hard refresh. So now, after refreshing the page, and we can see that there's no errors here. And notice that our cache, remember in the previous episode, I said that the developer tools, as far as the cache storage

after refreshing the page, and we can see that there's no errors here. And notice that our cache, remember in the previous episode, I said that the developer tools, as far as the cache storage is concerned, is a little wonky. Yeah, and the reason why I know that is because we can go to the console and we can write code to clear all of the cache. And it would still appear here. So we don't need to worry so much about what's listed here as far as the cache storage is concerned. What does matter is, you know, is this going to work like it should? And sure enough, the CSS is being loaded as it needs to be. But most importantly, well, I don't know if it's most importantly, because really it's more important that it work online like it should. But if we go offline, and if we attempt to go anywhere else, then we are shown the offline page, the styling is correct, and everything is good to go. So when you are working with service workers,

go offline, and if we attempt to go anywhere else, then we are shown the offline page, the styling is correct, and everything is good to go. So when you are working with service workers, and you are inside of a VEET environment, you know, you can run into some issues. And it could be issues that really aren't your fault. And if you're fine with just ignoring those issues, then you know, more power to you. I'm not. I want to find why something works or why something doesn't work. But one of the most helpful utilities that you can have is the Network tab, because it will show you where resources are currently being loaded from. And that can give you an idea as to why something, especially caching, doesn't work the way that you expect it to.