Forem: Ion Bragaru

React Performance: Boost it with Tree Shaking

Ion Bragaru — Thu, 12 Dec 2024 07:42:47 +0000

Tree shaking is an essential technique in modern JavaScript development, especially for libraries like React. It helps eliminate unused code from the final bundle, resulting in smaller file sizes and faster application performance.

or as MDN says

Tree shaking is a term commonly used within a JavaScript context to describe the removal of dead code.

What is Tree Shaking?

Tree shaking is a term used in JavaScript bundlers (like Webpack and Rollup) to describe the process of removing unused code from your final JavaScript bundle. It works by analyzing the import/export statements in your codebase, figuring out which parts of your code are actually being used, and eliminating everything else.

The name "tree shaking" comes from the analogy of shaking a tree and letting the unused branches (code) fall off, leaving only the necessary parts in your final build.

Why Should React Developers Care About Tree Shaking?

As a React developer, reducing the size of your JavaScript bundles can have a significant impact on the performance of your application. Large bundles lead to slow load times and a poor user experience, especially on mobile networks. Tree shaking helps ensure that only the code you actually use is included in your final build, which can dramatically improve performance.

How Does Tree Shaking Work in React?

Tree shaking relies heavily on ES Modules (ESM). When you import and export modules using ESM syntax, bundlers like Webpack and Rollup can analyze your code and remove unused exports.

For example, let’s say you're using a large utility library, but you only need one function:

// Bad practice: importing everything
import * as lodash from 'lodash';

In this case, even if you're only using one function, the entire lodash library will be bundled. This is inefficient and increases your app size.

Instead, you can use named imports:

// Good practice: importing only what you need
import { debounce } from 'lodash';

This way, only the debounce function is included in your bundle, and the rest of the lodash code is excluded, making your app much smaller.

Best Practices for Enabling Tree Shaking in React:

1. Use ES Modules (ESM):

Tree shaking works best when your code and the libraries you use are written in ESM. Avoid CommonJS if possible, as it doesn't support tree shaking.

2. Import Only What You Need:

As shown above, always use named imports or import specific functions instead of the entire library.

3. Eliminate Side Effects:

Tree shaking relies on the assumption that importing a module doesn’t have side effects. A "side effect" could be anything that changes global state, modifies variables, or executes code outside of the module itself. Ensure your modules don’t have unintended side effects that could prevent tree shaking from working.

4. Configure Your Bundler:

Ensure that your bundler (like Webpack or Rollup) is properly configured for tree shaking. This often includes enabling production mode to enable optimizations.

5. Leverage `package.json` "sideEffects" Field:

If you are working with a library, or even your own project, make sure to mark files that have side effects in your package.json. This helps the bundler understand what can be safely tree-shaken.

Example:

"sideEffects": [
  "*.css",
  "*.scss"
]

Tools to Analyze and Test Tree Shaking:

Webpack Bundle Analyzer: This tool helps you visualize the contents of your bundle and see if any unused code is still being included.
Source Maps: Use source maps to trace what’s being included in the final bundle.

Thoughts to take:

Tree shaking is an essential optimization technique for React (and not only) developers who want to build efficient and fast applications. By following best practices such as using ES Modules, importing only necessary code, and ensuring modules are side-effect-free, you can take full advantage of tree shaking and significantly improve the performance of your React apps.

If you’re looking to improve your app's performance, implementing tree shaking is a great place to start!

External libraries: The Hidden Weight of External Libraries

Ion Bragaru — Wed, 11 Dec 2024 10:17:31 +0000

As developers, we often rely on external hook libraries to save time, leverage well-tested solutions, and focus on the bigger picture of our projects. However, it’s crucial to consider the impact these libraries have on your bundle size—a key factor in your app’s performance and loading speed. Let’s explore how these libraries impact bundle size, how to check if tree-shaking is supported, and how to make informed decisions.

Why Bundle Size Matters

User Experience: Larger bundles take longer to download, parse, and execute, especially on slower networks or devices.
SEO and Performance Scores: Tools like Google Lighthouse penalize heavy bundles, impacting your search rankings.
Long-Term Maintenance: Larger bundles can obscure performance bottlenecks as your project grows.

External Hook Libraries: Convenience vs. Cost

Hook libraries are a common solution for handling complex state or reusable patterns, but their bundle cost depends on their structure:

Granular (Modular)

Install only the hooks you need, keeping dependencies minimal.
Example:

  import { useDebounce } from "hook-lib/useDebounce";

Monolithic (Tree-Shakable)

Install one library, but ensure your build tool removes unused exports.
Example:

  import { useDebounce } from "hook-lib";

Each approach has trade-offs. Granular libraries offer precise control over what’s added, while monolithic libraries are easier to manage but require proper tree-shaking to avoid bloat.

How Much Weight Do Hook Libraries Add?

The weight depends on:

Library Size: Some libraries are lightweight (a few KB), while others can balloon to dozens of KB if they rely on dependencies.
Tree-Shaking Effectiveness: If the library doesn’t support tree-shaking, you might import unused code.
Usage: Importing a single hook might pull in shared utilities or polyfills, inflating the size.

Example Scenario:

A lightweight library (use-fetch-hook) adds 5KB.
A large, monolithic library with poor tree-shaking might add 30KB+, even if you only use one hook.

How to Check if a Library Supports Tree-Shaking

To check if a library supports tree-shaking, you can follow several approaches based on understanding its code structure and how it's bundled. Tree-shaking is a feature supported by modern JavaScript bundlers like Webpack and Rollup, which removes unused code during the build process. Here’s how you can determine if a library supports it:

1. Check the Library’s Package Documentation

Look for ES Module (ESM) Support: For tree-shaking to work, the library must use ES Modules (ESM). ESM allows the bundler to analyze the import/export structure and safely eliminate unused code.
- Check if the library provides an ESM build (often specified in the module or exports field of its package.json).
- Search the documentation or repository to see if ESM is mentioned as the preferred usage.

2. Check the `package.json` of the Library

Exports Field: For more recent packages, check if the exports field is used. This can specify different entry points for different environments (like CommonJS or ESM), improving tree-shaking support.
Module Field: Look at the package.json file of the library. If it includes a module field that points to an ESM build, it indicates the library is compatible with tree-shaking. Example:

{
  "module": "dist/library.esm.js",
  "main": "dist/library.cjs.js"
}

module points to the ESM version, which is tree-shakable.
main typically points to the CommonJS version, which isn’t ideal for tree-shaking.

3.Check the Library’s Source Code

Use of import/export: Ensure that the library uses ES module syntax (e.g., import and export). Tree-shaking works best with this syntax.
- If the library uses CommonJS (require, module.exports), tree-shaking won’t be as effective.
No Side Effects: Libraries that support tree-shaking typically avoid side effects in their code. Check the library’s source code to ensure that functions or modules don’t perform actions when they are imported. For example, importing a module should not alter global state.

4. Use a Bundler to Test Tree-Shaking

You can use a modern JavaScript bundler (like Webpack or Rollup) to test if tree-shaking works. Here's a simple test:
- Create a minimal project with the library installed.
- Import only a part of the library in your code (e.g., a single function).
- Run the bundler and check the output:
- a) If the unused code is excluded from the final bundle, the library supports tree-shaking.
- b) If the unused code is still included, then the library either doesn’t support tree-shaking or requires further configuration (like marking certain code as side-effect-free).

5. Use a Bundle Analyzer

Use tools like Webpack Bundle Analyzer or Rollup's built-in analyzer to visualize the final bundle.

Look for the size of the library in the output. If tree-shaking works, unused code should be excluded, and the final size should be smaller.

6. Check the Community and Issues

Look at issues or discussions in the library’s repository (e.g., GitHub) to see if there are any mentions of tree-shaking or issues related to it. The maintainers may also provide guidance on enabling tree-shaking.

7. Look for Specific Build Instructions

Some libraries might have specific instructions for enabling tree-shaking, especially when they are not entirely tree-shakable by default. Check for any guidance on how to configure the bundler for optimal tree-shaking.

Example:

If you are using a library like Lodash, it has specific "modular" imports:

import { debounce } from 'lodash';

This allows bundlers like Webpack to shake off unused methods when using Lodash's modular imports, as opposed to importing the entire library (import _ from 'lodash'), which would include the entire codebase and prevent tree-shaking.

Create animations like PowerPoint slides in React with framer-motion and react-intersection-observe

Ion Bragaru — Wed, 26 May 2021 09:11:09 +0000

Well, I’m a little bit far from use of animation libraries and kind of, but at my last project we had such a request:

Clients want a webpage that will have similar effects as a presentation in PowerPoint. On mousewheel we change our slides (previous and next)

This PowerPoint effects should be available only on a desktop view (viewport 1200px and up). But for 1200px and down we must have a normal scrollable page.

Time resource — critical low(well as always because need in some days to be in a production)

Do not to waste your time, check out final codesandbox here:
***https://codesandbox.io/s/motion-framer-sample-3-l2y9x?file=/src/App.js:0-1912***

Assuming all these criterias, the only option is to use a library with a good documentation( no need to reinvent the wheel) and a ready CRA init project. After CRA install, we add these libraries:
npm i framer-motion react-intersection-observer lodash

Quick review on this libs:

Framer-Motion — actually the package that helps us to animate our react components. API here: https://www.framer.com/api/motion/
*react-intersection-observer *— react implementation of the Intersection Observer API to tell you *when an element enters or leaves the viewport *(from official description). Docs here: https://github.com/thebuilder/react-intersection-observer#readme
famous lodash **— well, we need only **debounce function . Debounce description from official docs : Creates a debounced function that delays invoking func until after wait milliseconds have elapsed since the last time the debounced function was invoked.

Now, we start to count steps:

Create Sections — Slides. Giving them a width and height of 100%, also setting them id. id must be different for all sections. our App.js look like:

styles.css looks like that:
- we reset margin and borders for all elements (margin:0; padding:0) and create sections with a width and height of 100% of container(container is 100vh and 100vw from viewport).

we create we flex center text and add some font size to text .
some color to each section individually

Each section looks like that :
nothing special, just a section tag with an ID (later we will add actions using this id! so important to each section to add a different id. ./sections/Section1.jsx (all sections contains same code)

Now, we have sections, we have our packages setted up, let’s do some coding!

Every page has 4 effects:

Animation that is played when section is on viewport( visible )
Animation that is played when user is leaving outport(hidden)
If user goes next section, we play exit animation for next section (next)
If user returns back to previous section, we play different exit animation (previous).

Well, let’s implement a custom hook that does all these. Also a file that constains all our constants ( delay! of course… we need a delay for our debounce function , that will optimize our wheel event listener)

./constants.js

*./useObserverHook.jsx
*So, what we did there:

we set by default hidden state of our animation, and if it is on viewport, with help of useInView hook we set state to **visible.

useEffect(() => {

if (inView) {

setVariant("visible");

} else setVariant("hidden");

}, [inView]);

Also we create a debounced function to trigger state change when user scrolls up or down, also we add a flag isFirst and *isLast *(well you dont need to go on previous section if you are on last section and viceversa)

const ***onMouseScroll*** = **debounce**((e) => {        
  if (e.deltaY > 0 && variant === "**visible**") 
     setVariant(isLast ? "**visible**" : "**next**")        
  if (e.deltaY < 0 && variant === "**visible**") 
     setVariant(isFirst ? "**visible**" : "**previous**")    
 }, MAIN_DELAY)

A codesandbox with sample files:

src="https://codesandbox.io/embed/motion-framer-sample-1-39iji"
style="width:100%; height:calc(300px + 8vw); border:0; border-radius: 4px; overflow:hidden;"
allow="geolocation; microphone; camera; midi; vr; accelerometer; gyroscope; payment; ambient-light-sensor; encrypted-media; usb"
loading="lazy"
sandbox="allow-modals allow-forms allow-popups allow-scripts allow-same-origin">

Now, let’s implement that hook on Sections1.jsx!

— First, we’re gonna create a *./constants.js *file and export MAIN_DELAY constant we’re we declare it to 600ms (well, this actually is debounce value for our hook — we can infinite scroll, but event will be trigerred after last “wheel” effect )

— Let’s console.log our sandbox, to be sure that we going on the right way:

— Now we have variants for triggering animation on mouse wheel , so next step we will do that. To do that we need to import motion from motion-framer and wrap our sections with motion. *Well, we got something like that:

To create these PowerPoint*ish slide effects, we need to create a separate div that will be positionated absolute on top of a section, and with different variants of animations, so we update our *./styles.css *with this block of code:

So, when user use wheel down event, we play for drawer — *drawerVar, and for section — sectionVar. *Code sandbox here:

And last small step, is just to switch our pages/slides on same mouse wheel event.
To do that we need to update our *App.jsx component (navigation — on scroll we switch out the slide and leave 0.4s to play animations for sections):

And some small updates on sections, and we get this effects :
a) for drawer — previous and next
b) for content — hidden and visible

Final results on codesandbox here:
***https://codesandbox.io/s/motion-framer-sample-3-l2y9x?file=/src/App.js:0-1912***
> Happy Coding!