This lesson is for PRO members.

Unlock this lesson NOW!
Already subscribed? sign in

Maintain sane file sizes with webpack code splitting

2:38 Tools lesson by

As a Single Page Application grows in size, the size of the payload can become a real problem for performance. In this lesson, learn how to leverage code splitting to easily implement lazy loading for your application to load only the code necessary for a particular feature or functionality.

Get the Code Now
click to level up

egghead.io comment guidelines

Avatar
egghead.io

As a Single Page Application grows in size, the size of the payload can become a real problem for performance. In this lesson, learn how to leverage code splitting to easily implement lazy loading for your application to load only the code necessary for a particular feature or functionality.

Avatar
Peng

What is the editor's name that you are using in this video?

Avatar
Kent C.

It's called Atom. Here are the plugins I use: https://github.com/kentcdodds/ama/issues/113

In reply to Peng
Avatar
Dan Hayden

When using System.import webpack creates the correct bundles however when it attempts to load the bundle in the browser it tries to load it from the root directory and not the webpack output directory.
Has anyone else had this problem or know how to fix it?
Thanks

Avatar
Kent C.

You probably need to set the output.publicPath.

In reply to Dan Hayden
Avatar
Dan Hayden

That worked! Thank you so much Kent 👍

In reply to Kent C.
Avatar
Andrejb

Thank you very much for this highly professional lessons! Your explanations are best on the planet, happy to extend the skills by this!

Avatar
Kent C.

That's super nice of you to say! Thank you! I'm glad it's helpful!

In reply to Andrejb
Avatar
Maxime

System import has already been deprecated...

https://webpack.js.org/guides/migrating/
"(Note on the deprecated System.import: webpack's use of System.import didn't fit the proposed spec, so it was deprecated in v2.1.0-beta.28 in favor of import())"

Avatar
Kent C.

Yep, thanks for adding that comment. Maybe eventually I'll get around to updating these. Luckily it's a pretty quick and simple change for people to make. Thanks!

In reply to Maxime

We've added a list of animals to our app. Click on each one, and it shows us an interesting fact about that animal. Click outside of the animals, and we'll get a default message. These facts come in individual files, but they're all loaded into the bundle with this import statement.

For the purposes of our example, let's imagine that we have thousands of these. We prefer to load these on demand, rather than have them included in the bundle.

We'll start off by getting rid of this import statement, and then, we'll go down here. Instead of setting the inner text right there, we're going to use the ES6 system api to import this module.

This will return us a promise. We'll add a function called a "setFactText" that will take the result of this module import, and set the FactText for us. Now, we don't have the dynamic facts implemented yet, but let's go ahead and take a look at what this looks like in the browser now.

If we refresh the page, we'll see that we're loading the bundle. If I load the default message, then, we see this 1.bundle.js which is loaded. That is the module that we just imported using the system api. Webpack has a runtime for us, so we don't have to worry about loading that ourselves.

If we try to load the other ones, we're going to get an error in here, Facts is not defined. Let's go ahead and dynamically load the animal Facts. To load these, we could have a big switch statement, or if statement of some kind to check what the Fact is that we're looking for, and system importing that one.

That would be really tedious, and not scale very well to our thousands of Facts that we're going to be adding to this application. Instead, Webpack is intelligent and will create a bundle for us for every possible combination or dynamic import like so.

Let's go ahead and look at the browser now. As we click around, we'll see that the different bundles created for each one of this is loaded dynamically on the fly as needed. Let's go ahead and take a look at the output bundle. We open up our terminal here, we run npm.run build, and then, we go to our isDirectory.

We'll see there's a bundle for each one of these dynamic modules. We open up one bundle, we'll see the bundle for the default Fact, we open up 2.bundle we'll see the ostrich Fact, and so on and so forth.

Webpack creates these dynamically, and we don't have to concern ourselves with them at all. We only have to make these available to Webpack, at the time our application starts running.

While this scenario is a bit contrived, the basic concept is extremely practical and powerful. For example, here is some code that we could write to lazy load parts of React application using React Router, and Webpack's code splitting. It's using the same system api, and Webpack is able to load entire sections of the application as needed.

That's how you use code splitting with Webpack.

HEY, QUICK QUESTION!
Joel's Head
Why are we asking?