Dynamic Import & Code Splitting

Steve Kinney

Steve Kinney


Check out a free preview of the full Vite course

The "Dynamic Import & Code Splitting" Lesson is part of the full, Vite course featured in this preview video. Here's what you'd learn in this lesson:

Steve explains how to split an application into multiple chunks using ECMAScript modules. They demonstrate two ways to import files: one that immediately imports the file and one that returns a promise and dynamically fetches the module when the import statement is called. They also discuss the use of Vite Preview, a tool that spins up a web server to test the built production assets and verify the build process.


Transcript from the "Dynamic Import & Code Splitting" Lesson

>> Well, if I did wanna split this application into multiple chunks, how would I do that, right? And one way that we could do that is, there's two ways to import files with ECMAScript modules. One is this kind of statement that we have up here, which is import, this is at the top of the file, it means immediately, right?

We know that we need this file and we will have it, right? If you've got a client-side router or maybe it's like, hey, I don't need all the assets for this modal or something like that until maybe they hover over the button, right, or something along those lines.

Then you could choose to do something along those lines as well and asynchronously load something, and let's look at how that works. And so, all right, if I got rid of this statement for a second, and instead, we'll get rid all this right now, we'll say import and we'll do ./counter.

That's good enough for now. What this version of import with ECMAScript modules does is it returns a promise, right? So, if you've got top level async await, you can wait it, otherwise it's just a promise, at which point it will now, when it hits this code, and again, you could say like, hey, until they hover over the button, that's gonna have the modal.

Or if I have a client-side router, when they go to the next client-side route, that's when, if you use something like React router, or svelte kit, or most like single page app frameworks, like Next, for instance, this is happening for you with the framework by virtue of the routes.

So you, generally speaking, if you're using any of those frameworks, don't think too much about this, but this is effectively what's happening. It's a promise, literally, and then we get the stuff in the file as kind of the return value of that promise. So we'll go and dynamically fetch that module whenever this import statement is called, instead of immediately as soon as the file is loaded.

And we can kinda see, if we go ahead and build it again. If you look right now I've got just my HTML file. And let's see if I can, yeah. And I've got the JavaScript file. Now if you look, because I'm dynamically importing it, and there's probably an action that would happen, either client-side route changing, whatever action would trigger the very next thing.

You can see that we actually spit out two different files now, right? So it knew, I don't need everything all at once. Awesome, go wait until we get the thing and then load the second piece, so you can begin to split stuff up. So this could be, again, if you have client-side routes or if it's a situation.

I work on an app where generally speaking, we get really frustrated if a content side takes too long to load, but we do watch a loading bar in Gmail, right? And so there's always those trade offs. I don't have a lot to show until the JavaScript has loaded in my app.

But if I was running like the New York Times or something like that, it could be that, all right, go run the initial JavaScript. And then these will be asynchronous after the initial JavaScript file is parsed, and it'll immediately go get the next thing and start loading it, right?

A lot of times, content sites will try to show you the content as fast as possible, and then they'll load up all the ads that take forever to load, right? So they are already reading that point by the time they slide all the ads in there, right? So this technique would work for that where we would load the initial file and then we would go ahead and import the counter as well.

And you can see that now I've broken this up into two chunks, that it has already figured this out for me and done everything, and I don't think a lot about it. The other thing that we can do is, right now you saw that I have a development server.

The other thing you might wanna do as you're building and testing stuff out to make sure everything's behaving the way you want is Vite has this other one called MPX or just really Vite preview. And what Vite preview does is it takes the built assets, vite. The nice part is there's smiles and giggling when I say vite, so it's gonna be great, [LAUGH].

I thought I'd make it a lot longer before the first time I slipped, but apparently not. Vite preview will look at your built assets and spin up a web server around that, so you actually see, okay, these are the built production assets. Does this behave the way I think it's supposed to?

And this application is simple enough that other than it being 4173, we can go ahead and see that's mostly the same idea, made sure my counter works, so on and so forth, right? And so that's actually the production build. If I look in the elements, you'll see that this is now the production build.

And I can actually play around with that as well. Now, again, most of the time in my experience, they are similar, but if there are transformations that you're only doing at build time, right, which is what some will see at the very end. Then this is useful to seeing like, okay, did my build part work the same way as it does in development?

Cuz we know that we don't have to think about it, but Vite is using a different technology for the development server to give us that fastest feedback loop possible. Than it is as it's kinda doing the tree shaking and code splitting, and everything along those lines for the production belts.

So it's mostly, if there's something special about your build process, you won't be able to verify or if you're debugging, then the Vite preview is super useful. But generally speaking, in my experience, which is, yes, a few years, but all on just the apps that I work on every day.

Generally speaking, the development server works really great, and we can rely on that most of the time for most things.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now