How To Pack Javascript Code with Webpack

What is Webpack?

Webpack is a module bundler for JavaScript as well as HTML applications. It grabs modular pieces of code compartmentalized in folders. Followed by reconstituting them into a compiled form. Then it's read as a whole by the application. You must be thinking, "Why break up a working code?" As your code scales, so does its complexity. Finding a correlation between each block becomes a challenge.

Hence Webpack was conceived to offer the following benefits;

• Separation of concerns - code can split by functionality (i.e. logic, DOM).
• Splitting of JS files enables the loading of separate files instead of a whole on the first page hit.
• Babel transpilation to ES5 form ES6 without worrying about support older browsers.
• Re-run bundling as it detects saved changes. Handles module replacements and/or changes.

That said, figuring out what to pack can be daunting to beginners. Starting with Webpack is much like a moving day. Especially deciding on what items to categorize, pack and in which order to unpack. Plates and bowls must packed in a box with foam as fragile items and placed on the top pile to prevent breakage. Whereas books and magazines can pile from the bottom up in boxes since it can take the most weight. Rule of thumb is not to mix different categories of items into one box. Otherwise, you'll have trouble keeping track of the whereabouts of specific things. Also, it'll be inconvenient to unpack books first without unpacking bookshelves first.

This article assumes that readers have prior knowledge of Webpack setup. And serves as a guide to splitting JS files. Otherwise, check out tutorials here and here.

Depending on your JS application, you may split your files by functionality. In my case, my To-Do-List app split into several ways below;

• Event listener - Button clicks send user input to backend
• User input - Data received from a user
• Control - Application logic DOM - HTML output
• Starter - Default entry
• Constructor - For new objects
• Local Storage - Store new and edit entries

The image below illustrated JS file divided by separation of concern. It eliminates confusion when a new set of eyes tries to interpret the code or follow the trail.

Flowchart below illustrates call flow of functions;

Above you'll see linearity from starting function to the last as it should be similar for split files too. After splitting the file, the next bit is to export and import them as modules. The split starts from the end to the beginning and not in the middle to avoid losing track.

For lone function in the last folder, use export and import default method as shown below;

./src/DOM/TaskDOM.js

export default function renderTaskCard() {
.
.
}

.src/control/taskControl.js 

import renderTaskCard from '../DOM/taskDOM';
.
.

The use of ES5 export function is permissible by Eslint. Whereas ES6's "export default renderTaskCard() { ...." shows as lint none defined var error since renderTaskCard() is not assigned to a variable.

The image below illustrates the export and import of several functions;

.src/DOM/taskDOM.js

export const renderTaskCard = () => {
.
.
}

export const closeTaskForm = () => {
.
.
}

import { renderTaskCard, closeTaskForm } from '../DOM/taskDOM';

.
.

Function's names encased in curly braces as declaration of function import. But how do we know what needs import and export? Easy, identify functions that are being called.

.src/control/taskControl.js

import { renderTaskCard, closeTaskForm } from '../DOM/taskDOM';


export const addTaskToProject = (..) => {
  .
  .
  .
    renderTaskCard(..);
    closeTaskForm();
  }
};

renderTaskCard and closeTaskForm are being called from addTaskToProject in taskControl. So hook them up by declaring an import for both functions residing in taskDOM.

Then export functions in the recipient file below;

./src/DOM/taskDOM

export const renderTaskCard = () => {
.
.
}

export const closeTaskForm = () => {
.
.
}

This business of importation and exportation goes on till index.js where all event listeners are housed. 

In summary;

• Split files by functionality or function type.
• Where functions are called, target function importation must be declared.
• Followed by exporting target functions for file linkage and bundling.