This is very nice and allows us, after some hair-pulling time spent configuring and fine tuning the entry points and the common chunks, to greatly improve the Time To Interactive (TTI) of our app.

The problem is that those separate chunks are by default lazy-loaded, meaning that the client will only fetch them when absolutely necessary. And that has a big drawback, because now we have to handle loading times we did not have before. We reduced the TTI, but significantly increased the time necessary to jump from one section to another.

Enter over-eager loading, which is basically the idea of loading resources before the user actually asks for them/needs them by anticipating his needs. Loading our async chunks in an over-eager fashion will mean to quietly load them in the background after our app is interactive so that they’re ready for when the user actually needs them.

Let’s look at how to implement that.

Let’s create a class named AsyncChunks that will be in charge of generating our webpack split points.

import Loadable from 'react-loadable';
import LoadingPage from './LoadingPage';

class AsyncChunks {
  generateChunk = (loader) => {
    return Loadable({ loader, loading: LoadingPage });
  }
}

export default new AsyncChunks();

We threw in the handy react-loadable util that handles displaying a loading placeholder in case we try to access our chunk before it has actually loaded, plus a couple of other edge cases.

Now, in our app’s code, replace our simple imports with something like this:

AsyncChunks.generateChunk(() => import('./MyComponent'));

So far so good, we got ourselves a basic implementation of bundles lazy-loading. Let’s now sprinkle some magic on top of this to make it more interesting.

First, we’ll register all of these chunks to a queue:

class AsyncChunks {
  chunksQueue = [];
  
  appendToQueue = chunk => this.chunksQueue.push(chunk)
  
  generateChunk = (loader) => {
    this.appendToQueue(loader);
    return Loadable({ loader, loading: LoadingPage });
  }
}

Now, as soon as our app loads, all the async chunks are going to register to the chunksQueue array, waiting for our command. Let’s add a loadChunks method to our class to allow us to trigger the eager loading of those chunks when we see fit:

class AsyncChunks {
  chunksQueue = [];
  
  appendToQueue = chunk => this.chunksQueue.push(chunk)
  
  generateChunk = (loader) => {
    this.appendToQueue(loader);
    return Loadable({ loader, loading: LoadingPage });
  }

  loadChunks = () => {
    this.chunksQueue.forEach(loader => loader());
    this.chunksQueue = [];
  }
}

Now, we only have to call this loadChunks method when appropriate. And what better time that right after our app is done mounting?

In our App.jsx, we add:

componentDidMount = () => {
  setTimeout(AsyncChunks.loadChunks, 2 * 1000);
}

Here, we wait for two seconds (to avoid cluttering the bandwidth while most of the HTTP calls made by the app upon boot are still running), and then start loading all our chunks.

And that’s it!

One final touch though: to have a smarter over-eager loading, we should improve our AsyncChunks class to allow us to specify chunks that do not need to be preloaded:

class AsyncChunks {
  chunksQueue = [];
  
  appendToQueue = chunk => this.chunksQueue.push(chunk)
  
  generateChunk = (loader, register = true) => {
    if (register) this.appendToQueue(loader);
    return Loadable({ loader, loading: LoadingPage });
  }

  loadChunks = () => {
    this.chunksQueue.forEach(loader => loader());
    this.chunksQueue = [];
  }
}

Now we can still register our likely-to-be-needed chunks just like before, and the no-so-necessary ones like so:

AsyncChunks.generateChunk(() => import(‘./MyComponent’), false);

Those registered like this will load on-demand, in a default Webpack way.

To recap, we achieved to remove the delay created by Webpack’s code splitting when the client needs a new chunk while keeping all of the advantages of code splitting: minimal initial bundle and thus reduced Time To Interactive 🎉

Our last optimisation even allowed us to avoid wasting bandwidth by only pre-loading important bundles 😎

A few months later, I found myself having to refactor a very CPU-heavy Node.js service handling huge amounts of data and transforming them in various ways.

This is when I remembered Anjana Vakil’s conference and decided to dig further into using immutable data structures. My first step was to experiment with a JSPerf test:

As you can see, the results were quite spectacular.

The above test is comparing using JS’ filter method on a native array against using Mori’s filter function on a Mori list. While the former re-creates an array from scratch with the values satisfying the isAboveFifty predicate, the latter leverages immutable data structures to create a new list referencing the old one, only different in that it discarded the values we don’t want to keep.

Rejoiced by those results, I decided to start using Mori to refactor my Node.js service. And this is where it gets interesting, because I had been blending in functional programming principles in my daily JS code for some time now, but Mori actually enabled me (or should I say forced me) to refactor all of the data manipulation code to adopt a strict FP style.

Consider the following snippet of code:

const rows = [
  { a: 'foo', b: 'bar' },
  { a: 'baz', b: 'qux' },
];

const processRows = (rows, flag) => {
  if (flag) {
    rows.forEach((row) => {
      row.a = 'test';
    }
  }
  ... more processing
};

processRows(rows, true);

Now, while this works, it has the disadvantage of mutating directly the input data, and that comes with many risks. So let’s try and avoid that by refactoring this function in a slightly more functional style:

const processRows = (rows, flag) => {
  let newRows = rows;
  if (flag) {
    newsRows = rows.map(row => ({ ...row, a: 'test' }));
  }
  ... more processing
  return newRows;
};

const result = processRows(rows, true);

Now we are not mutating the input data anymore, but we got ourselves a couple of issues: first of all, we’re assigning and re-assigning a variable, which is not something you want to do when writing functional code (plus it’s ugly), but most importantly we are re-creating a full array with all of our rows on every map, and that is wasting a lot of resources.

Let’s start with the first issue, and extract that conditional processing to a separate function:

const replaceA = (rows, flag) => (
  flag
    ? rows.map(row => ({ ...row, a: 'test' }))
    : rows
);

const processRows = (rows, flag) => {
  const newRows = replaceA(rows, flag);
  ... more processing
  return finalRows;
};

const result = processRows(rows, true);

Now, because we have extracted the conditional processing to a separate function, we do not need to re-assign any variable: we are always creating a new one, that we’re going to use for the subsequent processing. Each step of the processing is going to, in the same fashion, return a new variable until we have our finalRows that we can return.

But now, we just created ourselves a new problem: say we have 3 functions we need to apply to our data, our main function is going to look like this:

const processRows = (rows) => {
  const stepA = applyStepA(rows);
  const stepB = applyStepB(stepA);
  const stepC = applyStepC(stepB);
  return stepC;
};

Those are a lot of variable assignments, this code is way too verbose and is becoming hard to maintain: each function has to use the data from the previous step, or it will be inadvertently discarding one step of the processing.

Let’s tackle this with a simple pipeline util function:

const pipeline = (...fns) => seed => (
  fns.reduce((acc, fn) => fn(acc), seed)
);

const processRows = rows => (
  pipeline(
    stepA,
    stepB,
    stepC,
  )(rows)
);

We can even go further and write it “point-free style”:

const processRows = pipeline(stepA, stepB, stepC);

Now we got ourselves some clean, terse, functional JS code, but we’re still copying our rows multiple times ; time to bring in the big guns!

Let’s go back to our initial example, and see how it would look like after applying those FP patterns and Mori immutable data structures:

import mori from 'mori';

const replaceA = (flag, rows) => (
  flag
    ? mori.map(row => ({ ...row, a: 'test' }), rows)
    : rows
);

const processRows = flag => pipeline(
  mori.partial(replaceA, flag),
  ... more functions
);

const result = processRows(true)(rows);

Here is what’s happening: first of all, processRows now takes only one argument, the flag boolean, and returns a function, our pipeline, that itself also takes one argument, the rows of data.
Inside that pipeline, we’re discovering an interesting case where a step takes several arguments. To tackle this, we reversed the order of the arguments replaceA takes so that the data it expects comes last (this is a very common pattern in functional programming). Then we partially apply the function using a handy partial util provided by Mori, so that it expects only one last argument: the data to operate on.

Lastly, we replaced the native map with Mori’s, that also happen to expects data as its last argument (see? 😄).

And boom! We’re not duplicating the input rows anymore! (We’re still duplicating the objects it contains though, and we could avoid that with Mori too, but that’s beyond the scope of this article).

Using functional programming principles and immutable data structures, we were able to break down our code into smaller, more easily testable functions. But most importantly, we are no longer mutating the original array, while avoiding the performance drawbacks of constantly duplicating our input array like the native Javascript array methods like map or filter inevitably do.