snippetjavascriptTip

Modeling complex JavaScript object autoloading and console

Submitted by: @import:30-seconds-of-code·Mar 2, 2026·

Viewed 0 times

javascriptobjectconsolemodelingandautoloadingcomplex

Problem

> [!IMPORTANT]
>
> This article is part of a series, following Modeling complex JavaScript object field validation. It's highly recommended to read the previous articles to get the full context. The whole series is more of a show & tell hoping to <strong class="sparkles">inspire</strong> you to start that advanced JavaScript project you've been thinking about.
So far in this series, we've developed models, queries, scopes, serialization, and factories for our ActiveRecord-inspired project. As the project grows larger, I want to address autoloading and a console environment to interact with our objects. In this installment, we'll create an inspect utility to help us work with objects in the console.
This time, we're expanding the directory structure just a little. We'll add a new config directory for settings and a scripts directory for our autoload and console scripts.

Solution

src/
├── config/
│   └── settings.js
├── core/
│   ├── model.js
│   ├── recordSet.js
│   ├── serializer.js
│   └── factory.js
├── models/
│   ├── author.js
│   └── post.js
├── scripts/
│   ├── autoload.js
│   └── console.js
└── serializers/
    ├── postSerializer.js
    └── postPreviewSerializer.js
spec/
└── factories/
    ├── authorFactory.js
    └── postFactory.js

> This article is part of a series, following Modeling complex JavaScript object field validation. It's highly recommended to read the previous articles to get the full context. The whole series is more of a show & tell hoping to <strong class="sparkles">inspire</strong> you to start that advanced JavaScript project you've been thinking about.
So far in this series, we've developed models, queries, scopes, serialization, and factories for our ActiveRecord-inspired project. As the project grows larger, I want to address autoloading and a console environment to interact with our objects. In this installment, we'll create an inspect utility to help us work with objects in the console.
This time, we're expanding the directory structure just a little. We'll add a new config directory for settings and a scripts directory for our autoload and console scripts.
> [!TIP]
>
> If you need a refresher of the entire implementation thus far, it's available in the code summary section at the end of the previous article.

Code Snippets

src/
├── config/
│   └── settings.js
├── core/
│   ├── model.js
│   ├── recordSet.js
│   ├── serializer.js
│   └── factory.js
├── models/
│   ├── author.js
│   └── post.js
├── scripts/
│   ├── autoload.js
│   └── console.js
└── serializers/
    ├── postSerializer.js
    └── postPreviewSerializer.js
spec/
└── factories/
    ├── authorFactory.js
    └── postFactory.js

> [!NOTE]
>
> While the settings file might be a bit of an overkill for what appears to be a single setting, it's a good practice to have a **central place for all the settings**. This way, you can easily add more settings as your project grows.

### Autoloader

One of the features that I like a lot about ActiveRecord is the cleanliness of its modules. I never have to declare which modules I need, as they're all **automatically loaded**. Granted, this feels like magic and a bit of a black box, but it's a feature I want to replicate, at least to some extent.

After fiddling around with a few ideas, such as generating an index file for each directory, I settled on a fairly simple solution.

I'll first use the [`fs`](https://nodejs.org/api/fs.html) module to **read the directories** and **find all the files** in them. Then, I'll create a `Map` and use [`import()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) to **dynamically load each module**. Provided that naming conventions are followed, I'll be able to **deduce the module name from the file path**, much like Rails does. Then, I'll convert the `Map` to an object and export it.

> [!NOTE]
>
> As you'll notice, this implementation is pretty barebones, as it only handles **single-level directories** and **single-export modules**. However, it's a good starting point for a small project. You can take a stab at improving it by adding more features, such as nested directories or multiple exports, if you need them.

## Console environment

With the autoloader in place, we can now focus on creating a **console environment** to interact with our objects. We'll start by setting up the `console.js` script, then we'll create a custom object inspect utility.

### Console script

The `console.js` script will be the entry point for our console environment. It will **import the autoloaded modules** and **set up the REPL**. For that last part, we'll iterate over the modules and make them available in the REPL context.

Context

From 30-seconds-of-code: complex-object-autoloading-console

Revisions (0)

No revisions yet.