Forem: Agustin Maggi

Achieving a 3x reduction in React Bundle size: A case study

Agustin Maggi — Sat, 13 Jul 2024 02:58:01 +0000

In our recent efforts to improve the performance of our frontend applications, we made significant strides by optimizing our use of our component library.
Here's how we achieved a more than 3x reduction in our bundle size, speeding up our build process and enhancing our app's runtime efficiency.

The Power of Tree Shaking

Tree shaking is a term commonly used in the JavaScript context for dead-code elimination. It relies on the static structure of ES modules, which allows unused exports to be removed during the bundling process.
Our project uses Material UI extensively, a popular React UI framework known for its comprehensive component library.
Initially, our bundle size was bloated due to importing entire libraries, even when only using specific components.

To address this, we implemented stricter import rules using ESLint to ensure that every component is imported directly from its path:

// ESLint rules for Tree Shaking
"no-restricted-imports": [
    "error",
    {
        paths: [
            {
                name: "@material-ui/icons",
                message: 'Use direct imports, e.g., Import ExampleIcon from "@material-ui/icons/Example"'
            },
            {
                name: "@material-ui/core",
                message: 'Use direct imports, e.g., Import Example from "@material-ui/core/Example"'
            },
            {
                name: "mdi-material-ui",
                message: 'Direct imports preferred, e.g., Import ExampleIcon from "mdi-material-ui/Example"'
            }
        ],
        patterns: [
            {
                message: "Use path imports instead. See https://v4.mui.com/guides/minimizing-bundle-size/#option-1",
                group: [
                    "@material-ui/*/*/*",
                    "!@material-ui/core/test-utils/*",
                    "!@material-ui/core/styles/*",
                    "!@material-ui/core/colors/*",
                    "!@material-ui/pickers/typings/*",
                ]
            }
        ]
    }
]

Thus, if we attempt to use an import like this:

import { useMediaQuery } from '@material-ui/core';

ESLint will flag an error with the message: '@material-ui/core' import is restricted from being used. Import should be formatted as follows: Import Example from "@material-ui/core/Example".
It will prompt us to correct the import as shown below:

import useMediaQuery from '@material-ui/core/useMediaQuery';

This change enforced that developers import only what they need, significantly reducing the initial load time by cutting down unnecessary code from the bundle.

Embracing Lazy Loading with @loadable/components

Lazy loading is a design pattern commonly used in web development to defer initialization of objects until the point at which they are needed.
It can significantly reduce the initial load time and positively impact performance.
We incorporated lazy loading using the @loadable/component library, which integrates seamlessly with our server-side rendering setup. Here's an example of how we used it:

import React, { Suspense } from "react";
import TextInput from "@material-ui/core/TextField";
import loadable from "@loadable/component";
const SearchSuggestion = loadable(() => import("./SearchSuggestion"));

export const SearchInput = React.forwardRef((props, ref) => {
    const { suggestions, value, onChange} = props;
    return (
        <>
            <TextInput
                ref={ref}
                value={value}
                onChange={onChange}
            />
            {suggestions.length > 0 ? (
                <Suspense>
                    <SearchSuggestion
                        items={suggestions}
                        maxSuggestions={3}
                    />
                </Suspense>
            ) : null}
        <>
    )
})

In this example we are lazy loading the suggestion items only when suggestions is greater than 1.

Using @loadable/component allowed us to split our codebase into smaller chunks that are only loaded when required.
This approach not only reduced the load time but also decreased the time-to-interactive, enhancing the user experience by not loading heavy components upfront.

This library was causing some conflicts when testing components with Jest. To address this, we created the following mock setup:

import React from "react";

export const mockLoadable = (load) => {
  let Component;
  // Capture the component from the module load function
  const loadPromise = load().then(
    (val) => (Component = val.default)
  );
  // Create a react component which renders the loaded component
  const Loadable = (props) => {
    if (!Component) {
      throw new Error(
        "Bundle split module not loaded yet, ensure you beforeAll(() => MyLazyComponent.load()) in your test, import statement: " +
          load.toString()
      );
    }
    return <Component {...props} />;
  };
  Loadable.load = () => loadPromise;
  return Loadable;
};

Then, in the component that leverages Loadable, when we needed to test it, we included at the beginning of our test files:

jest.mock('@loadable/component', () =>
  jest.requireActual('../testing/testUtilities/mockLoadable')
);

This setup ensures that the asynchronous components are properly handled in our Jest tests, providing a stable environment for unit testing.

export default mockLoadable;

Advanced Code Splitting Using Vite

To further optimize our application, we embraced advanced code splitting strategies using Vite, which allowed us to push only the necessary code to production.
This approach was critical in reducing our bundle size significantly.

Here's the Vite configuration we used to achieve this:

import { defineConfig, splitVendorChunkPlugin } from "vite";
import react from "@vitejs/plugin-react-swc";
import tsPaths from "vite-tsconfig-paths";
import { visualizer } from "rollup-plugin-visualizer";

export default defineConfig({
    server: {
        https: false,
        port: 5173,
    },
    base: "./",
    plugins: [react(), tsPaths(), visualizer(), splitVendorChunkPlugin()],
    optimizeDeps: {
        force: true,
    },
    define: { "process.env.NODE_ENV": '"production"' },
    build: {
        outDir: "./build",
        rollupOptions: {
            output: {
                manualChunks: {
                    "react-vendor": ["react", "react-dom", "react-router-dom"],
                    "react-spring-carousel": ["react-spring-carousel"],
                    "material-ui": ["@material-ui/core", "@material-ui/icons", "@material-ui/lab", "@material-ui/styles"],
                    "react-select": ["react-select"],
                },
            },
        },
    },
});

Vite's flexible configuration supports manual chunking, allowing you to experiment and understand how much space various library groups consume.

We also used rollup-plugin-visualizer to provide a visual representation of how much weight each library and dependency adds to the bundle.
This tool has been invaluable in helping us understand and optimize our dependency graph.

Results and Conclusion

By implementing these optimizations, we observed a more than 3x reduction in our overall bundle size.
Our build times improved, and our application's performance increased dramatically, especially on mobile devices where bandwidth and processing power are more limited.

Adopting tree shaking, lazy loading, and manual code splitting with Vite requires an upfront investment in configuring and enforcing best practices, but the payoff in terms of performance can be substantial.
If you're using a component library like Material UI, consider these strategies to optimize your application's bundle size and runtime efficiency.

I encourage all developers to review their import statements, consider lazy loading, and explore advanced code splitting to improve performance.
Being vigilant and proactive about performance will consistently yield positive results.

Using Google Place to build a country autocomplete

Agustin Maggi — Fri, 08 Dec 2023 01:43:52 +0000

Google Places API is a service that provides information about places and addresses. This functionality is very useful for applications requiring specific location input from users.

One missing feature in the Google Places API is the ability to search for countries. In this tutorial, we will see how to implement a country autocomplete feature using the Google Places API and the React Select library.

You can see the final result at country-autocomplete.vercel.app.

Prerequisites

Getting Started

We will begin with our class that will handle the Google Places API. This class will have all the methods that we will need to interface with the API and ultimately generate the countries list for our autocomplete dropdown.

The first method is the SearchCountry. This will receive a search string and return a list of countries matching that value. We are using the AutocompleteService from the Google Places API to get the list of matches. We limit results to 'regions' to exclude streets or cities.

SearchCountry(search: string): Promise<google.maps.places.AutocompletePrediction[] | null> {
    new Promise<google.maps.places.AutocompletePrediction[] | null>((resolve) => {
        this.autocompleteService?.getPlacePredictions({ input: search, types: ["(regions)"] }, (predictions) => {
            if (!predictions) {
              resolve(null);
            } else {
                resolve(predictions.filter((prediction) => prediction.types.includes("country")) || null);
            }
        });
    });
}

The searchPlace method utilizes the Geocoding service to retrieve additional information for a provided place ID obtained from the AutocompleteService response.

searchPlace(search: string): Promise<google.maps.GeocoderResult | null> {
  return new Promise((resolve) => {
    this.geocoder.geocode({ placeId: search }, (results, status) => {
      if (status === "OK" && results && results[0]) {
        resolve(results[0]);
      } else {
        resolve(null);
      }
    });
  });
}

Finally, we will use the getCountry method to parse the geocoder result and obtain the country code.

getCountryCode(place: google.maps.places.PlaceResult): string | false {
  const addressComponents = place.address_components || [];
  for (const component of addressComponents) {
    if (component.types.includes("country")) {
      return component.short_name || false;
    }
    if (component.types.length === 2 && component.types.includes("political")) {
      return component.short_name || false;
    }
  }
  return false;
}

Writing the Autocomplete component

Now we are ready to implement the country autocomplete component using React Select library and the Google Helper class we just created.

import GoogleHelper from "./GoogleHelper";
import AsyncSelect from "react-select/async";
import CountryAutocompleteProps from "./types";

const Google = new GoogleHelper('myKey');

export function CountryAutocomplete(props: CountryAutocompleteProps) {
  const handleCountrySelection = async (country: Option | null) => {
        if (!country) return;
    const place = await Google.searchPlace(country.value as string);
    if (!place) return;
    const countryCode = Google.getCountry(place);
    props.onSelect({ value: countryCode, label: country.label });
    };
    const handleSearchCountries = (inputValue: string) => {
        return new Promise<OptionShape[]>((resolve) => {
            Google
                .searchCountry(inputValue)
                .then((results) => {
                    return resolve(formatAutocompleteResult(results));
                })
                .catch((err) => {
                    return resolve([]);
                });
        });
  }
  return (
    <AsyncSelect
      value={props.value}
      noOptionsMessage={(i) => (!i.inputValue ? "Type to search for a country" : "No results found")}
      placeholder="Type to search for a country"
      loadOptions={handleSearchCountries}
      onChange={handleCountrySelection}
      cacheOptions={true}
      defaultOptions={true}
    />
  )
}

We can see that we are using the AsyncSelect component from React Select. This component allows us to load the options asynchronously, so we can use the loadOptions prop to call our searchCountry function and get all the countries.

We are also defining the handleCountrySelection function that will be called when the user selects a country from the dropdown. This function will call the searchPlace function to get the extra information for the selected country, and then call the onSelect prop to notify the parent component that a country was selected.

Wrapping up

If you want to see the full code, you can visit this GitHub repository, where you will find this same example packed as an npm library to be easily consumed in your projects.

I hope this tutorial has been helpful and helped you to understand a bit better how to use the Google Places API.

If you have any questions or comments, feel free to reach me at @amaggi_ or leave a question on this post.

Building a visit counter with Redis and React

Agustin Maggi — Sat, 17 Apr 2021 03:55:54 +0000

Redis as a database is huge overestimated these days. It is commonly used for caching systems but on its own is a very powerful database. It can be used as an alternative of a Firebase storage, even for a Mongodb too.

At this time I will show you how we can get advantage about his speed and data structure for craft a visit counter component.

Setting Up the Redis database

We have to create an account in Redis Labs to start to configure the Redis database on the cloud.

Why did I choose Redis Labs?

They are responsible for the development of Redis so it's normal that they have the best tooling and latest update of this database motor.
300MB storage to use without any cost. That is more than enough for what we need to use.
99,999% uptime, that it's crazy!
Millisecond data processing.

When we have created the account, the next thing is to setup the Redis Cloud instance as a new subscription in your account. You can check this video for more details.

After you have ready the database, you need to go to the config tab and copy the Endpoint and Password values.

Connecting to Redis instance from a serverless backend

We need now a npm library to work as a client between Redis and our app. I used ioredis library because it has async functions and the feature of sending multiple commands at the same time, that we'll see later. So the first thing is create a file with the basic setup to connect to our Redis instance.
lib/redis.js

const redis = require("ioredis");

function Redis() {
  const conn = {
    port: process.env.REDIS_PORT,
    host: process.env.REDIS_URL,
    password: process.env.REDIS_PSW
  }
  return new redis(conn);
}

export default Redis;

Exposing an api service

Now, we have to define the api route with his logic for store and retrieve the numbers of users who visit a specific page. I'll use Next so we are going to create the following file.
pages/api/views/[slug].js

import client from 'lib/redis';
const redis = client();

export default async (req, res) => {
  const redis = client();
  const forwarded = req.headers['x-forwarded-for'];
  const ip = forwarded ? forwarded.split(/, /)[0] : req.connection.remoteAddress;
  let members = [];
  await redis
    .pipeline()
    .sadd(req.query.slug, ip)
    .smembers(req.query.slug)
    .exec((err, results) => {
      members = results[1][1];
    });
  redis.quit();
  const n = members.length;
  return res.status(200).json({
    total: n
  });
};

From the above, we can see a few things:

/api/views/:slug — it'll we the API URL expose to our frontend. It returns the number of unique users who visited a specific URL (slug).
We get the IP client to save it as a unique id and sum a visit on that page.
We are using a pipeline function to send multiple commands to Redis in only one transaction.
Redis has multiple commands to manipulate the data. We are using SADD to have a list of unique IPs for each page and not repeat the visit for each time that that user comes back to that page. And to retrieve the list we are using smembers.
The IP list from a specific page is saving in the variable members when we call the function exec.
Finally, we count the list of IPs from that page to know how many users visited it and return that number.

Building the React component

The last thing is coding the component that will fetch the data and hit the visit number.
PageviewsCounter.js

import useSWR from 'swr';
import { fetcher } from '@/lib/utils';

export default function PageviewsCounter({ slug }) {
  const { data } = useSWR(`/api/views/${slug}`, fetcher);
  const views = data?.total;

  if(views)
    return `${views} views`;
  return <><span className="line-through">999</span> views</>
}

As we can see, the component receives the slug of the page as a prop and it is using SWR library to improve the speed and cache for the fetch of the data.

Conclusion

So we had learned how in a few easy steps we can build a visit counter and save that data in our own backend as a Redis storage without depending on external services like Analytics.

Also we did get advantage of commands like SADD where in a native way it supports creating a list of non repeatable values to save the ip's of the users who visit each page.

You can see working this component in this site, in the right corner below the headline of each post.