00:02
- So up till now, we've kind of just been ignoring the @byte declaration that we've seen within our home and our movie show page. So let's take some time to actually figure out
00:12
what exactly that's doing. So if we dive into either our home page or our movie show page, we'll see this @byte declaration within the head of our HTML document. And we can see that it's pointing to a path,
00:21
resources.js, app.js. If we actually try to find that path, so resources.js, open that up, there is an app.js file. Let's take a look at that.
00:30
And we see an import for CSS, app.css. The dot dot slash means that it's going back directory. So we're going out of the JS directory,
00:38
over into CSS, into there, and looking for a file named app.css. So let's go and give that an open as well. We see some basic styling going on within this document. Let's add a style of our own
00:48
to see if this is actually working. So we'll come into here and let's add one for our h1 because we have one of those on each one of our pages so far. And let's just set this h1's color to red. It'll make it nice and obvious
00:58
that a change actually occurred. So let's give this a save, and we can jump back into our browser. And sure enough, we can see our text turned red. So, so far it seems like everything's rigged together. We have our CSS file being imported
01:07
within our JavaScript file, and we're informing Byte about our JavaScript file within our HTML documents. Furthermore, if we go ahead and right-click our page here, go down to inspect,
01:16
let's jump into our network tab, give the page a refresh so that we get some network requests going on here, and let's dive into the request for our document page. Particularly, let's take a look at that raw response once more.
01:25
Within the head of this raw response, we see two additional scripts. We have a script for byte client, and we have a script for our app.js file
01:33
that we're specifying to that particular byte declaration within our pages right here. Well, the reason that there's two here is because much like our AdonisJS server,
01:42
our assets actually have a server of their own that's run by Byte. Byte's communicating with that server via their byte client here, which allows it to use something called
01:49
hot module reloading to interject any changes that it recognizes directly into our document. For example, if we open our text editor backup on top of our browser,
01:59
so that we can still kind of see that red text there in the background, let's jump back into our app.css file and change the color from red to blue. We can give this a save, and when we do,
02:08
we'll see that's immediately reflected within our browser, and the browser doesn't even need to refresh to pick that up. In fact, if we take a look at our network requests, we'll see an additional request for app.css
02:17
with a brand new timestamp that was initiated by a client script. This client script is Byte's client script. The Byte asset server picked up that we made a change
02:25
within one of our asset files. It informed its script about that change, which then reloaded the file with a brand new timestamp inside of our active document.
02:34
Okay, let's go ahead and hide our browser back away, and let's dive back into our homepage. So this @byte declaration isn't the initiator point for our resources.
02:42
Instead, that's within Byte's own configuration file. So if we scroll down within our project structure, we'll see at the very bottom a byte.config.js file. Let's go ahead and open that up.
02:51
It's within this file that if we scroll up a little bit, we're using an AdonisJS package that incorporates with Byte to set up our client. Within this AdonisJS package,
02:59
we're informing it about our entry points. In particular, our current entry point is resources.js/app.js. And since our app.js file is also importing our CSS file,
03:09
it's including that within the changes as well. Now it's at this point you might be wondering why exactly is the CSS file being imported inside of our JavaScript? Well, during development, it doesn't really matter
03:18
because Byte's still gonna render everything out a-okay anyway. And whenever we build for production, it doesn't really matter because Byte's gonna split the two apart
03:26
into a separate CSS and JavaScript file. So the fact that our CSS file is being imported directly inside of our JavaScript file doesn't really matter.
03:34
But if it does bother you, you can split them apart. So let's go ahead and comment out our app.css import, give this a save. And now we need to inform Byte about it via an entry point.
03:43
So we'll scroll back down to our byte.config.js file and let's add that CSS file as an entry point here. So it's gonna be resources.css.app.css. We can give this a save.
03:52
And now we need to inform our page about that additional resource. So we'll dive into our home.edge page and we just need to add it to the array here as well.
03:59
So resources.css.app.css. We'll only make this change on our home page so that we can see that it's actually doing something whenever we jump between our home and our movie show page.
04:09
So let's go and give this a save. We can jump back into our browser. Everything looks a-okay. We saw a domino refresh, but we'll do a sanity check here to refresh ourselves. And indeed, we still have our blue text here.
04:19
However, if we jump into our movie show page via one of our two movie links, so we'll go and give that a click, you'll see our H1's not blue. Furthermore, if we dive down into our network requests,
04:27
we don't see our app.css anywhere within here. Whereas if we jump back into our home page, we have both an app.js and an app.css request. So if you want your CSS and JavaScript files
04:37
completely separated during development, you can absolutely do that. However, the way that it's set up by default works a-okay because at the end of the day, whenever we actually build out our production files,
04:46
it will result in both a CSS and JavaScript file. So we can go ahead and hide our browser by the way, and I'm just gonna undo the change that we did here, splitting them apart so that we can set it back to how it was by default.
04:56
Jump back down to our Vite config. We'll undo this change here. And then lastly, we'll jump into our app.js file and uncomment this. We can give it a save. And now if we jump back into our browser,
05:04
our H1 within our home page is still blue, and we can verify that this is now on our movie show page by jumping into one of those two links. And whenever it comes to that production build where we have our separate files split out
05:13
into individual files and bundles, that's where Vite's going to use a manifest file to keep track of which particular files ended up going out into which individual bundles. So within our project,
05:23
it's gonna house that manifest file within our public directory. If we dive into here right now, it'll be within the assets file. Currently we see a hot.json file. This is what Vite will use during development
05:32
to keep track of what server our resources are being served up on. So if you happen to notice within the network panel in our browser, it's not actually making the path to our resources
05:42
to the same URL that we're using for our .js server. That's because it's using that separate asset server that we talked about earlier to serve up and watch our asset files.
05:51
So it's just keeping track of what server it's running on within this hot.json file. But whenever we actually build out for production, that's where this will be an actual manifest file, keeping track of the different files
06:01
that we have within our final bundles. And we'll use those along with a version hash in place of the actual modules that we see right here for our scripts.
06:09
Vite will then use that manifest file to track back which individual bundles we need within our page by tracking it back to the paths that we provide within the resource array for the Vite declaration here.
06:19
And at the end of the day, you're really not gonna need to worry about any of that because all that you need to do is point Vite to the uncompiled asset version within your project structure, and it will map everything to the final files
06:28
that it needs to serve for your application. And it will do all that automatically for you based off of what you provide the Vite declaration and your entry points within your viteconfig.js file.
