JavaScript, like most programming languages, was initially used for small tasks. But as its popularity grew, so did the amount of code that needed to be written.

Having a large amount of code in a single file can be problematic, so it's helpful to split the code into multiple parts. This is where modules come in handy.

What is a Module?

JavaScript modules are a way to organize and structure code. They allow developers to break their code into smaller, reusable pieces. You can think about them as smaller pieces of code that you can import and export between different parts of an application.

Throughout this article, we'll go through how use modules in your program and the best ways to do it.

But first, let's talk about some more reasons to use modules.

The Benefits of Using Modules

Your code will still run if you put it all in the same file. But you might be causing some problems for yourself. Let's talk about some benefits of using modules in your program.

More Organized Code

Using modules in your application makes everything well-sorted and arranged. It also makes your work easier to understand for anyone that wants to go through your code.

You probably wouldn't be excited to find a variable called "username" on line 431 or to need to start renaming a variable or function name everywhere it is used in an application.

Code Reusability

By breaking down your code into smaller, modular components, you can easily reuse those components in other parts of your application or in entirely new applications.

This can save you a lot of time and effort, as you don't have to rewrite the same code over and over again.

Also, if you make changes to a module, those changes will be reflected everywhere that module is used, making it easier to maintain and update your codebase.

No Naming Conflicts

Using JavaScript modules helps you avoid naming conflicts. When working on a large project, it's common for developers to write multiple functions and variables with the same name. This can lead to naming conflicts where two or more pieces of code have the same name, causing unexpected behavior and errors. With modules, you don't have this problem.

How to Use Modules in JavaScript

How to Define a Module

Here is the basic way to define a module. Imagine 2 files names, main.js and generate.js.

Here's main.js:

let name = "Muhammad Ali"

And here's generate.js:

function generateUserCertificate(userName, date): 
    # generate user certificate. 
const myName = name
generateUserCertificate(myName, "2023-09-04")

To use the "name" variable inside the generate.js file, you need to export it from the main.js file and import it into the generate.js file.

There are a lot of techniques you can use to import and export files.

We'll go through them one by one.

Types of File Exports in JavaScript

Default Exports

Here's how to perform a default export in a JavaScript file:

function getAllUser():

export default getAllUser

Note that you can only use one default export in a JavaScript file. You can also export before the declaration, like this:

export default function getAllUser():

This is easier to read, right?

Named Exports

Named exports allow you to share multiple modules from a file, unlike default exports which can only have one in a file.

You won't need to use the "default" syntax when using named exports. Named exports also need to be enclosed in curly brackets if you are exporting more than one module.

Here's an example:

const name = "Muhammad Ali"

export name;

You can also export before the declaration. Here's how to do that:

export function sayHi(user) {
  alert(`Hello, ${user}!`);
}

export function sayHello(user) {
  alert(`Hello, ${user}!`);
}

You can also export multiple variables, functions, or classes using named exports in a single statement. Here's an example:

const name = "Muhammad Alli"

function sayHello(user) {
  alert(`Hello, ${user}!`);
}

export {name, sayHello};

Note: It is possible to have both default and named export in a module.

const age = 404;

const name = "Muhammad Alli"

export default function sayHello(user) {
  alert(`Hello, ${user}!`);
}

export {age, name};

How to Rename Exports

It's also possible to rename your modules before exporting them. Here's how you'd do that:

export function sayHello(user) {
  alert(`Hello, ${user}!`);
}

export { sayHello as greet };

How to Import Modules

How to Import a Single Default Export

Here is how to import a default export:

import getAllUser from "getuser.js";

That's all – you can then proceed to use the getAllUser function anywhere in that file.

How to Import a Single Named Export

Here is how to import a single named export.

import {name} from "username.js"

How to Import Multiple Named Exports

Here is how to export multiple named exports.

 import {name, sayHello} from 'user.js'

How to Rename Imports

You can also rename exports before using them in a JavaScript file. Here's how to do it:

import {userName as name, greet as sayHello} from 'user.js'

It basically imports the name and 1sayHello1 module and renames them, so you can only make reference to "userName" and "greet" in this current module.

How to Import an Entire Module

What if there are a lot of modules to import and it's a waste of time to create a single line of named exports for them? Then you can export them this way:

import * as User from 'user.js'

Here is how you can use it in the module exported to:

import * as User from 'user.js'

User.name
User.sayHi

Conclusion

Modules are a powerful feature in JavaScript that allow developers to organize and structure their code for improved readability and reusability. They also help you avoid naming conflicts.

By breaking down large codebases into smaller, manageable modules, developers can write more efficient and maintainable code.

This article has covered the basics of defining, exporting, and importing modules in JavaScript, including default exports, named exports, renaming exports, and importing entire modules.

By mastering the use of modules, you can take your JavaScript programming skills to the next level and write more efficient and scalable code.

You can share your thoughts with me on Twitter here.

Happy coding! ^-^

Developers publish packages on NPM to share their code with others. And organisations also use NPM to share code internally.

In this article, you will learn how to create a package. And you will also learn how to publish your package on NPM so others can download and use it.

Let's get started!

How to Choose a Name For Your NPM Package

The first thing you need to do before creating your package is to choose a name. This is important because your package needs to have a unique name. You should choose a name that has not been used already.

When you decide on a name, go to the NPM registry and run a search. Be sure there's no exact match to the name you chose (or a match that is too similar).

For example, if there's a package called hellonpmpackage and you decide to call yours hello-npm-package, NPM will throw an error when you attempt to publish it.

If there's already a package in the NPM registry with the same you want to use, then you have two options.

1. You can choose a different name.

2. You can publish your package as a scoped package (see the section "Publishing scoped packages" below).

How to Create a NPM Package

Follow the steps below to create your package.

1. Install Node

If you do not already have Node installed, you should go ahead and install it. You can visit the official website to download and install Node.js. NPM comes pre-installed with Node.

2. Initialize a Git Repository

Create a new project folder for your package and navigate into the folder. Then, run the following command in your terminal:

git init

This will help you track the changes you make to your package. Also, make sure you have a remote version of your repository on GitHub (or your preferred hosting service).

3. Initialize NPM in Your Project

To do this, navigate to the root directory of your project and run the following command:

npm init

This command will create a package.json file. You will get prompts to provide the following information:

• package-name: As you learned earlier in this tutorial, the name of your package must be unique. Also it must be lowercase. It may include hyphens.

• version: The initial value is 1.0.0. You update the number when you update your package using semantic versioning.

• description: You can provide a description of your package here. Indicate what your package does and how to use it.

• entry point: The entry file for your code. The default value is index.js.

• test command: Here, you can add the command you want to run when a user runs npm run test.

• git repository: The link to your remote repository on GitHub.

• keywords: Add relevant keywords that will help others find your package on the NPM registry.

• author: Add your name.

• license: You can add a license or use the default license (Internet Systems Consortium (ISC) License).

See the screenshot below for an example of how to answer the prompt questions:

Creating a package.json file

Note: I left the test command blank because there is no test command for the package in this tutorial.

4. Add Your Code

Now, you can go ahead and add the code for your package.

First, you need to create the file that will be loaded when your module is required by another application. For this tutorial, that will be the index.js file.

Inside the index.js file, add the code for your package.

For this tutorial, I will be creating a simple package called first-hello-npm. This package returns the string "Hello NPM!".

//index.js

function helloNpm() {
  return "hello NPM"
}

module.exports = helloNpm

After creating your function, you should export it like in the example above. That way, anyone who downloads your package can load and use it in their code.

If you have been following along, you should now have your package created. But before you publish, you need to test your package. Testing your package reduces the chances of publishing bugs to the NPM registry.

How to Test Your NPM Package

Testing ensures that your NPM package works as expected. There are many ways to test your package. In this tutorial, you will learn one of the simplest ways of testing.

First, navigate to the root of your package project. Then, run the following command:

npm link

This will make your package available globally. And you can require the package in a different project to test it out.

Create a test folder. And inside that test folder, add a script.js file.

Example of a test folder with a script.js file

In the example above, the test folder contains only the script.js file. It does not yet contain the package. To add the package you created to your test folder, run the command below:

npm link <name-of-package>

In the case of the test folder for this tutorial, I will run the following command:

npm link first-hello-npm

This will create a node-modules folder. And it'll add all the files and folders from your package – see the screenshot below:

In the script.js file, you can now require your package and use it for the test.

// test/script.js

const helloNpm = require('first-hello-npm')

console.log(helloNpm())

The first-hello-npm package is expected to return the string "hello NPM!". As you can see from the screenshot below, the package works as expected when I run the script.

Test result for first-hello-npm package

After testing your package and ensuring it works as expected, you can now publish it on the NPM registry.

How to Publish Your NPM Package

To publish your package on the NPM registry, you need to have an account. If you don't have an account, visit the NPM sign up page to create one.

After creating the account, open your terminal and run the following command in the root of your package:

npm login

You will get a prompt to enter your username and password. If login is successful, you should see a message like this:

Logged in as <your-username> on https://registry.npmjs.org/.

You can now run the following command to publish your package on the NPM registry:

npm publish

If all goes well, you should get results similar to the screenshot below:

Notice indicating that the package is published successfully.

If you have been following along, then congratulations! You just published your first NPM package.

You can visit the NPM website and run a search for your package. You should see your package show up in the search results.

For example, from the screenshot below, you can see the first-hello-npm package is now available on NPM.

The first-hello-npm package is now available on NPM

How to Publish Scoped NPM Packages

If an existing package has the same name you would like to use, the workaround is to publish a scoped package.

When you publish a scoped package, you have the option to make it public or private. If it's private, you can choose who you want to share the package with.

How to Create a Scoped NPM Package

To create a scoped package, first navigate to the root of your package directory.

Then, run the npm init command and pass your username as the value to the scope flag:

npm init --scope=@your-username

Respond to the prompts to create a package.json file. For your package name, the format should be @your-username/package-name.

For example @benjaminsemah/first-hello-npm.

You can now add the code for your package and test it. The process is the same as already explained above.

Then, to publish your scoped package, run the following command in your terminal.

npm publish --access public

You can change from public to private if you don't want to make the package available for public use.

You should see a response similar to this.

Scoped package published successfully.

Congratulations if you followed along. You've published your scoped package. You should see your scoped package on NPM if you search for it. For example in the screenshot below, you can see the scoped package I created in this tutorial.

Scoped package is now available on NPM

Conclusion

Packages helps developers work faster. And they also improve collaboration. When you figure out a smarter way of doing things, one way you can share with the community is to create and publish your solution as a package.

In this article, you learned what packages are and why they are useful. You also learned how to create and publish packages on the NPM registry. The developer community awaits all the beautiful packages you will create and share.

Thanks for reading. And happy coding!

In this tutorial, you will learn what node modules are. You will also learn about the three types of node modules. And we'll go over the right way to use them in your applications.

What is a Module in JavaScript?

In simple terms, a module is a piece of reusable JavaScript code. It could be a .js file or a directory containing .js files. You can export the content of these files and use them in other files.

Modules help developers adhere to the DRY (Don't Repeat Yourself) principle in programming. They also help to break down complex logic into small, simple, and manageable chunks.

Types of Node Modules

There are three main types of Node modules that you will work with as a Node.js developer. They include the following.

• Built-in modules

• Local modules

• Third-party modules

Built-in Modules

Node.js comes with some modules out of the box. These modules are available for use when you install Node.js. Some common examples of built-in Node modules are the following:

• http

• url

• path

• fs

• os

You can use the built-in modules with the syntax below.

const someVariable = require('nameOfModule')

You load the module with the require function. You need to pass the name of the module you're loading as an argument to the require function.

Note: The name of the module must be in quotation marks. Also, using const to declare the variable ensures that you do not overwrite the value when calling it.

You also need to save the returned value from the require function in someVariable. You can name that variable anything you want. But often, you will see programmers give the same to the variable as the name of the module (see example below).

const http = require('http') 

server = http.createServer((req, res) => { 
    res.writeHead(200, {'Content-Type': 'text/plain'}) 
    res.end('Hello World!')
})

server.listen(3000)

You use the require function to load the built-in http module. Then, you save the returned value in a variable named http.

The returned value from the http module is an object. Since you've loaded it using the require function, you can now use it in your code. For example, call the .createServer property to create a server.

Local Modules

When you work with Node.js, you create local modules that you load and use in your program. Let's see how to do that.

Create a simple sayHello module. It takes a userName as a parameter and prints "hello" and the user's name.

function sayHello(userName) {
    console.log(`Hello ${userName}!`)
}

module.exports = sayHello

First, you need to create the function. Then you export it using the syntax module.exports. It doesn't have to be a function, though. Your module can export an object, array, or any data type.

How to load your local modules

You can load your local modules and use them in other files. To do so, you use the require function as you did for the built-in modules.

But with your custom functions, you need to provide the path of the file as an argument. In this case, the path is './sayHello' (which is referencing the sayHello.js file).

const sayHello = require('./sayHello')
sayHello("Maria") // Hello Maria!

Once you've loaded your module, you can make a reference to it in your code.

Third-Party Modules

A cool thing about using modules in Node.js is that you can share them with others. The Node Package Manager (NPM) makes that possible. When you install Node.js, NPM comes along with it.

With NPM, you can share your modules as packages via the NPM registry. And you can also use packages others have shared.

How to use third-party packages

To use a third-party package in your application, you first need to install it. You can run the command below to install a package.

npm install <name-of-package>

For example, there's a package called capitalize. It performs functions like capitalizing the first letter of a word.

Running the command below will install the capitalize package:

npm install capitalize

To use the installed package, you need to load it with the require function.

const capitalize = require('capitalize)

And then you can use it in your code, like this for example:

const capitalize = require('capitalize')
console.log(capitalize("hello")) // Hello

This is a simple example. But there are packages that perform more complex tasks and can save you loads of time.

For example, you can use the Express.js package which is a Node.js framework. It makes building apps faster and simple. To learn more about NPM, read this freeCodeCamp article on the Node Package Manager.

Conclusion

In this article, you learned about what Node modules are and the three types of node modules. You also learned about how to use the different types in your application.

Thanks for reading. And happy coding!

In programming, modules are components of a program with one or more functions or values.

These values can also be shared across the entire program and can be used in different ways.

In this article, I will show you how to share functions and values by exporting and importing modules in Node.js.

Why Export Modules?

You'll want to export modules so that you can use them in other parts of your application.

Modules can serve different purposes. They can provide simple utilities to modify strings. They can provide methods for making API requests. Or they can even provide constants and primitive values.

When you export a module, you can import it into other parts of your applications and consume it.

Node.js supports CommonJS Modules and ECMAScript Modules.

For the rest of this article, we'll focus on CommonJS Modules, the original approach to packaging modules in Node.js.

If you want to learn more about ES Modules (along with CommonJS modules), you can check out this in-depth guide.

How to Export Modules in Node

Node.js already exports in-built modules which include fs, path, and http to name a few. But you can create your own modules.

Node.js treats each file in a Node project as a module that can export values and functions from the file.

Say, for example, that you have a utility file utility.js with the following code:

// utility.js

const replaceStr = (str, char, replacer) => {
  const regex = new RegExp(char, "g")
  const replaced = str.replace(regex, replacer)
  return replaced
}

utility.js is a module which other files can import things from. But utility.js currently does not export anything.

You can verify this by examining the global module object in each file. When you print the module global object in this utility file, you have:

console.log(module)

// {
//   id: ".",
//   path: "...",
//   exports: {},
//   parent: null,
//   filename: "...",
//   loaded: false,
//   children: [],
//   paths: [
//     ...
//   ],
// }

The module object has an exports property which, as you can see, is an empty object.

So any attempt to import anything from this file will throw an error.

The utility.js file has a replaceStr method which replaces characters in a string with some other characters. We can export this function from this module to be used by other files.

Here's how:

// utility.js

const replaceStr = (str, char, replacer) => {
  const regex = new RegExp(char, "g")
  const replaced = str.replace(regex, replacer)
  return replaced
}

module.exports = { replaceStr }
// or
exports.replaceStr = replaceStr

Now, replaceStr is available for use in other parts of the application. To use it, you import it like this:

const { replaceStr } = require('./utility.js')

// then use the function anywhere

module.exports vs exports in Node

You can export functions and values from a module by either using module.exports:

module.exports = { value1, function1 }

or by using exports:

exports.value1 = value1
exports.function1 = function1

What's the difference?

These methods are pretty identical. Basically, exports serves as a reference to module.exports. To understand this better, let's populate the exports object by using the two ways of exporting values:

const value1 = 50
exports.value1 = value1

console.log(module)
// {
//   id: ".",
//   path: "...",
//   exports: { value1: 50 },
//   parent: null,
//   filename: "...",
//   loaded: false,
//   children: [],
//   paths: [
//     ...
//   ],
// }

const function1 = function() {
  console.log("I am a function")
}
module.exports = { function1, ...module.exports }

console.log(module)

// {
//   id: ".",
//   path: "...",
//   exports: { function1: [Function: function1] },
//   parent: null,
//   filename: "...",
//   loaded: false,
//   children: [],
//   paths: [
//     ...
//   ],
// }

There are two things to notice here:

• The exports keyword is a reference to the exports object in the modules object. By doing exports.value1 = value1, it added the value1 property to the module.exports object, as you can see in the first log.
• The second log does not contain the value1 export anymore. It only has the function exported using module.exports. Why is this so?

module.exports = ... is a way of reassigning a new object to the exports property. The new object only contains the function, so the value1 is no longer exported.

So what's the difference?

Exporting values with just the exports keyword is a quick way to export values from a module. You can use this keyword at the top or bottom, and all it does is populate the module.exports object. But if you're using exports in a file, stick to using it throughout that file.

Using module.exports is a way of explicitly specifying a module's exports. And this should ideally only exist once in a file. If it exists twice, the second declaration reassigns the module.exports property, and the module only exports what the second declaration states.

So as a solution to the previous code, you either export like this:

// ...
exports.value1 = value1

// ...
exports.function1 = function1

or like this:

// ...
module.exports = { value1, function1 }

Wrap up

Each file in a Node.js project is treated as a module that can export values to be used by other modules.

module.exports is an object in a Node.js file that holds the exported values and functions from that module.

Declaring a module.exports object in a file specifies the values to be exported from that file. When exported, another module can import this values with the require global method.

When you are building an application that can be accessed on the web, there are a lot of dependencies or packages that you will need for your application to function well.

You'll need most of these packages when you're building JAMStack applications with frameworks or libraries like React, Vuejs, Next.js, or Angular.

In this article, I'll walk you through an error you may get when you are building JavaScript apps with Next.js, and how to bypass it.

What the Heck are ESModules?

ESModules are the ECMAScript standards for working with JavaScript modules in the browser.

"What does that have to do with these annoying and frustrating errors that I have been seeing for the past few days?" you might ask me.

Well... Node.js has been using the CommonJS standards for a very long time to properly structure JavaScript code or modules in this scenario, and the majority of the code we write resides/works in the browser.

There were no standards to properly guide how JavaScript modules were used, or interpreted, at least in web browsers. This challenge brought about the ESModules standards which guide how JavaScript modules work in the browser.

This standard was approved when ES6 (ECMAScript 6) was launched in 2015, and brought about the implementation of the standards in various web browsers like Chrome, Safari, Firefox, and Microsoft's Edge.

Most of the packages we use in building frontend UIs are written in JavaScript. They have modules that are exporting a particular function (it could be a JavaScript component), an object, a string, a bunch of arrays, and so on.

These functions, arrays, or strings can be exposed as libraries to other JavaScript files. Say, for example, we have a function that prints the name of anyone in the console. The syntax will be like this:

// name.js
export default (name) => console.log(name)

The snippet above describes a default export, without a specific name. This means that if we want to use the function in this module, we can call it any name, since a name wasn't explicitly assigned to it upon declaration

import printName from "./name.js"

printName("Dodo")

Okay, why do I still get the error though?

Yes. Now on to that error. When we begin to interface with a lot of dependencies or packages in our applications, some things might start going wrong if we don't give proper care to our codebases.

We start to deal with versioning of these packages, breaking changes, and releases sometimes, which we can not keep track of. Then, we might begin to scurry down the rabbit hole of downgrading or upgrading a particular npm package before anything even works at all.

Most of these errors may arise from the maintainers of these packages. Take, for example, the ESModules standard – which is relatively new – that we are discussing in this article. It may take some time for it to be adopted by some frameworks or front-end JavaScript libraries out there, for example, Next.js.

The error in the image below shows that we can't use the CommonJS approach to import a module.

This new standard and the fact that it's a bit unfamiliar to these tools we use is the reason for this error. Nirmalya Ghosh wrote this piece on how to maintain large Next.js apps, you should take a look at it.

How to use Next.js dynamic imports

Now that we've gone through the rudiments of what ESModules are, let's see how we can fix the error that is quite similar to the one we saw in the image above. We'll see how we can fix it with dynamic imports in Next.js.

I'll be assuming you already have a Next.js app running, so I'll just share the corresponding ESModule error I got from my terminal in the code block below:

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /path/to/package

require() of ES modules is not supported. 

ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.

Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /path/to/package

Take a look at the error above so that you're quite familiar with it. Once you've done that, let's proceed.

What are dynamic imports?

Dynamic imports is a feature of Next.js that allows you to work with JavaScript modules conveniently in the browser.

It provides a means of pre-rendering these modules with SSR (Server-side Rendering) so that users do not need to send requests continuously to the server when they need — say, for example — a page that uses a JavaScript module. With dynamic imports, the modules are already pre-rendered in the browser.

Recently, I was working on a project that had to do with markdown content. I needed to use rehype plugins, but I kept on getting the error in the previous code block.

const rehypeSlug = dynamic(() => import('rehype-slug'), { ssr: false })
const rehypeCodeTitles = dynamic(() => import('rehype-code-titles'), {
  ssr: false,
})
const rehypeAutolinkHeadings = dynamic(
  () => import('rehype-autolink-headings'),
  { ssr: false }
)
const rehypePrism = dynamic(() => import('rehype-prism-plus'), { ssr: false })

The snippet above shows how you can import a module with dynamic imports and pass the ssr object as an argument to it.

With this approach of using dynamic imports, the ESModule errors that kept on showing up were removed.

Wrapping Up

So I hope you'll be able to make use of this feature, and I hope it liberates you from that error.

There's a lot you have to think about when you're building JavaScript applications, so this can be one less thing. Thank you for reading this article, and I hope you enjoyed it.

Modules are a technique heavily used in today's software design/architecture.

First we're going to learn what they are and the different types of modules that exist. Then we're going to discuss why modules are useful. Then we're going to see examples and basic syntax for the most used module types, and finally we're going to discuss bundling, why is it necessary, and how to do it.

Enough cháchara, let's go! =D

Table of Contents

• What are modules and why are they useful

• Types of modules

  • CommonJS

  • ESmodules

• Using modules

• Bundling modules

• Roundup

What are modules and why are they useful

A module is just a piece of code in a file that you can call and use from other files. A modular design is the opposite of having all your project's code in one single file.

When developing a big project, it's very useful to divide our code into modules for the following reasons:

• It's good for dividing concerns and features into different files, which helps visualization and organization of code.

• Code tends to be easier to maintain and less prone to errors and bugs when it's clearly organized.

• Modules can be easily used and reused in different files and parts of our project, without needing to rewrite the same code again.

Instead of having all of our program's components in a single file, we can divide it into parts or modules, and make each of them responsible for a single feature/concern.

If this concept isn't clear enough now, don't worry. We'll see some examples in a sec.

Types of modules

As with almost everything in life, and especially in JavaScript, there are many ways for us to implement modules.

As JavaScript was first created to be just a small scripting language for websites, a feature for big projects like modules wasn't supported at the beginning.

But as the language and the ecosystem grew, developers started to see the need for this feature. And so different options and libraries were developed to add this feature to JavaScript.

Of the many available, we're only going to take a look at CommonJS and ESmodules, which are the most recent and widely used ones.

Side comment: Did you know that Javascript was originally created in just 10 days of work?

When analyzing the complexities of JavaScript and understanding how the language has evolved, I think it's important to have in mind that the language wasn't originally created to do what it does nowadays. It's the growth of the Javascript ecosystem that pushed for many of the changes that have come about.

CommonJS modules

CommonJS is a set of standards used to implement modules on JavaScript. The project was started by Mozilla engineer Kevin Dangoor in 2009.

CommonJS is mainly used in server-side JS apps with Node, as browsers don't support the use of CommonJS.

As a side comment, Node used to only support CommonJS to implement modules, but nowadays it also supports ESmodules which is a more modern approach.

So let's see how CommonJS looks in actual code.

To implement modules, you need a Node app on your computer first. So create one by running npm init -y.

First let's create a main.js file with a simple function in it.

const testFunction = () => {
    console.log('Im the main function')
}

testFunction()

Ok now let's say we want to have another function called from our main file, but we don't want the function in it as it's not part of our core feature. For this, let's create a mod1.js file and add this code to it:

const mod1Function = () => console.log('Mod1 is alive!')
module.exports = mod1Function

module.exports is the keyword we use to declare all we want to export from that file.

To use this function in our main.js file, we can do it like this:

mod1Function = require('./mod1.js')

const testFunction = () => {
    console.log('Im the main function')
    mod1Function()
}

testFunction()

See that we declare whatever we want to use and then assign that to the require of the file we want to use. Piece of cake. ;)

If we wanted to export more than one thing from a single module, we can do it like this:

const mod1Function = () => console.log('Mod1 is alive!')
const mod1Function2 = () => console.log('Mod1 is rolling, baby!')

module.exports = { mod1Function, mod1Function2 }

And on the main.js file we can use both functions like this:

({ mod1Function, mod1Function2 } = require('./mod1.js'))

const testFunction = () => {
    console.log('Im the main function')
    mod1Function()
    mod1Function2()
}

testFunction()

And that's pretty much it. Quite simple, right? It is simple but it's a powerful tool to use. =)

ESmodules

Now let's review ESmodules. ESmodules is a standard that was introduced with ES6 (2015). The idea was to standarize how JS modules work and implement this features in browsers (which didn't previously support modules).

ESmodules is a more modern approach that is currently supported by browser and server-side apps with Node.

Let's see this in code. Once again we start by creating a Node app with npm init -y.

Now we go to our package.json and add "type": "module" to it, like this:

{
  "name": "modulestestapp",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "type": "module"
}

If we don't do this and try to implement ESmodules on Node, we'll get an error like this:

(node:29568) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
...
SyntaxError: Cannot use import statement outside a module

Now let's repeat the exact same example. In our main.js file we'll have the following code:

// main.js
import { mod1Function } from './mod1.js'

const testFunction = () => {
    console.log('Im the main function')
    mod1Function()
}

testFunction()

And on mod1.js we'll have this:

// mod1.js
const mod1Function = () => console.log('Mod1 is alive!')
export { mod1Function }

Notice instead of require we're using import and instead of module.exports we're using export. The syntaxt is a bit different but the behaviour is very similar.

Again if we wanted to export more than one thing from the same file we could do it like this:

// main.js
import { mod1Function, mod1Function2 } from './mod1.js'

const testFunction = () => {
    console.log('Im the main function')
    mod1Function()
    mod1Function2()
}

testFunction()

// mod1.js
const mod1Function = () => console.log('Mod1 is alive!')
const mod1Function2 = () => console.log('Mod1 is rolling, baby!')

export { mod1Function, mod1Function2 }

Another feature available in ESmodules is import renaming, which can be done like this:

// main.js
import { mod1Function as funct1, mod1Function2 as funct2 } from './mod1.js'

const testFunction = () => {
    console.log('Im the main function')
    funct1()
    funct2()
}

testFunction()

Notice we use the as keyword after each function, and then rename it however we want. Later in our code, we can use that new name instead of the original name the import has. ;)

Another thing you could do is import all exports together and put them together in an object, like this:

// main.js
import * as mod1 from './mod1.js' 

const testFunction = () => {
    console.log('Im the main function')
    mod1.mod1Function()
    mod1.mod1Function2()
}

testFunction()

This may be useful in cases when, throughout our code, we want to be explicit about where each import is coming from. See that functions are now being called like mod1.mod1Function().

The last thing worth mentioning is the default keyword. With it we can set a default export for a given module. Like this:

// mod1.js
const mod1Function = () => console.log('Mod1 is alive!')
const mod1Function2 = () => console.log('Mod1 is rolling, baby!')

export default mod1Function
export { mod1Function2 }

And what does it mean to have a default export? Well, it means we don't have to destructure it when we import it. We can use it just like this:

// main.js
import mod1Function, { mod1Function2 } from './mod1.js' 

const testFunction = () => {
    console.log('Im the main function')
    mod1Function()
    mod1Function2()
}

testFunction()

We can even rename the import whatever we want without the as keyword, since JavaScript "knows" that if we're not destructuring we'll be referring to the default import.

// main.js
import lalala, { mod1Function2 } from './mod1.js' 

const testFunction = () => {
    console.log('Im the main function')
    lalala()
    mod1Function2()
}

testFunction()

And that pretty much sums it up about ESmodules too. Straightforward I hope. =)

Using modules

Ok now that we're clear about the different types of modules available and how they work, let's see how we can implement modules in a website using HMTL and Vanilla JS.

Let's create a simple HTML file with a heading, two buttons, and a script tag linking to our main.js file.

<!-- index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>
    <h1>I'm just a test...</h1>
    <button id="isAlive">Is mod1 alive?</button>
    <button id="isRolling">Is mod1 rolling?</button>
    <script src="./main.js" type="module"></script>
</body>
</html>

Pay attention to the fact that I'm declaring type="module" on the script tag. We need to do this in order to use the JS module feature. If we don't, we'll get an error like this:

Uncaught SyntaxError: Cannot use import statement outside a module

If we open our HTML file we should get something like this:

Our main.js file will have this code:

// main.js
import { mod1Function, mod1Function2 } from './mod1.js'

const testFunction = () => console.log('Im the main function')

document.getElementById('isAlive').addEventListener('click', () => mod1Function())
document.getElementById('isRolling').addEventListener('click', () => mod1Function2())

testFunction()

We're just adding a click event listener to each button so the functions that come from the mod1.js file get executed.

Ok so now we can serve our HTML file and see if this works. We need to serve the file, we can't just open the HTML in the browser because we would get a CORS error like this:

Access to script at ... from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, brave, chrome-untrusted, https.

To serve it quickly you can use the Live server VS code extension, or create a Node app by running npm init -y and then running npx serve.

Anyway, once the file is served we can click on each button and test that our functions execute correctly. Our console should look like this:

But there's one more thing about this. If we go to the network tab of the browser's developer tools, and filter by JS files, we can see that the website is loading two files, main.js and mod1.js:

Of course if we're going to use the code inside each file, both need to be loaded – but this is not the best thing to do. That's because the browser needs to perform two different requests to load all the JS necessary.

We should always try to reduce the requests to the minimun to increase the performance of our projects. So let's see how we can do this with the help of a module bundler.

Side comment: if you'd like a video explanation, Kent C Dodds has a great one. I really recommend that you follow him, he's one of the best JS teachers out there. And here's another cool video by Fireship. ;)

Bundling modules

As previously mentioned, dividing our code into modules is nice because our codebase will be more organized and it will be easier to reuse our code.

But these are advantages only for the development phase of a project. When in production, modules are not the best thing, as forcing the browser to make a request for each JS file might hurt the site's performance.

This problem can be easily solved with the use of a module bundler. Simply put, module bundlers are programs that take JS modules as input and combine them into a single file (many module bundlers have many more features but that's their core concept).

Thanks to this, as developers we can code our project dividing it into nicely organized pieces, and then run a module bundler to obtain the final code that will be used in production.

This step of converting "development code" to "production code" is normally recognized as "build".

There're many options to use for this (like Browserify, Parcel, Rollup.js, Snowpack...) but the most widely used is Webpack. So let's see an example using Webpack.

• Side comment 1: If you want to dig deeper into module bundlers and how they work, this awesome video by Fireship might be a good place to start.

• Side comment 2: Webpack is a very robust and sophisticated tool that can do many things besides bundling JS files. Check out their docs if you want to learn more.

Great, so now we can start off by creating a Node app (if you haven't already) by running npm init -y. Then we'll need to install Webpack and the Webpack CLI by running npm i --save-dev webpack webpack-cli.

Next we'll create a webpack.config.js file and put this code inside it:

/* webpack.config.js */
const path = require('path');

module.exports = {
  entry: './main.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js',
  },
};

This file will be responsible for the configuration of Webpack and how it will work in our app.

What we're doing here first is setting the entry file (entry: './main.js'). Webpack will start by reading that file and then analyzing all the dependencies (modules imported from that file). In other words, the entry file is our main JS file where all other modules are imported.

Then we're declaring the output – first declaring the path where it will be stored and then declaring the name of the bundled file.

output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js',
},

Super! Now let's go to our package.json file and add a build script, like this:

{
  "name": "testappv2",
  "version": "1.0.0",
  "description": "",
  "main": "main.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "webpack"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "webpack": "^5.72.0",
    "webpack-cli": "^4.9.2"
  }
}

Then we can go back to our terminal and run npm run build. That should create a dist directory within our project, and inside it a bundle.js file.

If you check that file out, you'll see this code within it:

(()=>{"use strict";document.getElementById("isAlive").addEventListener("click",(()=>console.log("Mod1 is alive!"))),document.getElementById("isRolling").addEventListener("click",(()=>console.log("Mod1 is rolling, baby!"))),console.log("Im the main function")})();

You'll see that it's practically the same code we had distributed in our files, but all bundled in a single file and minified.

The only thing left is to change the script tag in our index.html file so it consumes the bundled JS now, like this:

<!-- index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>
    <h1>I'm just a test...</h1>
    <button id="isAlive">Is mod1 alive?</button>
    <button id="isRolling">Is mod1 rolling?</button>
    <script src="./dist/bundle.js" type="module"></script>
</body>
</html>

Now we can serve it again, check that the JS still works perfectly, and if we open the network tab again we should see just a single file being loaded! =D

I hope this simple example helped you understand the relevance of module bundlers and how they help us combine the great development experience of modular architecture with good site performance.

Roundup

Well, we're done for today. In this article we've seen what modules are, why are they cool, the different ways you can implement modules in JavaScript, and a practical example of bundling our code with Webpack.

For a complete guide on JS modules, you can take a look at this article.

As always, I hope you enjoyed the article and learned something new. If you want, you can also follow me on linkedin or twitter.

Cheers and see you in the next one! =D

JavaScript modules (also known as ES modules or ECMAScript modules) were created to help make JavaScript code more organized and maintainable.

Understanding how ES modules work will help you become a better JavaScript developer. In this article, we'll cover:

• What is a module?
• What are ES modules? Why do we use them?
• How to use ES modules
• Other module systems used in JavaScript

Let's get started.

What is a module?

A module in JavaScript is just a file of code. You can think of a module as a reusable and independent unit of code.

Modules are the building blocks of your codebase. As your application gets bigger, you can split your code up into multiple files, aka modules.

Using modules allows you to break down large programs into more manageable pieces of code.

What are ES modules? Why do we use them?

ES modules are the official module system used in JavaScript. There are other module systems that can be used in JavaScript as well, and we'll talk more about those later. But for now, know that we're learning about ES modules rather than other module systems because they're standard for modules in JavaScript.

As a JavaScript developer, you'll likely use ES modules in your daily work.

Here are some of the advantages that developers get from using ES modules:

1. Organization. By breaking down large programs into smaller pieces of related code, you keep your program organized.
2. Reusability. With ES modules, you can write code in one place and reuse that code in other files throughout your codebase. For example, instead of rewriting the same function everywhere, you can write a function inside of one module and then import it into another file and use it there.

Let’s dive into an example using ES modules. We'll learn about how ES modules work so you can use them in your projects going forward. As we work with ES modules, we’ll see each of the above advantages demonstrated.

How to use ES Modules

Let’s start out with creating a vanilla JavaScript Replit. You can also find the completed code here.

Once on Replit, we can create a new project and choose HTML, CSS, and JavaScript. This will create a starter project that has an index.html file, a script.js file, and a style.css file. This is everything we need to get set up.

Inside of our index.html file, we're going to modify our script tag to include type="module". This will allow us to start using ES modules in our code. Modify your script tag to be:

<script type="module" src="script.js"></script>

Let’s start out by writing a simple add function. This function will take two numbers, add them together, and then return the result of that addition. We'll also call this function. We'll write this function in our script.js file:

function add(a, b) {
 return a + b;
};
console.log(add(5, 5)); //outputs 10

So far, our script.js file is small with little code in it. But imagine that this application gets bigger and we have dozens of functions like this. This script.js file could get too big and become harder to maintain.

Let’s avoid this problem by creating a module. We can do this by clicking 'Add File', within our replit. Remember, a module is just a file of related code.

We'll call our module math.js. We're going to remove this add function from our script.js file, and we're going to create a new file, math.js. This file will be our module where we'll keep our math-related functions. Let's place our add function inside this file:

// math.js

function add(a, b) {
 return a + b;
};

We've decided to call this module math.js, because we will create more math related functions in this file later on.

If we were to open this application and see it at a glance, we'd know that our math-related logic is inside this file. We don’t need to waste time coming into this application and searching for our math functions and wondering about where they are – we've organized them neatly into a file.

Next, let’s use the add function inside of our script.js file, even though the function itself now lives inside of the math.js file. To do this, we need to learn about ES module syntax. Let's go over the export and the import keywords.

The export keyword

When you want to make a module available in other files besides the one it lives in, you can use the export keyword. Let’s use the export keyword with our add function so we can use it inside of our script.js file.

Let's add export default underneath our add function inside of math.js:

// math.js

function add(a, b) {
 return a + b;
};

export default add;

With the last line, we are making this add function available to use in other places besides the math.js module.

Another way of using the export keyword is to add it just before we define our function:

// math.js

export default function add(a, b) {
 return a + b;
};

These are two different ways of using the export keyword, but both work the same.

You might be wondering what that default keyword is that comes after export. We'll get to that in a minute. For now, let's actually use our add function in another file, now that we've exported it.

The import keyword

We can use the import keyword to import our add function into our script.js file. Importing this function just means we'll gain access to that function and be able to use it within the file. Once the function is imported, we can use it:

// script.js
import add from './math.js';

console.log(add(2, 5)); //outputs 7

Here, with ./math.js, we're using a relative import. To learn more about relative paths and absolute paths, check out this helpful StackOverflow answer.

When we run this code, we can see the result of calling our add function, 7. Now you can use the add function as many times as you’d like within this file.

The code for the add function itself is now out of sight, and we can use the add function without necessarily needing to look at the code for the function itself.

If we commented out the line import add from './math.js' for a moment, we'd suddenly get an error: ReferenceError: add is not defined. This is because script.js does not have access to the add function unless we explicitly import that function into this file.

We've exported our add function, imported it into our script.js file, and then called that function.

Let’s look into our math.js file again. As mentioned earlier, you may have been confused when you saw the word default with the export keyword. Let's talk more about the default keyword.

Named exports versus default exports in JavaScript

With ES modules, you can use named exports or default exports.

In our first example, we used a default export. With a default export, we exported only a single value (our add function) from our math.js module.

When using a default export, you can rename your import if you'd like to. In our script.js file, we can import our add function and call it addition (or any other name) instead:

// script.js
import addition from './math.js';

console.log(addition(2, 5)); //outputs 7

On the other hand, named exports are used to export multiple values from a module.

Let's create an example using named exports. Back in our math.js file, create two more functions, subtract and multiply, and place them underneath our add function. With a named export, you can just remove the default keyword:

// math.js

export default function add(a, b) {
 return a + b;
};

export function subtract(a, b) {
 return a - b;
};

export function multiply(a, b) {
 return a * b;
};

In script.js, let's remove all the previous code and import our subtract and multiply functions. To import the named exports, surround them in curly brackets:

import { multiply, subtract } from './math.js';

Now we can use both of these functions inside of our script.js file:

// script.js
import { multiply, subtract } from './math.js';

console.log(multiply(5, 5));

console.log(subtract(10, 4))

If you'd like to rename a named export, you can do so with the as keyword:

import add, { subtract as substractNumbers } from './math.js';

console.log(substractNumbers(2, 5));

Above, we've renamed our subtract import to subtractNumbers.

Let's get back to our add function. What if we'd like to use it again in our script.js file, alongside our multiply and subtract functions? We can do so like this:

import add, { multiply, subtract } from './math.js';

console.log(multiply(5, 5));

console.log(subtract(10, 4))

console.log(add(10, 10));

Now we've learned how to use ES modules. We've learned how to use the export keyword, the import keyword, and we've learned about the differences between named exports and default exports. And we've learned how to rename both our default exports and our named exports.

Other module systems in JavaScript

When learning about modules, you may have seen or even used a different type of import, possibly one that looks like this:

var models = require('./models')

This is where learning about modules in JavaScript can get confusing. Let's dive into a brief history of JavaScript modules to clear up the confusion.

The code example above using the require statement is CommonJS. CommonJS is another module system that can be used in JavaScript.

When JavaScript was first created, it didn’t have a module system. Because JavaScript had no module system, developers created their own module systems on top of the language.

Different module systems were created and used over the years, including CommonJS. When working in a codebase at a company or in an open source project, you might spot different module systems being used.

Ultimately, ES modules were introduced as the standardized module system in JavaScript.

In this article, we've learned about what modules are and why developers use them. We've learned about how ES modules work and the different kinds of module systems in JavaScript.

If you enjoyed this post, join my coding club, where we tackle coding challenges together every Sunday and support each other as we learn new technologies.

If you have feedback or questions on this post, or find me on Twitter @madisonkanna.

You create modules to better organize and structure your codebase. You can use them to break down large programs into smaller, more manageable, and more independent chunks of code which carry out a single or a couple of related tasks.

Modules should be:

1. Independent/Self-contained: A module has to be as detached from other dependencies as possible.

2. Specific: A module needs to be able to perform a single or a related group of tasks. The core essence of creating them in the first place is to create separate functionalities. One module, one (kind of) task.

3. Reusable: A module has to be easy to integrate into various kinds of programs to perform its task.

To better explain, let me give you an analogy:

Suppose we want to build a huge house from the ground up. All the tools we need to set up the building are all pilled up within just one room.

In such a situation, organizing the tools in the right way so we can start building would be difficult.

Instead of having the separate dependencies pilled up in just one room, we should instead organize each set of related tools and group them into different rooms. Each room is independent and self-contained with its tools solving specific tasks.

We could put up labels like: "these tools are for roofing", "these tools are for brick laying", "these tools are for foundation digging" and so on.

Whenever we want a tool to carry out a particular task, we know in which room exactly to find it. That way, everything is much more organized and locatable.

Also, say we are done building the house and then decide to build something different. We will still have at our disposal the same set of tools. This enforces the principle of reusability. Modules are reusable because they are self-contained.

Example of a Module

Now in the context of code, modules are very important.

Let's consider a simplified illustration of this with an e-commerce application which allows people and businesses to sell products online. This program will typically be composed of two or more unrelated tasks. For example,

• a program for creating an account,

• a program to validate the information,

• another program to process payments

• another program to calculate the user ratings

and so on.

Instead of having all of those unrelated programs together in one module/file, it is a better practice to create several files, or modules, for each of those tasks. In such a case, the modules become dependencies.

Then from the main app or program, you simply import/load the dependencies (i.e the modules you need) and execute them accordingly. As a result, your main app becomes cleaner and more minimal.

main.js has been broken down into four modules

Assuming you need to process payments in some other application in the codebase, for example, it becomes very easy to reuse the same functionality. No need to copy and paste or code a new function from scratch.

JavaScript Modules

A module in JavaScript is just a file containing related code.

In JavaScript, we use the import and export keywords to share and receive functionalities respectively across different modules.

• The export keyword is used to make a variable, function, class or object accessible to other modules. In other words, it becomes a public code.

• The import keyword is used to bring in public code from another module.

Let's look at a simple example of this:

function getPower(decimalPlaces) {
    return 10 ** decimalPlaces;
}

function capitalize(word) {
    return word[0].toUpperCase() + word.slice(1);
}

function roundToDecimalPlace(number, decimalPlaces = 2) {
    const round = getPower(decimalPlaces);
    return Math.round(number * round) / round;
}

export { capitalize, roundToDecimalPlace };

This module has three functions defined in it:

• getPower: This function gets the power of a number

• capitalize: This function capitalizes the first letter in a word

• roundToDecimalPlace: This function rounds a given number to a specified number of decimal places.

At the end of the file, you can see that two of the three functions were exported. In other words, they became public functions which could be used by any other script.

To export two functions out of the three, you use the export keyword, followed by an object containing the functions you want to make accessible. Once you do this, the functions can be accessed by any program within that codebase which require them.

Let's take a look at how we can use them:

import { capitalize, roundToDecimalPlace } from './main';

function displayTotal(name, total) {
    return `${capitalize(name)}, your total cost is: ${roundToDecimalPlace(total)}`;
}

displayTotal('kingsley', 20.4444444);
// "Kingsley, your total cost is: 20.44"

export { displayTotal };

The displayTotal.js module does not have capitalize() and roundToDecimalPlace() but wants to use the capitalize and round-to-decimal-place functionality. So how did we bring it in? With import!

We did this by using the import keyword followed by the name of the functions we want to import from the module, which in our case are capitalize and roundToDecimalPlace.

What if you only wanted to import the capitalize function into your program?

Simple – import only capitalize(), like so:

import { capitalize } from './main';

function warn(name) {
    return `I am warning you, ${capitalize(name)}!`;
}

warn('kingsley');
// I am warning you, Kingsley!

export { warn };

N/B: Understanding how file structuring works is very important when working with modules. In the above example, we are simply importing from a file which exists in the same directory, which is why we use the notation './import'.

If you want to import every public function from another module, use the asterisk * keyword:

import * as mainfunctions from './main';

function warn(name) {
return `I am warning you, ${mainfunctions.capitalize(name)}!`;
}
warn('kingsley');
// I am warning you, Kingsley!

export { warn };

TIP: If you're importing everything from a module, you should use the asterisk instead of explicitly spelling out all the functions one-by-one.

You may have noticed the as keyword. We use this to import the public functions into a new object, which in our case is the mainfunctions object. We then access and call the functions we want to use in our program.

So far, we have only considered examples where the export happens at the end of the file. But you can equally export a function, variable, or class by registering the export keyword just in front of its definition, like so:

function getPower(decimalPlaces) {
    return 10 ** decimalPlaces;
}

export function capitalize(word) {
    return word[0].toUpperCase() + word.slice(1);
}

export function roundToDecimalPlace(number, decimalPlaces = 2) {
    const round = getPower(decimalPlaces);
    return Math.round(number * round) / round;
}

If you compare this with the first example, you will notice this syntactic difference:

• In the first example, the export keyword was used to export two functions at the end of the script. In the above example, the export keyword is attached to both functions when they are being defined.

However, they both deliver the same outcome: capitalize and roundToDecimalPlace will both get exported.

Default Exports

If you want to export all three functions but intend to make one of them a default (perhaps because you are most likely to use that single function), you simply use the default keyword.

The default keyword makes importing a function easier. Let's consider the following example:

export function getPower(decimalPlaces) {
    return 10 ** decimalPlaces;
    }

export default function capitalize(word) {
    return word[0].toUpperCase() + word.slice(1);
    }

export function roundToDecimalPlace(number, decimalPlaces = 2) {
    const round = getPower(decimalPlaces);
    return Math.round(number * round) / round;
    }

As you can see, we have made capitalize our default function. This essentially means we have given it some sort of privilege.

Say we want to import the capitalize function from the module into another program. The syntax for that will be very similar, except you don't have to import the function into curly braces:

import capitalize from './main';

function warn(name) {
    return `I am warning you, ${capitalize(name)}!`;
}

warn('kingsley');
// I am warning you, Kingsley!

export { warn };

If you want to import the default function along with any other functions, you mix the bare 'default' function with other functions in curly braces:

import capitalize, { getPower } from './main';

function warn(name) {
    return `I am warning you, ${capitalize(name)}!`;
}

warn('kingsley');
// I am warning you, Kingsley!

export { warn };

Wrapping Up

Modules are independent and self-contained chunks of code. You create them by splitting up a larger program into logical parts or dependencies.

Modules should be independent, specialized, and reusable.

You use the import and export keywords to interchange functionalities between modules in JavaScript.

You use the default keyword to specify a function, object, variable, or class that you want to be a first-choice import.

With this, we have covered the basics of modules in JavaScript.

I hope you got something valuable from this article. I write programming-related articles every week on my personal blog

Thank you for reading.

P/S: If you are learning JavaScript, I created an eBook which teaches 50 topics in JavaScript with hand-drawn digital notes. Check it out here.

In this quick guide to Python's datetime module, you'll learn how to parse dates, extract meaningful information from dates, handle timedelta objects and much more.

So without further ado let's start counting time with Python!

Most programming languages provide libraries for easy handling of dates. Python offers the powerful datetime module with its many functions and lucid documentation which makes parsing dates easy.

This article lists out some of the most important functions from this module, how it can be applied for real-world situations, and some tricky things to watch out for when using it.

How to Convert Timestamps to datetime Objects Using strptime()

Dates can give us a lot of information like the month, year, day, weekday and whether it's a holiday or not. strptime() converts a timestamp in the form of a string to a datetime object which gives us a lot of extra functionalities. This function expects a string and the format of the timestamp.

from datetime import datetime

d = datetime.strptime("21-02-2021 18:46:00", "%d-%m-%Y %H:%M:%S")

The string 21-02-2021 18:46:00 is converted to a suitable datetime using the format specified. Some of the most useful directives are:

• %d for day of month as a zero-padded decimal like 01, 02, 03
• %m for month as a zero-padded decimal number
• %Y for year with century as a decimal number
• %H for 24 hour clock with a zero-padded hour value
• %M for zero-padded minutes, and
• %S for zero-padded seconds.

This collection of format specifiers is enough to get you started. For more options, you can browse through the docs linked here.

How to Get the Current Timestamp Value

Suppose you want to store data to a database with the current timestamp as a key. To obtain the current timestamp, you just need 1 line of code:

#Obtain the current timestamp

from datetime import datetime
print(datetime.now())

How to Know What Day it Is

Let's say we need to know the day of the week. We can use the weekday() function which returns a numeric code for the day of the week, zero through six, where zero represents Monday, one represents Tuesday, and so on.

The output could be used with a switch statement to convert the numeric code to the required day name or you could use a list like this:

How to Generate a List of Dates from a Given Date

Let's say we know how many pizzas people ordered up until today and we are interested in predicting pizza sales for the next week.

So, given today's date we need all dates for next week for our required analysis. But we don't want to worry about leap years, century years, and so on. Here's one way to do it.

How to Work with timedelta Objects

As the name suggests, timedelta objects represent a time duration between two dates. Let's say that we have two dates and we need to know how much time has passed between them.

timedelta objects require several arguments like days, seconds, microseconds, milliseconds, minutes, hours and weeks. Default values for all are zero. Let's find out the difference in hours between 2 dates.

What went wrong? timedelta does not store anything internally except for days, seconds, and microseconds, so we need to convert them as shown below:

How to Get String Representation of Dates from datetime or Date Objects using strftime

If we print the datetime object itself, the date is printed in ISO format. Using strftime, we pass a format string to control the string representation of the date.

Conclusion

If you've read this far, congrats – you've learned how to parse dates according to a specified format, obtain the current timestamp value, get the weekday, get a list of dates, use timedelta objects, and get the date as a string back from objects. Whew!

This is a compiled collection based on my own numerous internet searches and endless perusal of the official docs.

Thank you for taking some time out of your busy schedule to read this. Hope you enjoyed reading it just as much as I loved writing it. Have fun parsing dates in Python!

One of the most powerful things about software development is the ability to reuse and build upon the foundations of other people. This code sharing has helped software progress at an amazing rate.

Such a wonderful mechanism is critical on a micro-level for both individual projects and teams.

For Node.js, this process of code sharing – both within individual projects and in external npm dependencies – is facilitated using module.exports or exports.

How Node Modules Work

How do we use module exports to plug an external module, or sensibly break our project down into multiple files (modules)?

The Node.js module system was created because its designers didn't want it to suffer from the same problem of broken global scope, like its browser counterpart. They implemented CommonJS specification to achieve this.

The two important pieces of the puzzle are module.exports and the require function.

How module.exports works

module.exports is actually a property of the module object. This is how the module object looks like when we console.log(module):

Module {
  id: '.',
  path: '/Users/stanleynguyen/Documents/Projects/blog.stanleynguyen.me',
  exports: {},
  parent: null,
  filename: '/Users/stanleynguyen/Documents/Projects/blog.stanleynguyen.me/index.js',
  loaded: false,
  children: [],
  paths: [
    '/Users/stanleynguyen/Documents/Projects/blog.stanleynguyen.me/node_modules',
    '/Users/stanleynguyen/Documents/Projects/node_modules',
    '/Users/stanleynguyen/Documents/node_modules',
    '/Users/stanleynguyen/node_modules',
    '/Users/node_modules',
    '/node_modules'
  ]
}

The above object basically describes an encapsulated module from a JS file with module.exports being the exported component of any types - object, function, string, and so on. Default exporting in a Node.js module is as simple as this:

module.exports = function anExportedFunc() {
  return "yup simple as that";
};

There's another way of exporting from a Node.js module called "named export". Instead of assigning the whole module.exports to a value, we would assign individual properties of the default module.exports object to values. Something like this:

module.exports.anExportedFunc = () => {};
module.exports.anExportedString = "this string is exported";

// or bundled together in an object
module.exports = {
  anExportedFunc,
  anExportedString,
};

Named export can also be done more concisely with the module-scoped exports predefined variable, like this:

exports.anExportedFunc = () => {};
exports.anExportedString = "this string is exported";

However, assigning the whole exports variable to a new value won't work (we will discuss why in a later section), and often confuses Node.js developers.

// This wont work as we would expect
exports = {
  anExportedFunc,
  anExportedString,
};

Imagine that Node.js module exports are shipping containers, with module.exports and exports as port personnel whom we would tell which "ship" (that is, values) that we want to get to a "foreign port" (another module in the project).

Well, "default export" would be telling module.exports which "ship" to set sail while "named export" would be loading different containers onto the ship that module.exports is going to set sail.

My "flagship" analogy for Node.js module.exports' role

Now that we have sent the ships sailing, how do our "foreign ports" reel in the exported ship?

How the Node.js require keyword works

On the receiving end, Node.js modules can import by require-ing the exported value.

Let's say this was written in ship.js:

...
module.exports = {
  containerA,
  containerB,
};

We can easily import the "ship" in our receiving-port.js:

// importing the whole ship as a single variable
const ship = require("./ship.js");
console.log(ship.containerA);
console.log(ship.containerB);
// or directly importing containers through object destructuring
const { containerA, containerB } = require("./ship.js");
console.log(containerA);
console.log(containerB);

An important point to note about this foreign port operator – require – is that the person is adamant about receiving ships that were sent by module.exports from the other side of the sea. This leads us to the next section where we will address a common point of confusion.

module.exports vs exports – What is the difference and which do you use when?

Now that we have gone through the basics of module exporting and requiring, it's time to address one of the common sources of confusion in Node.js modules.

This is a common module exports mistake that people who are starting out with Node.js often make. They assign exports to a new value, thinking that it's the same as "default exporting" through module.exports.

However, this will not work because:

• require will only use the value from module.exports
• exports is a module-scoped variable that refers to module.exports initially

So by assigning exports to a new value, we're effectively pointing the value of exports to another reference away from the initial reference to the same object as module.exports.

If you want to learn more about this technical explanation, the Node.js official documentation is a good place to start.

Back to the analogy that we made previously using ships and operators: exports is another port personnel that we could inform about the outgoing ship. At the start, both module.exports and exports have the same piece of information about the outgoing "ship".

But what if we tell exports that the outgoing ship will be a different one (that is, assigning exports to a completely new value)? Then, whatever we tell them afterwards (like assigning properties of exports to values) won't be on the ship that module.exports is actually setting sail to be received by require.

On the other hand, if we only tell exports to "load some containers on the outgoing ship" (assigning properties of exports to value), we would actually end up loading "containers" (that is, property value) onto the ship that is actually being set sail.

Based on the common mistake explained above, we could definitely develop some good conventions around using CommonJS modules in Node.js.

Node.js export best practices – a sensible strategy

Of course the convention offered below is entirely from my own assessments and reasonings. If you have a stronger case for an alternative, please don't hesitate to tweet me @stanley_ngn.

The main things I want to achieve with this convention are:

• eliminating confusion around exports vs module.exports
• ease of reading and higher glanceability with regards to module exporting

So I'm proposing that we consolidate exported values at the bottom of the file like this:

// default export
module.exports = function defaultExportedFunction() {};
// named export
module.exports = {
  something,
  anotherThing,
};

Doing so would eliminate any disadvantages in terms of conciseness that module.exports have versus shorthand exports. This would remove all incentives for us to use the confusing and potentially harmful exports.

This practice would also make it very easy for code readers to glance at and learn about exported values from a specific module.

Going beyond CommonJS

There's a new, and better (of course!) standard that's recently been introduced to Node.js called ECMAScript modules. ECMAScript modules used to only be available in code that would eventually need transpilation from Babel, or as part of an experimental feature in Node.js version 12 or older.

It's a pretty simple and elegant way of handling module exporting. The gist of it can be summed up with the default export being:

export default function exportedFunction() {}

and the named export looking like this:

// named exports on separate LOC
export const constantString = "CONSTANT_STRING";
export const constantNumber = 5;
// consolidated named exports
export default {
  constantString,
  constantNumber,
};

These values can then easily be imported on the receiving end, like this:

// default exported value
import exportedFunction from "exporting-module.js";
// import named exported values through object destructuring
import { constantString, constantNumber } from "exporting-module.js";

This results in no more confusion from module.exports vs exports and a nice, human-sounding syntax!

There are definitely projects that are yet to be migrated to Node.js version 14 and above and so can't use this new syntax.

However, if you do have a chance (because you are starting a new project, or your project has successfully been migrated to Node.js 14 and above), there's no reason not to switch to this awesome futuristic way of doing things.

Thank you for reading!

Last but not least, if you like my writings, please head over to my blog for similar commentaries and follow me on Twitter. 🎉

One of the major challenges when building a web-app is how quickly you can scale and respond to the market needs. When the demand (requirements) increases, the capabilities (features) increase too. It is therefore important to have a solid architectural structure so that the app grows organically. We don’t want to end up in situations where the app can’t scale because everything in the app is deeply entangled.

Write code that is easy to delete, not easy to extend.

• Tef, Programming is Terrible

In this article, we’ll create a simple dashboard using ES6 modules, and then present optimization techniques for improving the folder structure and ease write less code. Let’s see dive into why ES6 modules are important, and how to effectively apply it.

JavaScript has had modules for a long time. However, they were implemented via libraries, not built into the language. ES6 is the first time that JavaScript has built-in modules (source).

TL;DR — If you want to see a practical example where we create a dashboard using ES6 modules from an architectural design layout, jump to section 4.

Here’s what we’ll address

1. Why ES6 modules are needed
2. Back in the days when scripts were loaded manually
3. How ES6 modules work (import vs export )
4. Let’s build a dashboard with modules
5. Optimization techniques for dashboard example

If you want to become a better web developer, start your own business, teach others, or improve your development skills, I’ll be posting weekly tips and tricks on the latest web languages.

1. Why ES6 modules are needed

Let’s view a couple of scenarios as to why modules are relevant.

Scenario 1 — Don’t reinvent the wheel

As developers, we often recreate things that has already been created without even being aware, or copy and paste stuff to reduce time. In the end, it adds up, and we are left with x number of identical copies scattered throughout the app. And for each time we need to change something, we must do it x times depending on how many copies we have.

Example
For instance, imagine a car factory trying to reinvent the engine every time it produced a new car, or an architect starting from scratch after each drawing. It’s not impossible to do this, but then what is the point of knowledge if you cannot reuse the experience you’ve acquired.

Scenario 2— Knowledge barrier

If the system is deeply entangled, and lack of documentation, its difficult for old/new developers to learn how the app works, and how things are connected.

Example
For instance, a developer should be able to see what the outcome of a change is without guessing, otherwise we end up with lots of errors without knowing where to start. A solution is to use modules for encapsulating behaviour, we can easily narrow down the debug process and quickly identify the root of the problem.

I’ve recently written an article about “Developers that constantly want to learn new things”, with tips on how to improve knowledge.

Scenario 3— Unexpected behavior

By avoiding separation-of-concerns (design principle), it can lead to unexpected behaviour.

Example
For instance, let’s say someone increases the volume in the car, and that starts the windshield wipers. That is an example of an unexpected behaviour, and not something we want in our application.

In short, we need ES6 modules in order to effectively reuse, maintain, separate and encapsulate internal behaviour from external behaviour. It’s not about making the system complex, but having the ability to easily scale and delete stuff without breaking the system.

2. Back in the days when scripts were loaded manually

If you’ve done web development for a couple of years, then you’ve definitely encountered dependency conflicts such as scripts not loading in the right order, or that the elements of the DOM tree cannot be accessed by JS.

The reason is that the HTML on a page is loaded in the order in which it appears, which means we cannot load scripts before the content inside the <body> element has finished loading.

For instance, if you try to access an element within the <body> tag using document.getElementById("id-name") and the element is not loaded yet, then you get an undefined error. To make sure that scripts are loaded properly we can use and defer async. The former will make sure that each script loads in the order it appears, while the latter loads the script whenever it becomes available.

The old fashioned way of solving such issue was to load the scripts right before the </body> element.

<!DOCTYPE html>
<head>
</head>
<body>

  <!--HTML content goes here-->

  <script src="js/jquery.js"></script>
  <script src="js/script2.js"></script>
  <script src="js/script3.js"></script>
  <script src="js/script4.js"></script>
</body>
</html>

But in the long run, the number of scripts adds up and we may end up with 10+ scripts while trying to maintain version and dependency conflicts.

Separation-of-concerns

In general, loading scripts as shown above is not a good idea in terms of performance, dependencies and maintainability. We don’t want the index.html file to have the responsibility of loading all the scripts — we need some sort of structure and separation of logic.

The solution is to utilize ES6’s syntax, import and export statements, an elegant and maintainable approach that allows us to keep things separated, and only available when we need it.

The import and export statements

The export keyword is used when we want to make something available somewhere, and the import is used to access what export has made available.

The thumb rule is, in order to import something, you first need to export it.

And what can we actually export?

• A variable
• An object literal
• A class
• A function
• ++

To simplify the example as shown above, we can wrap all scripts one file.

import { jquery } from './js/jquery.js';
import { script2 } from './js/script2.js';
import { script3 } from './js/script3.js';
import { script4 } from './js/script4.js';

And then just load app.js script in our index.html. But first, in order to make it work, we need to use type="module" (source) so that we can use the import and export for working with modules.

<!DOCTYPE html>
<head>
</head>
<body>

  <!--HTML content goes here-->

  <script type="module" src="js/app.js"></script>
</body>
</html>

As you can see, the index.html is now responsible for one script, which makes it easier to maintain and scale. In short, the app.js script becomes our entry point that we can use to bootstrap our application.

Note: I would not recommend having all scripts loaded in one file such as app.js, except the ones that require it.

Now that we have seen how we can use the import and export statements, let’s see how it works when working with modules in practice.

3. How ES6 modules work

What is the difference between a module and a component? A module is a collection of small independent units (components) that we can reuse in our application.

What’s the purpose?

• Encapsulate behaviour
• Easy to work with
• Easy to maintain
• Easy to scale

Yes, it makes development easier!

So what is a component really?

A component may be a variable, function, class and so forth. In other words, everything that can be exported by the _export_ statement is a component (or you can call it a block, a unit etc).

What is a component

So what is a module really?

As mentioned, a module is a collection of components. If we have multiple components that communicate, or simply must be shown together in order to form an integrated whole, then you most likely need a module.

What is a module

Its a challenge to make everything reusable

A principal engineer with over 30 years of experience in electrical engineering once said, we cannot expect everything to be reused because of time, cost and not everything is meant to be reused. It is better to reuse to some extent than expecting things to be reused 100%.

In general, it means that we don’t have to make everything reusable in the app. Some things are just meant to be used once. The rule of thumb is that if you need something more than two times, then maybe it is a good idea to create a module or a component.

At first, it may sound easy to make something reusable, but remember, it requires taking the component out from its environment, and expect it to work in another one. But often times, we have to have to modify parts of it to make it fully reusable, and before you know it, you’ve created two new components.

Antoine, wrote an article describing 3 essential rules of creating reusable JS components, which is recommend to read. When he presented VueJS to his team, an experienced coworker says:

That’s great in theory, but in my experience these fancy “reusable” things are never reused.

The idea is that, not everything should be reused, such as buttons, input-fields and check boxes and so forth. The whole job of making something reusable requires resources and time, and often we end up with over-thinking scenarios that would never occur.

The CEO of Stack Overflow, Joel Spolsky says:

A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. Shipping is a feature. A really important feature. Your product must have it.

4. Let’s build a dashboard with modules

Now that we have a basic understanding of how modules work, let’s view a practical example you’ll most likely encounter when working with JS frameworks. We’ll be creating a simple dashboard following an architectural design that consist of layouts and components.

The code for the example can be found here.

Step 1 — Design what you need

In most cases, developers would jump directly into the code. However, design is an important part of programming and it can save you a lot of time and headache. Remember, design should not be perfect, but something that leads you to the right direction.

So this is what we need based on the architectural design.

• Components: users.js, user-profile.js and issues.js
• Layouts: header.js and sidebar.js
• Dashboard: dashboard.js

All components and layouts will be loaded in dashboard.js and then we will bootstrap dashboard.js in index.js.

Architectural design of our dashboard

So why do we have a layouts and components folder?

A layout is something that we need once, for instance a static template. The content inside the dashboard may change, but the sidebar and header will stay the same (and these are what is known as layouts). A layout can be either an error page, footer, status page and so forth.

The components folder is for general components we most likely will reuse more than once.

It is important to have a solid ground structure when dealing with modules. In order to effectively scale, folders must have reasonable names that make it easy to locate stuff and debug.

Later I’ll show you how to create a dynamic interface, which requires having a folder space for the components and layouts we need.

Step 2— Setup folder structure

As mentioned, we have 3 main folders: dashboard, components and layouts.

- dashboard
- components 
- layouts
index.html
index.js ( entry point )

And in each file inside the folder, we export a class.

- dashboard
    dashboard.js
- components
    issues.js
    user-profile.js
    users.js 
- layouts
    header.js
    sidebar.js
index.html
index.js ( entry point )

Step 3 — Implementation

The folder structure is all set, so the next thing to do is to create the component (a class) in each file and then export it. The code convention is the same for the rest of the files: every component is simply a class, and a method that consoles “x component is loaded” where x is the name of the component in order to indicate that the component has been loaded.

Let’s create a user class and then export it as shown below.

class Users {

  loadUsers() {
    console.log('Users component is loaded...')
  }

}

export { Users };

Notice, we have various options when dealing with the export statement. So the idea is that you can either export individual components, or a collection of components. For instance if we export the class, we can access the methods declared within by creating a new instance of the class.

export { name1, name2, …, nameN };
export function FunctionName(){...}
export class ClassName {...}
...

export * from …;
export { name1, name2, …, nameN } from …;
export { import1 as name1, import2 as name2, …, nameN } from …;
export { default } from …;
...

Alright, so if you look at the architectural diagram in step 1, you’ll notice that the user-profile component is encapsulated by the header layout. This means that when we load the header layout, it will also load the user-profile component.

import { UserProfile } from '../components/users-profile.js';

class Header {

  loadHeader() {
    // Creata a new instance
    const userProfile = new UserProfile(); 

    // Invoke the method (component)
    userProfile.loadUserProfile();

    // Output loading status
    console.log('Header component is loaded...')
  }

}

export { Header };

Now that each component and layout has an exported class, we then import it in our dashboard file like this:

// From component folder
import { Users } from '../components/users.js';
import { Issues } from '../components/issues.js';

// From layout folder
import { Header } from '../layouts/header.js';
import { Sidebar } from '../layouts/sidebar.js';


class Dashboard {

  loadDashboard(){

    // Create new instances
    const users = new Users();
    const issues = new Issues();
    const header = new Header();
    const sidebar = new Sidebar();

    console.log('Dashboard component is loaded');
  }

}

export { Dashboard }

In order to understand what is really going on in the dashboard file, we need to revisit the drawing in step 1. In short, since each component is a class, we must create a new instance and then assign it to an object. Then we use the object to execute the methods as shown in method loadDashboard().

Currently, the app doesn’t output anything because we haven’t executed the method loadDashboard(). In order to make it work we need to import the dashboard module in file index.js like this:

import { Dashboard } from './dashboard/dashboard.js'; 

const dashboard = new Dashboard(); 

dashboard.loadDashboard();

And then the console outputs:

ES6 Components loaded

As shown, everything works and the components load successfully. We can also go ahead and create two instances and then do something like this:

import { Dashboard } from './dashboard/dashboard.js'; 

const dashboard_1 = new Dashboard(); 
const dashboard_2 = new Dashboard(); 

dashboard_1.loadDashboard();
dashboard_2.loadDashboard();

Which outputs the same as shown above, but since we have to new instances, we get the results twice.

Two unique instances of dashboard

In general, this allows us to easily maintain and reuse the module in the files needed without interfering with other modules. We just create a new instance which encapsulates the components.

However, as previously mentioned, the purpose was to cover the dynamic of how we can work with modules and components using the import and export statements.

In most cases when working with JS frameworks, we usually have a route that can change the content of the dashboard. Right now, everything along such as layouts is loaded every time we invoke the method loadDashboard() which is not an ideal approach.

5. Optimization techniques for dashboard example

Now that we have a basic understanding of how modules work, the approach is not really scalable or intuitive when we deal with large applications that consist of a lots of components.

We need something that is known as a dynamic interface. It allows us to create a collection of the components we need, and easily access it. If you are using Visual Studio Code, the IntelliSense shows you what components are available, and which one you’ve already used. It means you don’t have to open the folder/file manually to see what components has been exported.

So if we have a module with twenty components, we don’t want to import each component one line after the other. We simply want to get what we need, and that’s it. If you’ve worked with namespaces in languages such as C#, PHP, C++ or Java, you’ll notice that this concept is similar in nature.

Here’s what we want to achieve:

// FILE: dashboard.js

// From component folder
import { users, issues } from '../components';

// From layout folder
import { header, sidebar } from '../layouts'; 


class Dashboard {

  loadDashboard(){

    // Invoke methods
    users.loadUsers();
    issues.loadIssues();
    header.loadHeader();
    sidebar.loadSidebar();

    console.log('Dashboard component is loaded');
  }

}

export let dashboard = new Dashboard();

As shown, we have less lines of code, and we made it declarative without losing the context. Let’s see what changes we’ve made.

Create a dynamic interface (also known as a barrels)

A dynamic interface allows us to create a collection of things we need. It’s like creating a toolbox with our favorite tools. One thing that is important to mention is that a dynamic interface should not be added in every single folder, but to folders that consist of many components.

They greatly simplify the imports and make them look clearer. We just don’t want to have too many barrel files since that is counter productive and usually leads to circular dependency issues which sometimes can be quite tricky to resolve.

• Adrian Fâciu

In order to create a dynamic interface, we create a file named index.js which is located in the root of each folder to re-export a subset of files or components we need. The same concept works in TypeScript, you just change the type from .js to .ts like index.ts.

The index.js is the first file that loads when we access the root folder space — it’s the same concept as index.html that boots our HTML content. This means we don’t have to explicitly write import { component } from './components**/index.js**' , but instead import { component } from './components.

Here’s how a dynamic interface looks.

// Root space -> components folder

// Dynamic interface
export { users } from './users';
export { issues } from './issues';
export { userProfile } from './user-profile';

By using a dynamic interface, we end up with one less root level to access, and also less code.

// Before
import { Users } from '../components/users.js';
import { Issues } from '../components/issues.js';
import { Header } from '../layouts/header.js';
import { Sidebar } from '../layouts/sidebar.js';

// After (with dynamic interface)
import { users, issues } from '../components';
import { header, sidebar } from '../layouts';

Create a new instance at runtime

We removed the four instances in our dashboard.js, and instead created an instance at runtime when every component is exported. If you want to decide the name of the object, you can do export default new Dashboard(), and then import dashView without the curly braces.

// Before
export class { dashboard }; 
const dashboard = new Dashboard(); 
dashboard.loadDashboard(); 

// After
export const dashboard = new Dashboard(); 
dashboard.loadDashboard()

As shown, we can directly invoke the method without needing to create a new instance, and also write less code. However, this is a personal preference and you can freely decide what is a practical use case for your app and requirements.

And finally, we load all components and layouts with one method.

import { dashboard } from './dashboard/dashboard';

dashboard.loadDashboard();

Conclusion

I started with the intention of just showing a short example of how you can import and export a component, but then felt the need to share everything I know (almost). I hope this article provides you some insight into how to deal with ES6 modules effectively when building apps, and the things that are important in terms of separation-of-concerns (design principle).

The takeaways:

• With ES6 modules we can easily reuse, maintain, separate and encapsulate components from being changed by external behavior
• A module is a collection of components
• A component is an individual block
• Don’t try to make every everything reusable as it requires time and resources, and most often we don’t reuse it
• Create an architectural diagram before diving into the code
• In order to make components available in other files, we must first export and then import
• By using index.js (same concept for TypeScript index.ts) we can create dynamic interfaces (barrels) to quickly access the things we need with less code and fewer hierarchical paths
• You can export a new instance at runtime by using export let objectName = new ClassName()

The good news is that things have changed and we are moving towards a component-based and reusable paradigm. The question is how can we reuse not only plain JS code, but HTML elements too in a practical and intuitive way. It looks like that ES6 modules combined with web components may just give us what we need to build performant and scalable apps.

Here are a few articles I’ve written about the web-ecosystem along with personal programming tips and tricks.

• A comparison between Angular and React
• A chaotic mind leads to chaotic code
• Developers that constantly want to learn new things
• Learn these core Web Concepts
• Boost your skills with these important JavaScript methods
• Program faster by creating custom bash commands

You can find me on Medium where I publish on a weekly basis. Or you can follow me on Twitter, where I post relevant web development tips and tricks along with personal dev stories.

In object-oriented computer languages such as Python, classes are basically a template to create your own objects. Objects are an encapsulation of variables and functions into a single entity. Objects get their variables and functions from classes.

Say what?

Here are some examples that will help you understand — read on. There is also an interactive code shell, simply press the “Run” button at the top of the specific window.

The simplest way to describe classes and how to use them is this:

Imagine you have great powers. You create a species (“class”).

Then you create attributes for that species (“properties”) — height, weight, limbs, color, powers, and so on.

Then you create an instance of that species — Fido the dog, Drogon from Game of Thrones, and so on. Then you work with these instances:

• In a game, for instance, they would engage in action, interact, using their attributes.
• In a banking app, they would be the different transactions.
• In a vehicle buy/sell/trade/lease app, the vehicle class could then spawn sub-classes such as cars. Each would have attributes such as mileage, options, features, color, and trim.

You can already see why this is useful. You are creating, re-using, adapting, and enhancing items in a very efficient, logical, and useful way.

By now, you have probably realized that this is a way to classify and group, one that that is similar to how humans learn:

• Animals are living things that are not human or trees, in a basic sense
• then you move on to different types of animals — dogs, cats are probably the first animals most of us learnt about
• then you move to different attributes of animals — shapes, sizes, sounds, appendages and so on.

For instance, when you were a child, your first understanding of a dog was probably something with four legs that barked. Then you learnt to distinguish that some were real dogs, others were toys. That this “dog” concept contained many types.

Creating and using classes is basically:

• building a template to put “things” in — a classification
• which can then be operated on. For example, pulling up all the people with dogs that you could request to link to a blog on pets, or all bank clients who might be good prospects for a new credit card.

The main point here is classes are objects that can produce instances of those templates, on which operations and methods can be applied. It is an excellent way to conceptualize, organize, and build a hierarchy for any organization or process.

As our world gets more complex, this is a way to mimic that complexity from a hierarchical perspective. It also builds a deeper understanding of the processes and interactions for business, technical, and social settings from a virtual information technology point.

An example might be a video game you create. Each character could be a “class”, with its own attributes, that interacts with instances of other classes. King George of the “King” class might interact with Court Jester Funnyman of the “Clown” class, and so on. A King might have a royal “servant” class, and a “servant” class would always have a “King” class, for example.

This is what we will do:

• create a class and use it
• create a module and move the class creation and initiation to the module
• call the module in a new program to use the class

The code is available in GitHub here.

#TSB - Create Class in Python - rocket positions (x,y) and graph

#some items and comments bolded to call attention to processimport matplotlib.pyplot as plt

class Rocket():  def __init__(self, x=0, y=0):    #each rocket has (x,y) position; user or calling function has choice    #of passing in x and y values, or by default they are set at 0    self.x = x    self.y = y      def move_up(self):    self.y += 1      def move_down(self):    self.y -= 1      def move_right(self):    self.x += 1      def move_left(self):    self.x -= 1

#Make a series of rockets - x,y positions, I am calling it rocketrockets=[]rockets.append(Rocket())rockets.append(Rocket(0,2))rockets.append(Rocket(1,4))rockets.append(Rocket(2,6))rockets.append(Rocket(3,7))rockets.append(Rocket(5,9))rockets.append(Rocket(8, 15))  #Show on a graph where each rocket is

for index, rocket in enumerate(rockets):  #original position of rockets  print("Rocket %d is at (%d, %d)." % (index, rocket.x, rocket.y))  plt.plot(rocket.x, rocket.y, 'ro', linewidth=2, linestyle='dashed', markersize=12)  #move the 'rocket' one up  rocket.move_up()  print("New Rocket position %d is at (%d, %d)." % (index, rocket.x, rocket.y))  #plot the new position  plt.plot(rocket.x, rocket.y, 'bo', linewidth=2, linestyle='dashed', markersize=12)  #move the rocket left, then plot the new position  rocket.move_left()  plt.plot(rocket.x, rocket.y, 'yo', linewidth=2, linestyle='dashed', markersize=12)

#show graph legend to match colors with positionplt.gca().legend(('original position','^ - Moved up', '< - Moved left'))plt.show()#plt.legend(loc='upper left')

Output from code above, using Python class

Now let us create a module and move some of the code above to the module. Any time we need to create this simple set of x,y coordinates in any program, we can use the module to do so.

What is a module and why do we need it?

A module is a file containing Python definitions and statements. Module is Python code that can be called from other programs for commonly used tasks, without having to type them in each and every program that uses them.

For example, when you call “matplotlib.plot”, you are calling a package module. If you didn’t have this module you would have to define the plot functionality in every program that used a plot graph.

From the Python documentation:

If you quit from the Python interpreter and enter it again, the definitions you have made (functions and variables) are lost. Therefore, if you want to write a somewhat longer program, you are better off using a text editor to prepare the input for the interpreter and running it with that file as input instead.This is known as creating a script. As your program gets longer, you may want to split it into several files for easier maintenance. You may also want to use a handy function that you’ve written in several programs without copying its definition into each program.

To support this, Python has a way to put definitions in a file and use them in a script or in an interactive instance of the interpreter. Such a file is called a module; definitions from a module can be imported into other modules or into the main module (the collection of variables that you have access to in a script executed at the top level and in calculator mode).

Here’s our simple module. It takes the class creation and the functions to move an instance of that class from the program above and into its own class. We will then use this in a new program simply by calling and referencing this module:

Notice what we did above:

• created and initialized the class
• created a function to move an instance of the class in the four major directions (up, down, right, left) and the increments — as parameters, or arguments to the function
• created another function to calculate the distance between two instances of the class, using the graph distance formula

Here’s how we will use the new module to re-write the same program from the first part. Notice in the import section at the beginning, we now import the simple_module1 module that we just created:

Here’s the output from the code using our module. Note that they are the same, except for the chart title and the shape of the position markers, which I changed for comparative purposes.

Output from code from creating and calling our own module!

Comparison of the original file-left(create class, use it) and same functionality using a module, right

Comparison of the output. On the right side, I change the marker shape for distinction, but the positions are unchanged.

That’s great, you may say — what are some other uses for this? One classic example is a bank account. A customer class might contain the name and contact details and — more importantly — the account class would have deposit and withdrawal elements.

This is grossly oversimplified but, for illustrative purposes, it is useful. That’s it — create a template, then define instances of that template with details (properties), and add value by adding, subtracting, modifying, moving, and using these instances for your program objectives.

Still wondering about classes? Ok, let’s get “classy” — here’s another simple illustration. We will call this class “Person”. It has only two properties — name and age. We will then add an instance of this with a person’s name and age, and print it. Depending on what your objective is, you can imagine all the other details you might add — for example, marital status and location preferences for a social networking app, job experience in years and industry specialization for a career related app. Press the little triangle below to see it work.

So there you have it. You can create many different classes, with parent classes, sub-classes and so on. Thanks for reading — please clap if you liked it. Here are some other references if you would like to learn more:

• Python documentation — Classes
• Python Object Oriented — Tutorials Point
• Classes and Objects — learnpython.org