Tree Shake Your React Application Modules

Tyler Clark
InstructorTyler Clark
Share this video with your friends

Social Share Links

Send Tweet
Published 3 years ago
Updated 2 years ago

Sometimes one line of code can eliminate 50% of your bundle size. As you'll see in this video, we can remove "dead code" from modules we are working with by correctly tree shaking.

Tree shaking is a term commonly used in the JavaScript context for dead-code elimination. It relies on the static structure of ES2015 module syntax, i.e. import and export.

Instructor: [0:00] The easiest way to decrease load time in a browser is to simply use less code. This sounds like a silly statement. Of course, less code will be faster, but how do we do that without sacrificing any features into our application?

[0:12] In this example here, I'm simply using debounce from Lodash. This is a very common practice, no harm here. Lodash is very popular and does a lot of utility functions for us.

[0:24] To get an idea of how big our application is as is, we're going to run a build. This is using WebPack behind the scenes, and building all of our files together to create some gzip files for us. If we look at the file sizes after gzip, you can see that we're at a 565 number for this chunk file.

[0:45] Relatively speaking, that's not a very large application. It should be fine on most browsers and mobile devices. However, by simply making one tweak to our application, instead of doing debounce as a named import from Lodash, what if we imported it a different way by saying debounce from 'lodash/debounce.'

[1:10] Now with this, we're going to get the exact same functionality. A debounce() function is going to do the same for our MousePosition hook. If we go back to our terminal and rerun this build, remembering that our previous size is 565, you'll notice that we're down almost 90 kilobytes on our static file here after gzipping.

[1:33] By simply changing one line of code, how we use this Lodash function in front here, inside of our application, by simply changing this one line, we are down almost 90 kilobytes. The best part again, is that we are not losing any functionality. This still works the same.

[1:51] How does this happen? This is called tree shaking, as we can see from the WebPack docs here. Tree shaking is just a term that's used in JavaScript for dead code elimination. Before with the larger bundle size file that we're working with, we're importing the entire Lodash library, when we only care to use the debounce() function from that library.

[2:13] Now, bundlers, like WebPack, Parcel, and many others, they have their own implementations and how they try to help you tree shake modules. Links to these can be found in the video notes below so you can find your direct implementation.

[2:26] Now, you might be thinking, how do you make sure you do this on all of your modules in your React app today? The answer to this is, it depends. There are some things that you can do on your part, like you saw in the video with Lodash, but there are some things that you need to rely on the modules to do themselves.

[2:43] As for what we can control for the WebPack example, we need to make sure we're using the ES2015 modules syntax, import and export, which will help with static analysis of JavaScript files.

[2:55] This basically means that at compile time, the compiler or WebPack here can determine imports and exports and programmatically decide which code should be executed as opposed to CommonJS and AMD modules, which are both analyzed dynamically.

[3:11] Add a side effects property to our package.json file, since we are using WebPack. We'll do that in a second. Then make sure when we build, we are using the production mode which we were in the previous terminal example. That includes minification and tree shaking.

[3:27] Let's go ahead and add this WebPack specific property of side effects to our package.json file. Inside of my package.json file, let's just add side effects as false. You can optionally also pass it an array of modules here that do have side effects to let WebPack know.

[3:49] Again, it just looks something like this. Side effects occur inside of our modules when a function or expression modify state outside of its own context. Some examples of side effects would be making a call to an API. A quick recap on what we talked about here.

[4:07] There's three main things that you need to do inside of your application to get tree shaking to work. You need to make sure you're working with import and export, and utilize and look into your packages to see what context you need to import and export them in.

[4:20] You need to make sure you configure whatever bundler you're using to ignore transpiling modules to CommonJS. Then here for our WebPack example, we needed to add this side effects option in our package.json file.

egghead
egghead
~ 10 minutes ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today