Course Introduction: React Optimization Cookbook

Debounce Callbacks on DOM events in React Apps

Use the React Production Build

Virtualize Long Lists of Data in React

Tree Shake Your React Application Modules

View Package Sizes in a React App with Webpack Analyzer

Containerization of State within Child React Components

Profile React Components with the Devtools Profiler

Optimize Function Components with React.memo

Memoized Values with React useMemo

Memoize a Function with useCallback in React

Add the why-did-you-render Package to Catch Unnecessary Updates in React

Code Split Components with React Lazy & Loadable Components

React Optimization Cookbook

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.

https://app.egghead.io/api/v1/lessons/react-tree-shake-your-react-application-modules/subtitles

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.

Tree Shake Your React Application Modules

Share this video with your friends

Course

React Optimization Cookbook